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 Fri, 27 Jul 2007 12:30:49 GMT
On 7/27/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
> Xiao-Feng Li wrote:
> >> What does prevents putting tags into the objects directly, is the requirement
> >> to enumerate tagged objects quickly, as this is likely to be used by memory
> >> profilers, and the performance of O(tagged) is much more preferrable than
> >> O(all objects). Current implementation puts a pointer to a native tag
> >> structure into objects.
> >> Xiao Feng, what other solutions do you consider?
> >
> > 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. 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. In this way,
> > there is no need to keep a seperate weakroot list for those tagged
> > objects. In my understanding, the weakroot list is almost a loyal copy
> > of the tagged objects' list.(?) So I want to reuse it rather than
> > create an additional copy. This is Occam Razor principle. :-)  (Btw, I
> > haven't thought this solution deeply yet.)
> >
> > This is similar to weakroot, but the difference is, if most of tagged
> > objects are dead, the GC data structure can be kept very small. Well I
> > know nothing about the behavior of tagged objects. If the assumption
> > is not true, it can use weakroot.
>
> 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.

Gregory, in this case (very long list of tagged objects in VM), it
looks like my suggested solution will outperform the weakroot
solution, since it doesn't reproduce a similar list in GC (as weak
roots do). GC only calls back to VM, lets VM to traverse the tagged
objects.

Actually the assumption I mentioned is only an optimization. That is,
if lots of tagged objects are found dead in the VM callback, they can
be removed off from the VM tagged objects list immediately. Then the
remaining objects in the list are sure to survive, and this list is
much shorter for later moved-objects reference updating.

I am not sure if I described my idea clearly. Or I should draw a graph
to illustrate it?

Thanks,
xiaofeng

> > For fatlock (a native structure hold by a Java object) reclamation,
> > our approach in GC is to notify the VM for every live object when it's
> > traced. The VM will mark the notified fatlock as live. And after GC,
> > another callback to VM will clean up the unmarked fatlocks.
> >
> > For class unloading, the situation is different again. 1. classes are
> > mostly live across collections; 2. there is no simple single list to
> > traverse after GC marking. 3. there are more logics involved. So
> > weakroot is probably appropriate for class unloading.
> >
> > I am open to any solution suggestions. I only want to have more
> > understanding of the situation of a native resource before taking a
> > solution for granted. People are prone to choose weakroot solution
> > sometimes only because weakroot is there, while weakroot is not
> > necessarily to be the best solution.
> >
> > Comments?
> >
> > Thanks,
> > xiaofeng
>
>
> --
> Gregory
>
>


-- 
http://xiao-feng.blogspot.com

Mime
View raw message