Re: [Gnash-dev] Garbage Collection

[strk]

On Wed, Sep 05, 2007 at 07:50:20PM +0900, Chad Musick wrote:

> A more expansive garbage collection proposal --
> 
> I think we ought to unify our garbage collection scheme, and I propose
> that we use either the attached collector or something similar.

What do you mean by 'unify' ?
We are currently using the GC for a set of objects and RC (ref-counting)
for another set.

> This GC
> would run concurrently with the rest of the program and require some
> basic support from the objects code, as I'll explain. The following
> classes are defined:
> 
> GC -- the garbage collector itself, a singleton accessed only through
> static functions.

Would this be appropriate even in case we'll support multiple VMs ?

> GC_runner -- Also a singleton, this is the thread which runs
> continuously for garbage collecting.
> 
> GcResource -- the base class from which (I think) all objects which
> might ever be dynamically allocated ought to derive.

You mean you want to have *everything* managed by the GC ?
The choice to keep RC for things w/out circular refs problem was to
reduce overhead of the marking phase. Of course if your solution happens
to run faster no problem here. I guess it's hard to compare w/out an
implementation though...

> Allocating new GcResources
> ==========================
> A GcInvoke object should be on the stack when new GcResource objects are
> heap allocated.  The GcInvoke object either 'on' or 'off'. ('on' is the
> default). If it is on, the newly allocated memory will be managed by the
> Gc. If it is off, the newly allocated memory must be managed by hand.

So, to recap, a developer can choose when to leave management of a GcResource
to the garbage collector and when to manage outside of it ?

> When all GcInvoke objects have gone out of scope (they may be nested),
> any GcResource objects which were heap allocated in the scope of an 'on'
> GcInvoke is added to the list of managed objects.
> 
> By constructing in this way, the newly allocated resources don't face
> the possibility of collection until they have had a chance to be placed
> into a reachable state. 

What if they get registered when assigned to a GC-aware smart pointer ?
Doing so any dumb-pointer will never be registered with the GC and we'd use
gc_ptr as class members.

> Instead, the following code is used:
>   { // Scope.
>     GcInvoke GcI;
>     SomeGcClass *p = new SomeGcClass;
>     p->do_something();
>     this->markable_member = p;
>     /* It would be safe to manage p from here, if it is safe to manage
> 'this' */
>   } /* GcInvoke falls out of scope. 'p' is as safe as 'this'. Since
> GcInvoke objects stack, 'p' is only managed once 'this' is managed. */

In the suggested interface above the code would be something like:

struct MyMarkableResourceContainer {

        GcManagedPtr<SomeGcClass> markable_member;

        void doSomething1()
        {
                SomeGcClass* p = new SomeGcClass; // manually managed
                p->do_something();
                markable_member = p; // safe from now on ?
        }

        void doSomething2()
        {
                markable_member = new SomeGcClass; // safe from now on ?
                markable_member->do_something();
        }

        void doSomething3()
        {
                std::auto_ptr<SomeGcClass> p ( new SomeGcClass ); // manually 
managed
                if ( p->do_something() )
                {
                        markable_member = p.release();  // or = p, implementing 
assignmnt op from auto_ptr..
                }
                // else, SomeGcClass released by auto_ptr destructor
        }

};

> A Caveat: It is NOT safe to spawn a new thread inside the scope of a
> GcInvoke. (Strictly speaking, any dynamic resources allocated in a
> spawned thread must provide for their own safety, and not rely on
> 'this'.)
> 
> Marking GcResources
> ===================
> Objects do not need to be immutable while they are being marked, except
> that the _structure_ of any containers which hold GcResource objects
> must not be changed while the object is being marked.

I don't understand this, can you provide an example, and explain why ?

--strk;