harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <salikh.zaki...@gmail.com>
Subject Re: [jira] Created: (HARMONY-4511) [drlvm][jvmti][gc] GC_gen doesn't collect tagged objects
Date Mon, 30 Jul 2007 08:21:47 GMT
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.

 * 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);

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

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)

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.

View raw message