From: Nikodemus S. <nik...@ra...> - 2009-01-18 12:43:15
Attachments:
0001-SB-EXT-BEFORE-GC-HOOKS.patch
|
The attached patch implements my take on *BEFORE-GC-HOOKS*: SB-EXT:*BEFORE-GC-HOOKS* * Add back. Run without holding locks, with interrupts enabled, and *GC-PENDING* set. * Run both before and after GC hooks only before and after the outermost call to SUB-GC: if hooks or finalizers cause a nested GC, the hooks don't run for the nested one. (Finalizers still do.) This allows sane pairing of before and after hooks, and reduces the danger of exceeding interrupt nesting limit. No extensive testing done. Comments from those (*cough* James *cough*) who use similar locally patched hooks welcome. Cheers, -- Nikodemus |
From: Gábor M. <me...@re...> - 2009-01-18 19:39:00
|
On Domingo 18 Enero 2009, Nikodemus Siivola wrote: > The attached patch implements my take on *BEFORE-GC-HOOKS*: > > SB-EXT:*BEFORE-GC-HOOKS* > > * Add back. Run without holding locks, with interrupts enabled, > and *GC-PENDING* set. > > * Run both before and after GC hooks only before and after the > outermost call to SUB-GC: if hooks or finalizers cause a > nested GC, the hooks don't run for the nested one. (Finalizers still > do.) > > This allows sane pairing of before and after hooks, and > reduces the danger of exceeding interrupt nesting limit. > > No extensive testing done. Comments from those (*cough* James > *cough*) who use similar locally patched hooks welcome. > > Cheers, > > -- Nikodemus Don't you need an allow-with-interrupts for that with-interrupts to actually do something? In general, the problem with this patch is that in a multithreaded environment there is often a race to do gc between threads. When acquiring the lock it should be checked that *gc-pending* is still not nil, and punt on gc if it is. This is to avoid a lot of unneeded gcs. Naturally the after gc hooks should only be run if gc was done in that thread. Same for before gc hooks. How to run the before hooks only when it's decided that gc will actually be done in this thread (i.e. holding the *already-in-gc* lock with *gc-pending*), I don't know. All in all, sub-gc needs fixing as it is and once fixed it will become apparent that before hooks are not an easy add on. At least, I don't see how they can be supported. I'm in doing a cleanup of signal handling and gc triggers (needless to say there are a few bugs there), touching sub-gc as well. I'm aiming to commit it early 1.0.25.xxx. Things may be a bit clearer by then. Cheers, Gabor |
From: Nikodemus S. <nik...@ra...> - 2009-01-19 06:17:55
|
Ooops, to the list as well. ---------- Forwarded message ---------- From: Nikodemus Siivola <nik...@ra...> Date: Mon, Jan 19, 2009 at 8:17 AM Subject: Re: [Sbcl-devel] patch: SB-EXT:*BEFORE-GC-HOOKS* To: Gábor Melis <me...@re...> On Sun, Jan 18, 2009 at 9:38 PM, Gábor Melis <me...@re...> wrote: > Don't you need an allow-with-interrupts for that with-interrupts to > actually do something? Not unless WITHOUT-INTERRUPTS is broken: if WITH-INTERRUPTS is lexically nested within the only WITHOUT-INTERRUPTS, no A-W-I is needed. > In general, the problem with this patch is that in a multithreaded > environment there is often a race to do gc between threads. When > acquiring the lock it should be checked that *gc-pending* is still not > nil, and punt on gc if it is. This is to avoid a lot of unneeded gcs. > Naturally the after gc hooks should only be run if gc was done in that > thread. Same for before gc hooks. How to run the before hooks only when > it's decided that gc will actually be done in this thread (i.e. holding > the *already-in-gc* lock with *gc-pending*), I don't know. I don't quite agree: even if the GC is punted, the hooks could be run. Call it a trivial GC if you will. My reasoning is that I don't see how both could be elided unless we allow user code to run while holding the lock, and we want to make them it possible to pair them for statistics-gathering, etc. > All in all, sub-gc needs fixing as it is and once fixed it will become > apparent that before hooks are not an easy add on. At least, I don't > see how they can be supported. > > I'm in doing a cleanup of signal handling and gc triggers (needless to > say there are a few bugs there), touching sub-gc as well. I'm aiming to > commit it early 1.0.25.xxx. Things may be a bit clearer by then. Ok, I'll hold off on this till then. Cheers, -- Nikodemus |