No bugs fixed, but added new capability to allocate memory outside of the garbage collector, to appeal to programmers who want to do their own allocation/deallocation.

www.digitalmars.com/d/changelog.html

Note: this will require a recompile of any existing .obj's and .lib files, as the contents of the ClassInfo changed.

Thanks, it seems to be very useful for critical applications.

Nic Tiger.

"Walter" <walter@digitalmars.com> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ: news:b255i0$1ufn$1@digitaldaemon.com...
> No bugs fixed, but added new capability to allocate memory outside of the garbage collector, to appeal to programmers who want to do their own allocation/deallocation.
>
> www.digitalmars.com/d/changelog.html
>
> Note: this will require a recompile of any existing .obj's and .lib files, as the contents of the ClassInfo changed.
>
>
>

> No bugs fixed, but added new capability to allocate memory outside of the garbage collector, to appeal to programmers who want to do their own allocation/deallocation.

Anyone thinking to take advantage of this new functionality might find this paper interesting:

Reconsidering Custom Memory Allocation http://citeseer.nj.nec.com/berger01reconsidering.html

Rob

On Sun, 9 Feb 2003 01:05:04 -0800, Walter <walter@digitalmars.com> wrote:
> No bugs fixed, but added new capability to allocate memory outside of the garbage collector, to appeal to programmers who want to do their own allocation/deallocation.

Are there any plans to allow non-member user-supplied new and delete functions, such as in C++?

For example, one might have a special new function that allocates from a given shared memory region, or one might want to do a mark/release on a specific collection of objects or structs, regardless of type.  Currently, to do this one would have to add non-default member new()s to every class that do nothing but call the global new.

Globally replacing the generic new and delete could also be useful for debugging memory leaks.

Also, I notice that new() takes a uint argument for size; shouldn't this be stdint.uintptr_t, to allow allocating arrays larger than 4GiB on 64-bit platforms?  Perhaps there should be a more readable basic type, such as "word/uword", which would be defined as the size of an integer register (sort of like "extended")...

-Scott

>>No bugs fixed, but added new capability to allocate memory outside of the
>>garbage collector, to appeal to programmers who want to do their own
>>allocation/deallocation.
> 
> 
> Anyone thinking to take advantage of this new functionality might find this
> paper interesting:
> 
> Reconsidering Custom Memory Allocation
> http://citeseer.nj.nec.com/berger01reconsidering.html
> 
> Rob

Nice paper, thanks for the link.  However, since I'm very interested in speed, I wouldn't use their allocator.

It looks like they've built a nice general purpose allocator, but of the 8 benchmarks, only two seem important in measuring speed: ICC, and Muddle.  These are the only two that have advanced memory allocation (region allocators) while still being significantly impacted in run-time by memory allocation.  They focused on these two at the end of the paper, and reported to be within 10% of the run-time of the region allocators in these two benchmarks.  However, the memory allocation in these programs only took 25-33% of the run-time, so you have to multiply  the difference by 3 to 4 to see the difference that region allocation makes.  That leaves their allocator at somewhere from 20-40% slower.

Let's face it.  If you need speed, region allocators rock.

Bill

"Scott Wood" <scott@buserror.net> wrote in message news:slrnb4m44u.tl.scott@ti.buserror.net...
> Are there any plans to allow non-member user-supplied new and delete functions, such as in C++?
>
> For example, one might have a special new function that allocates from a given shared memory region, or one might want to do a mark/release on a specific collection of objects or structs, regardless of type.  Currently, to do this one would have to add non-default member new()s to every class that do nothing but call the global new.
>
> Globally replacing the generic new and delete could also be useful for debugging memory leaks.

I've found in practice that replacing the global new/delete in C++ leads to bugs after bugs, generally from adding in code that expects otherwise, such as the library routines. But the member new/delete *are* inheritable, so you could define a base class and then derive all your classes from it, and they'll all use your custom allocator.

> Also, I notice that new() takes a uint argument for size; shouldn't this be stdint.uintptr_t, to allow allocating arrays larger than 4GiB on 64-bit platforms?  Perhaps there should be a more readable basic type, such as "word/uword", which would be defined as the size of an integer register (sort of like "extended")...

That's a good point.