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
signature.asc
Description: OpenPGP digital signature
