Re: beforeGarbageCollection
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
Re: beforeGarbageCollection
On 2010-06-17 12:15:58 -0400, Andrei Alexandrescu 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.for...@michelf.com http://michelf.com/
Re: beforeGarbageCollection
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 wrote: > Michel Fortin wrote: >> On 2010-06-17 01:52:57 -0400, Andrei Alexandrescu > > > 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
Re: beforeGarbageCollection
Michel Fortin wrote: On 2010-06-17 01:52:57 -0400, Andrei Alexandrescu 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
Re: beforeGarbageCollection
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
Re: beforeGarbageCollection
On 2010-06-17 01:52:57 -0400, Andrei Alexandrescu 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.for...@michelf.com http://michelf.com/
Re: beforeGarbageCollection
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
Re: beforeGarbageCollection
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?
beforeGarbageCollection
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
