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