harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [jira] Created: (HARMONY-4511) [drlvm][jvmti][gc] GC_gen doesn't collect tagged objects
Date Mon, 30 Jul 2007 09:28:02 GMT
On 7/30/07, Salikh Zakirov <salikh.zakirov@gmail.com> wrote:
> Xiao-Feng Li wrote:
> > I had thought to have a hook to VM invoked after GC marks all live
> > objects, where the VM traverses the tagged objects' list and query GC
> > for the object liveness info. If an object is dead (unmarked), its
> > reference in the list is nullified.
> I think similar idea was considered and prototyped in GCv4 for class unloading.
> If the same hook can be used for tags, it looks even better.

Great minds think alike! :-)

> /**
>  * 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.

> > 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

> 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.


> What's more, this scheme will allow to keep the finalization queue in VM too.
> (Currently the live finalization queue is kept in GC, and transferred to VM as
> objects become eligible for finalization)

Good idea! While it requires some substantial changes in current
finref subsystem implementation, the idea sounds more intuitive than
existing queue transference design.

> Gregory Shimansky wrote:
> > The nature of the tagged objects is completed up to the JVMTI agent
> > which tags or untags them. The agent is the VM resident part of a memory
> > profiler that user would run, so it is up to the user to specify which
> > objects he's interested in. So there is no assumption about how live the
> > tagged objects are going to be, it depends on the user who controls the
> > profiler and the user's needs to profile the memory usage.
> >
> > One thing I am afraid of, is that the list of tagged objects may be very
> > big. JVMTI allows tagging whole classes of objects by tagging the
> > j.l.Class instance for the class but this is the only optimization
> > possible not to tag big numbers of objects.
> Some time ago, I've heard of someone trying to tag _every_ object on the heap.
> Obviously, it incurred tremendous overhead (they didn't try DRLVM), but still
> was usable in their experiments.

This is worth testing with DRLVM once the implementation is done.



View raw message