GC.calloc

Marco Leise Marco.Leise at gmx.de
Fri Jul 19 10:32:29 PDT 2013


Am Thu, 18 Jul 2013 13:00:24 +0200
schrieb "Vladimir Panteleev" <vladimir at thecybershadow.net>:

> On Thursday, 18 July 2013 at 09:55:15 UTC, David wrote:
> > I use it all the time, e.g. I have an array of blocks 
> > (65536*12Byte) and
> > I don't want the GC to care about this chunk of data (since it 
> > exists up
> > to 961 times) but I can't just have it filled with random data 
> > ->
> > calloc. Often when I was relativly new to C I always called 
> > malloc
> > followed by a memset to 0, until I learned about calloc (but 
> > that's
> > getting offtopic).
> 
> calloc may still be useful as a stand-alone function. The 
> question is whether it makes sense to be part of the GC 
> interface, which all GCs need to implement. I think it only makes 
> sense if some GC implementations have knowledge that allows them 
> to return 0-filled memory without actually filling it all (e.g. 
> if it is known that the OS does it for them).

The calloc implemented in Linux only works like the GC.calloc
up to ~24 MiB or so. After that it does neither set anything
to zero nor does it allocate physical memory. It just gives
you X references to a read-only page filled with zeroes, that
is marked copy-on-write.
Thus with C calloc you can allocate gigabytes of "zero
initialized" memory in an instant.
But the real benefit with the C calloc > ~24 MiB is that the
memory pages don't consume RAM until you write to them.

-- 
Marco



More information about the Digitalmars-d mailing list