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 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 next 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