Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
>>
>> Can you summarize your scheme again please WRT this and other
>> enhancements. I'm somewhat lost in all the improvements that were
>> proposed since your original.
> Alright, here's a patch that implements it.
Wow.
Some remarks:
First of course did you test & benchmark it? Please ...
(Allocate 10^x PMCs into some aggregates. Then: set active object(s) in
the root set, then do 2 or 3 "sweep 1" for cache settling, then time a
"sweep 1" against a "sweep 0". The same with some active objects deeper
buried inside a nested structure)
> Bear with me, because I don't know my way around the DOD very well.
> First, do I increment num_early_DOD_PMCs in the right place? That's
> where it was set to 1 before...
Looks good.
I didn't look, but do you decrement the counter, when such an object
gets destroyed?
> Also, the critical block that makes this an optimization is missing,
> marked with an XXX. I didn't implement it because I don't really know
> the control flow of DOD, so I didn't know how to abort cleanly. Can
> someone give me some hints here?
It should probably be inside trace_children's loop. Then, when you have
all your num_early_DOD_PMCs seen, you just leave the loop for the lazy
case. That's it.
Please note: you don't have to worry about GC. It might be inefficient
to move already dead object buffers around, but this is the way its done
currently. (Another thing to benchmark - though)
> Other than those few, but unignorable, caveats, Enjoy!
> + && interpreter->dod_trace_ptr) {
> + /* put it at the head of the list */
> + }
> + else {
> + /* put it on the end of the list */
/Me thinks, Dan will not like that part. Seems to break his
serialization scheme.
leo
