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).

-- 
Leandro Lucarella
Senior R&D Developer
Sociomantic Labs GmbH <http://www.sociomantic.com>
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

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.

According to the repo-history Sean is the author of that code, so he might have good use cases for uncommitted memory.

_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

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>
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 30 maj 2013, at 13:40, Leandro Lucarella <leandro.lucarella@sociomantic.com> wrote:

> Really? I thought this was really old, like D1 phobos old.


Most of the druntime is based on the Tango runtime which Sean wrote. I think that he started by modifying the D1 runtime and built on top of that.

-- 
/Jacob Carlborg

_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Thu, May 30, 2013 at 03:30:52PM +0200, Jacob Carlborg wrote:
> 
> On 30 maj 2013, at 13:40, Leandro Lucarella <leandro.lucarella@sociomantic.com> wrote:
> 
> > Really? I thought this was really old, like D1 phobos old.
> 
> Most of the druntime is based on the Tango runtime which Sean wrote. I think that he started by modifying the D1 runtime and built on top of that.

Yes, I also think this is how story goes, I just saw the committed memory stuff was from D1 phobos ages and Sean just kept it in Ares/Tango.

-- 
Leandro Lucarella
Senior R&D Developer
Sociomantic Labs GmbH <http://www.sociomantic.com>
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Thu, May 30, 2013 at 04:37:17PM +0200, Leandro Lucarella wrote:
> On Thu, May 30, 2013 at 03:30:52PM +0200, Jacob Carlborg wrote:
> > 
> > On 30 maj 2013, at 13:40, Leandro Lucarella <leandro.lucarella@sociomantic.com> wrote:
> > 
> > > Really? I thought this was really old, like D1 phobos old.
> > 
> > Most of the druntime is based on the Tango runtime which Sean wrote. I think that he started by modifying the D1 runtime and built on top of that.
> 
> Yes, I also think this is how story goes, I just saw the committed memory stuff was from D1 phobos ages and Sean just kept it in Ares/Tango.

This is effectively in Phobos 1 at least: https://github.com/D-Programming-Language/phobos/blob/phobos-1.x/internal/gc/win32.d#L27

My guess is this code was written when DMD was Windows only.

According to the history which I guess Brad imported first to svn and
then to Git, the code goes back to phobos 0.1, when the GC was written
in C  ;)
https://github.com/D-Programming-Language/phobos/blob/ffa1d1d7060da9f1801e0cc76eab9a2f251372ca/gc/win32.c#L22

-- 
Leandro Lucarella
Senior R&D Developer
Sociomantic Labs GmbH <http://www.sociomantic.com>
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On May 30, 2013, at 3:45 AM, Rainer Schuetze <r.sagitario@gmx.de> wrote:
> 
> 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.
> 
> According to the repo-history Sean is the author of that code, so he might have good use cases for uncommitted memory.

I think some form of that code has always been there.  If I had any goal in preserving it it was just to use only as much main memory as needed.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime