harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [jira] Created: (HARMONY-4511) [drlvm][jvmti][gc] GC_gen doesn't collect tagged objects
Date Wed, 08 Aug 2007 20:21:13 GMT
Good solution.

On 7/30/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> On 7/30/07, Salikh Zakirov <salikh.zakirov@gmail.com> wrote:
> > /**
> >  * GC calls this function in stop the world state when all live objects
> >  * are marked. This is the callback to classloader allowing it to
> >  * gather needed statics for class unloading.
> >  *
> >  * @sa gc interface functions: gc_get_next_live_object(void *iterator)
> >  */
> > VMEXPORT void vm_classloader_iterate_objects(void *iterator);
> I'd suggest a more general interface, something like
> vm_callback_for_native_resources(int flag). Then vm can call different
> modules in order for various resources.

And the VM will inspect liveliness for its list with a cheap call like ?

GCEXPORT bool gc_is_object_live( Managed_Object_Handle *ref);

> > > Depending on the collection
> > > algorithm, GC will call back to VM later again, where VM traverses the
> > > list again and updates the moved objects' references.
> >
> > I would say, that you can add the surviving tagged object pointers as regular
> > roots at this stage, and thus avoid requiring any more interface functions.
> This is possible. But the impact depends on two factors: 1) if the
> original list in VM is very long normally; 2) if most objects in the
> list are dead after marking. If most are dead, this short-list for
> live objects can be efficient; otherwise, if more are live, this list
> would be equally long as the original list in VM. In the latter case,
> it would be ok to call a VM hook. It actually doesn't require a new
> interface, since it can reuse the interface above with a flag
> parameter.

In some cases like class unloading, the VM might usually treat these
as strong roots but weaken the reference ( by either scheme ) for
specific GC cycles. The survivors would then again be strong roots in
the VM in some future cycles. So there "may" not be too much
duplication in the secondary roots scheme, if I understand right. But
it is more flexible to keep the post hook.

> > Effectively, adding a 'live objects marked' callback and allowing to add more
> > roots at that stage (continuing the tracing, maybe even calling the callback
> > again) allows us to implement kind of weak roots in VM.
> Agree.

View raw message