[Issue 2858] D specs allow GC implementations that don't call finalizers

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=2858





------- Comment #9 from llucax at gmail.com  2009-04-20 07:25 -------
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #3)
> > > SDWF tries to get around this by running a collection if creation of a GDI
> > > object fails, in case it frees some system resources in order to try again. 
> > > But maybe what we really need is some kind of monitoring system.  How does
> > > DMD's GC decide when to run, anyway?
> > 
> > Collection is triggered by gc_malloc() when no free space can be found.
> 
> So it waits until the system runs out of memory before trying to free some? 
> This way, D programs are almost bound to run down system memory, denying it to
> other programs, sooner or later.  If you're running several programs that rely
> on this gc_malloc implementation or similar, at a given time one of them is
> likely to be at or near its peak in memory consumption.  Generally speaking,
> one program's memory demand cannot trigger another program to collect its
> garbage.

It doesn't. gc_malloc() uses an internal pool of memory, when no memory in
*that* pool is not found, the collection is triggered, if that collection
couldn't find some free memory, then the GC ask the OS for some more. So nobody
can trigger a collection but the program itself.

Anyway, this is a little off-topic. This bug report is not about that =)


--