RFR: 8227269: Slow class loading when running JVM in debug mode

[Roman Kennke]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20191219/040d273b/signature.asc>