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