At 11:40 PM 4/8/2002 -0400, Michel J Lambert wrote:
> > 2) I'm thinking of an internal stack not visible to user code that we use
> > for temporary PMCs and Buffers and a simple macro for entry and
> > exit of GC sensitive routines. I think I might have mentioned this.
>
>What defines a GC-sensitive routine? Anything that does string manip, pmc
>manip, or any allocations, is marked GC-sensitive?
Ok, thats a really general phrase I used. :)
I agree we need an overall architectural solution. Setting and clearing
bits manually is error-prone but fast, as you said. Its identical to
the malloc()/free() situation which is one of the primary reasons we
use garbage collection in the first place, so why reinvent the same
situation with different syntax?
malloc/free is vulnerable to:
1) leakage (forgot to free)
2) double deallocation (freed an already freed buffer)
So is setting/clearing GC bits.
I was thinking of a solution that didn't require tracking every single
allocation. Keep in mind I'm just tossing about an alternate point of
view for sake of discussion.
I suppose a variation of the scratch-pad that might be more on the
performance line that you are thinking could be similar to the
scope tracking that compilers do when gathering symbols into
symbol tables.
Keep track of global (or interpreter local) scope with a macro
upon entry.
#define GC_NEWPAD() cur_interp->scope++
#define GC_CLEARPAD(s) cur_interp->scope = s
So a GC-able buffer gets created with a intial scope of cur_interp->scope,
hidden in the allocator, and the collector skips collect on any
buffer with scope <= the cur_scope.
>Two things:
>
>First, we now have a GC_DEBUG define that we can turn on to find all
>places the GC could cause problems. In the current state, I think it
>covers 90% of the problems (one problem is that if I conditionally
>call string_make, this function isn't guaranteed of triggering GC in
>a test case, like it should.)
>
>However, if we can't find all the places we do buffer manipulation to mark
>them immortal, how are we going to properly identify all the GC-sensitive
>functions?
>
>Secondly, setting a flag should be much quicker, speed-wise. We'd only be
>setting flags on buffer headers that are already in the CPU cache, as
>opposed to writing to memory in this stack, pushing and popping all the
>time. And if we macro-ize the setting of the flags, I don't think it
>should look nearly as bad. GC_MARK(Buffer), GC_UNMARK(Buffer), etc.
Fair enough on the speed point, however you have to remember for
every object you are handling to (1) mark it, (2) unmark it after attaching
it to the root set.
One the other hand, what if we could say
{
orig = GC_NEWPAD();
x();
y();
z();
GC_CLEARPAD(orig);
}
and know that anything in between newpad to clearpad would be
safe and be free to write normal code even with GC churning.
And there is no stack churn.
I know there's been little activity in the past week...as far as my
>activity, I'm waiting for the Dan to come back tomorrow, and tell us
>minions what the plan is for GC stuff. Peter and I fixed most of the GC
>bugs that are easily fixed, but the rest require a more architectural fix,
>something I think we all are deferring to Dan on.
Agreed. However, more discussion around here is a good thing. :)
-Melvin
