beforeGarbageCollection

[Andrei Alexandrescu]

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