On 7/30/07, Salikh Zakirov <[EMAIL PROTECTED]> 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 parameter. > 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. > 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. Thanks, xiaofeng -- http://xiao-feng.blogspot.com
