[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] Garbage Collection
From: |
strk |
Subject: |
Re: [Gnash-dev] Garbage Collection |
Date: |
Wed, 19 Sep 2007 23:25:10 +0200 |
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;