www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - beforeGarbageCollection

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.


Andrei
Jun 16 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 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.

Thread local or thread global?
Jun 17 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 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.

Thread local or thread global?

Good question! I think it's thread-local because the whole point is to clear thread-local caches. The function could be called during execution of new within a thread. Andrei
Jun 17 2010
prev sibling next sibling parent Bane <branimir.milosavljevic gmail.com> writes:
Andrei Alexandrescu Wrote:

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

void beforeGarbageCollection(bool delegate() callMe); Maybe return value indicating should collect cycle be executed or skipped only that once? There might be some cases that it can be useful. Just my 2c
Jun 17 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-06-17 01:52:57 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail 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. 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). 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. 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. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jun 17 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2010-06-17 01:52:57 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail 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
Jun 17 2010
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
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 erdani.org> wrote:
 Michel Fortin wrote:
 On 2010-06-17 01:52:57 -0400, Andrei Alexandrescu >
 <SeeWebsiteForEmail 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
Jun 17 2010
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-06-17 12:15:58 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 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.

I wasn't thinking about calling 'new' from within the callback. The problem is more that you have to deal with reentrancy while you work in the cache data structure. For instance, let's say I use a AA for a cache. Then I add an element to the cache. Adding one element might call the GC to get more memory, so it has the potential to call the low memory callback every time you add something to it. So while implementing the AA you must be extra careful so that the data structure invariants for the cache holds at all times, even in the middle of a function, when you have a line of code that may call new (directly or indirectly), and you must recheck your assumptions about that structure after every memory allocation because the callback might have tampered with it. That sounds troublesome... it's akin to a race condition, but with a single thread. I won't say the callback can't be useful. But if I were using it, I wouldn't do any work in the callback. Instead, I would raise a flag somewhere that the program can check the next time it enters into a state where it's safe to clear the caches. In an event-driven application, that would be the event loop. In a program with multiple threads, a good strategy might be to ask idle threads to clear their thread-local caches instead of the one which is currently working. Having a callback could enable such a strategy, and many others, so I'll admit it's a good idea. But it should be used with caution. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jun 17 2010
prev sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Andrei Alexandrescu, el 17 de junio a las 09:15 me escribiste:
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,

It does, but when is low on it's own pools of memory, not when the physical memory is low, as Michel suggested. I agree with Michel, it's pointless to clear some cache because a collection was triggered, it's only useful only when the physical memory is exhausted, but even then, you can't assume much from it. For example Linux makes a heavy use of physical memory for disk cache, so even when you might have little physical memory available, a lot can be used by disk cache, and would you really want you give up your own cache for the OS disk cache? I'm not so sure... It's a really delicate issue... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Peperino nos enseña que debemos ofrendirnos con ofrendas de vino si queremos obtener la recompensa de la parte del medio del vacío. -- Peperino Pómoro
Jun 17 2010