Re: Re: my garbage collector sucks

"Greg Ewing" <[email protected]> wrote

> Mark Hahn <[email protected]>:
>
> > I have continuous tracing (mark and sweep) due to my locking objects.
> > He must have to stop the interpreter when he garbage collects because
> > Parrot doesn't have locking objects.
>
> Even with object locking, I don't see how you can get away with not
> stopping the world while you're doing a mark pass.  What ensures that
> the marker doesn't miss anything if links can be changing while it's
> running?

Believe me, I am fully aware of this.  If I accidently let an object not be
included in the container hierarchy in my C code for one instruction it can
and will dissapear right out from under me.  I use a dual opteron
workstation for my testing so for most single-threaded test programs I have
an entire CPU doing nothing but running through marking and sweeping.

I have a bit in the object called del_lock.  You set this to temporarily
protect the object from the garbage collector while you are in the middle of
manipulating pointers etc.  The bit is set when the object is first created
or it would die instantly after birth.  You usually don't have to use the
del_lock bit if you are careful to put the object in the new location before
removing it from the old location in a move for example.

I just realized that in a move you could get in trouble if the GC visited
the new location, you moved from old to new, then the GC visited the old.
I'm surprised I haven't seen a problem like this.  I'll have to look into
why this hasn't happened.  I guess this is the kind of problem you are
asking about.

So the short answer is that it is the C programmer's responsibility to make
sure the object is always linked up.  Note that I am only talking about the
C coder.  In the Prothon language this is never an issue of course.

Now the question I have to revisit is "can I guarantee this can be done
reliably".

Thanks for the heads up...