Luke Palmer <[EMAIL PROTECTED]> wrote:
> After many months of lying dormant, I figured I'd get my act together
> and adapt this patch to the few recent modifications. And this time,
> I'm posting a benchmark!
Wow, thanks.
Some comments:
> - b_PObj_needs_early_DOD_FLAG = 1 << 27,
> + /* true if this is connected by some route to a needs_early_DOD object */
> + PObj_high_priority_DOD_FLAG = 1 << 27,
> + PObj_needs_early_DOD_FLAG = (1 << 27 | 1 << 28),
Moving the needs_early_DOD_FLAG out of the arena_flags is suboptimal
(and probably the reason for the 5% slowdown for the eager case). Now the
relevant flags is the high_priority_DOD_FLAG. If I get the patch right,
it gets set on the PMC itself and all its parents.
So it would be fine, if the high_priority_DOD_FLAG would be in the
arena_flags nibble. The tests in the fast path of pobject_lives can then
go away - PMCs that can contain other PMCs can't be the parent of PMCs
that need timely destruction, so that should work. And all PMCs, that
can contain other PMCs must have a PMC_EXT attached with the next_for_GC
pointer.
And if that helps, we can just say: If an object needs timely
destruction it must have the PMC_EXT struct attached, so that marking
is out of the fast path.
>@@ -45,21 +45,45 @@
> UINTVAL *dod_flags = arena->dod_flags + ns;
> if (*dod_flags & ((PObj_on_free_list_FLAG | PObj_live_FLAG) << nm))
> return;
> + if (*dod_flags & PObj_on_free_list_FLAG << nm)
> + return;
This seems bogus, if the flag is set, the first test has succeeded.
> + if (PObj_high_priority_DOD_TEST(obj) && interpreter->dod_trace_ptr)
> + /* set obj's parent to high priority */
> + PObj_high_priority_DOD_SET(interpreter->dod_trace_ptr);
That could go probably below, if the special_PMC_FLAG is set.
>@@ -84,23 +108,38 @@
> - if (PObj_is_special_PMC_TEST(obj)) {
> + if (*dod_flags & (PObj_is_special_PMC_FLAG << nm)) {
This seems to be the non-ARENA_DOD_FLAGS case, so above doesn't work.
leo
