harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [jira] Created: (HARMONY-4511) [drlvm][jvmti][gc] GC_gen doesn't collect tagged objects
Date Fri, 27 Jul 2007 11:02:15 GMT
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.

> 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


View raw message