[D-runtime] Committed and uncommitted memory in the GC
Leandro Lucarella
leandro.lucarella at sociomantic.com
Thu May 30 04:40:16 PDT 2013
On Thu, May 30, 2013 at 12:45:19PM +0200, Rainer Schuetze wrote:
> On 29.05.2013 19:23, Leandro Lucarella wrote:
> >In CDGC I completely removed the distinction between committed and
> >uncommitted memory. This is only useful for Windows AFAIK, but is
> >currently handled as an integral part of the GC as if it were something
> >all the OSs use. Besides making the code a little bit more complex, it
> >has some performance impact (involves some bit manipulation and
> >reading).
> >
> >Do you think the price we pay for this is justified or will you be
> >opened to remove the distinction between committed and uncommitted
> >memory from the GC? (in Windows, the os_mem_alloc function will
> >automatically commit the memory too and the deallocation will decommit
> >it).
>
> Considering that (apart from very large user allocations that need
> committed memory anyway) the maximum pool size is currently only 32
> MB (though I think this should be configurable), it doesn't make
> much sense to me to distinguish between committed and uncommitted
> memory. It is probably also more efficient to allocate committed
> memory than to commit it in separate steps for every 64kB.
I already made a pull request, it wasn't that much work and I think it
will be much easier to discuss if people can try the actual change
instead of theorize in the air.
> According to the repo-history Sean is the author of that code, so he
> might have good use cases for uncommitted memory.
Really? I thought this was really old, like D1 phobos old.
--
Leandro Lucarella
Senior R&D Developer
Sociomantic Labs GmbH <http://www.sociomantic.com>
More information about the D-runtime
mailing list