Hi Coleen,

>>> I'll have a look at this, although it might not be for a few days. In
>>> the meantime, maybe you can describe your new implementation in
>>> classTrack.c so it's easier to look through the changes.
>> Sure.
>>
>> The purpose of this class-tracking is to be able to determine the
>> signatures of unloaded classes when GC/class-unloading happened, so that
>> we can generate the appropriate JDWP event.
>>
>> The current implementation does so by maintaining a table of currently
>> prepared classes by building that table when classTrack is initialized,
>> and then add new classes whenever a class gets loaded. When unloading
>> occurs, that cache is rebuilt into a new table, and compared with the
>> old table, and whatever is in the old, but not in the new table gets
>> returned. The problem is that when GCs happen frequently and/or many
>> classes get loaded+unloaded, this amounts to O(classCount*gcCount)
>> complexity.
>>
>> The new implementation keeps a linked-list of prepared classes, and also
>> tracks unloads via the listener cbTrackingObjectFree(). Whenever an
>> unload/GC occurs, the list of prepared classes is scanned, and classes
>> that are also in the deletedTagBag are unlinked (thus maintaining the
>> prepared-classes-list) and its signature put in the list that gets
>> returned.
>>
>> The implementation is not perfect. In order to determine whether or not
>> a class is unloaded, it needs to scan the deletedTagBag. That process is
>> therefore still O(unloadedClassCount). The assumption here is that
>> unloadedClassCount << classCount. In my experiments this seems to be
>> true, and also reasonable to expect.
> 
> I don't know if you should use this, but I recently fixed the
> ClassUnload Jvmti Extension event to return the name of a class that's
> unloaded.

That sounds interesting. Which change is that? How would I use it?

Thanks,
Roman

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to