Alright, the perfectionist in me got me. I am implementing the even more efficient ~O(1) class tracking. Please hold off reviewing for now.
Thanks,Roman Hi Chris, > >> 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 have some ideas how to improve the implementation to ~O(1) but it > would be considerably more complex: have to maintain a (hash)table that > maps tags -> KlassNode*, unlink them directly upon unload, and build the > unloaded-signatures list there, but I don't currently see that it's > worth the effort). > > In addition to all that, this process is only activated when there's an > actual listener registered for EI_GC_FINISH. > > Thanks, > Roman > > >> Chris >> >> On 12/18/19 5:05 AM, Roman Kennke wrote: >>> Hello all, >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8227269 >>> >>> I am proposing what amounts to a rewrite of classTrack.c. It avoids >>> throwing away the class cache on GC, and instead keeps track of >>> loaded/unloaded classes one-by-one. >>> >>> In addition to that, it avoids this whole dance until an agent >>> registers interest in EI_GC_FINISH. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rkennke/JDK-8227269/webrev.01/ >>> >>> Testing: manual testing of provided test scenarios and timing. >>> >>> Eg with the testcase provided here: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1751985 >>> >>> I am getting those numbers: >>> unpatched: no debug: 84s with debug: 225s >>> patched: no debug: 85s with debug: 95s >>> >>> I also tested successfully through jdk/submit repo >>> >>> Can I please get a review? >>> >>> Thanks, >>> Roman >>> >> >> >
signature.asc
Description: OpenPGP digital signature
