At 06:10 PM 4/8/2002 -0700, Steve Fink wrote:
>On Mon, Apr 08, 2002 at 07:01:44PM -0400, Melvin Smith wrote:
> > At 05:49 PM 4/8/2002 -0400, Roman Hunt wrote:
> > > find the definition for the string_vtable it is not in
> >
> > Try classes/perlstring.pmc
> >
> > Keep in mind there is the primitive STRING type which is the S* registers,
> > and then there is the PMC (PerlString) which uses vtables.
>
>The primitive STRING also uses a vtable (for the different encodings).
>That's in include/parrot/encoding.h.
Don't mind me, I'm 75% fact and 25%......well
> > If you make calls to subroutines that may trigger a GC_collect()
> > then the STRING you had might be moved or collected.
> >
> > For now the safest is the 'immortal' bit or stashing the STRING in a
> > register so the root set can see it.
>
>And if the C string belongs to someone else, you may need to set the
>BUFFER_external_FLAG flag.
>
> > However, if all you are doing is allocating the STRING then doing a lot of
> > known ops and/or system calls that don't thread into the GC,
> > there is nothing to bother with.
>
>This message does remind me of how empty the TODO list is. Surely we
>can think of many more things to be done?
Speaking of..
1) Bugfix release please, we banged quite a few stack and GC bugs out.
Don't we get any dessert?
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.
p = gcsaveframe();
yada
yada
yada
gcrestoreframe(p);
This "scribble pad" stack is part of the root set so I think its self
explanatory.
Even if messy code scribbles too much on the stack, as long as the outer
scopes restore the stack frame, it'll be kept in check.
So..
foo_alloc() {
marker = gcsaveframe();
bar_alloc();
gcrestoreframe(marker);
# All cleaned up
}
# bar_alloc might be messy and return without restoring.
bar_alloc() {
mymarker = gcsaveframe();
yada();
return;
}
There isn't anything really innovative here, its the same way we handle normal
stacks, yet its just implicit because the pushes are hidden in the PMC and
buffer allocators.
I'm not a GC design guru, but the limited reading I've done on JVM hints that
they do something similar.
Then again, I haven't thought about how this works with threads, I suppose
the stack would have to exist in TLS.
I'd like something like this rather than hoping all developers can
systematically
set bits or handle references correctly because in reality we'd probably
never catch all the cases.
-Melvin
