beforeGarbageCollection

[Sean Kelly]

The GC will collect if it can't find memory for the requested allocation
in tts internal pool. If the collection doesn't improve the situation
the the GC will obtain more memory from the OS. So onLowMemory could
occur before every collection or once memory use has reached some fixed
threshold. 

Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
> Michel Fortin wrote:
>> On 2010-06-17 01:52:57 -0400, Andrei Alexandrescu >
> > <SeeWebsiteForEmail at erdani.org> said:
>>>> I'm thinking of a feature that would improve the memory footprint
> > > > of D >> programs. Say druntime provided a function:
>>> 
>>> void beforeGarbageCollection(void delegate() callMe);
>>> 
>>> The runtime would guarantee that callMe gets called before any >>
> > > collection. That would allow modules to clean up caches (e.g. free
> > > >> lists) to improve their memory profile.
>>> 
>>> Any thoughts, please share.
>>> Hum, cleaning up caches will reduce the memory used, but not using a
> > > > cache will too.
> 
> I agree :o).
> 
>> If you use a cache, it's probably because you need one > to improve
> > performance, so it may have an adverse effect on performance > if
> > you clear caches at every collection cycle. Are collections only
> > done > when you're low on memory? I doubt it. It'd be more useful I
> > think to > have a callback for when you're actually low on physical
> > RAM (because > swapping caches to disk through virtual memory is
> > quite unproductive).
> 
> I think currently collections occur only when you're low on memory,
> but even if not, they'd be rare. But I agree with you that a name like
> onLowMemory is better, and supports incremental garbage collectors
> that don't start at a specific time.
> 
>> On a side note, that looks like how things work on the iPhone: your >
> > application receives a memory warning when memory is near-exhausted,
> > and > it should release the unessential memory it holds. For
> > instance, what > Mobile Safari does when it receives a memory
> > warning is to flush the > cached representation of the non-frontmost
> > tabs, except for the URL and > a small previous picture; when you
> > switch back to another tab, it has to > reload the content.
> 
> Cool.
> 
>> I'm also wondering if the idea of using a *callback* for this is
> > really > a good idea. If you're in the process of updating a cache,
> > you call > 'new', it trigger the garbage collector which reentrantly
> > asks your > cache to clear itself, won't this easily become trouble?
> > Apple use an > event for this on the iPhone, which is handled by the
> > event loop of the > application; perhaps a low memory *message*
> > could be sent to all the > threads that are listening to the message
> > passing system, this would > avoid the reentrancy issue and would
> > work better with multithreading.
> 
> I was thinking new would throw if called from within a callback. These
> are known solutions.


Andrei