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 06:31:27 GMT
Salikh, we missed you here. Welcome back! :-)

On 7/27/07, Salikh Zakirov <salikh.zakirov@gmail.com> wrote:
> On Tue, Jul 24, 2007 at 01:18:24PM +0400, Gregory Shimansky wrote:
> > >On 7/23/07, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> > >>> These object references are enumerated as weak
> > >>There might be a coincidence with the message Harmony VM continues to
> > >>print:
> > >>The GC did not provide gc_add_weak_root_set_entry()
> I think the analysis by Alexei is correct.
> GC_gen does not implement weak roots, so the VM emulates it using
> regular gc_add_root_set_entry() function, and the tagged objects
> end up not being collected at all.
> The last boolean parameter to gc_add_weak_root_set_entry() is not relevant,
> as Gregory correctly pointed out, as it controls only if the weak root will
> behave as weak reference or as phantom reference, i.e. will be reset as soon
> as objects becomes unreachable for the first time, or only after its
> finalization has completed.

So it should be the second case: the reference will be nullified after
Actually I think the last parameter probably should be removed from
the interface.

> > Other solution would be to allocate tags inside of objects themself
> > inside of heap, but there is a big problem with it because spec states
> > that tags are local to JVMTI environment. If an agent creates many
> > environments, or if there is more than JVMTI agent, it may be necessary
> > to associate different environments with the same object.
> Many environments requirement is not a real problem, at least current
> implementation allows using tags only for one environment, and returns
> "not available" code for all other environment attempting to request this
> capability.
> 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.

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.



View raw message