RFR: JDK-8074696: Remote debugging session hangs for several minutes

Andreas Eriksson andreas.eriksson at oracle.com
Wed Oct 21 12:05:44 UTC 2015


Hi,

Please review this change to JDI/JDWP to address two performance 
bottlenecks for high delay networks.

Bug:
8074696: Remote debugging session hangs for several minutes
https://bugs.openjdk.java.net/browse/JDK-8074696

Webrev:
http://cr.openjdk.java.net/~aeriksso/8074696/webrev.00/

This change fixes two problems:

1) VirtualMachineImpl.findBootType loops over all loaded classes and 
does a remote call to check if the signature matches.
It will wait for the server response for each class before moving on to 
the next class, thus for many classes and high delay this will take a 
long time.

Solution:
Since we have a signature that should match, use 
retrieveClassesBySignature command that only returns matching classes.
At worst we have to loop over the number of active classloader since we 
want the class loaded by the boot classloader (null class loader);
This is the changes to VirtualMachineImpl.java.

2) ClassLoaderReferenceImpl.visibleClasses requests all the classes 
visible from a specific classloader, and then proceeds to add them to a 
lookup table based on signatures.
The jdwp command for visibleClasses doesn't include signature 
information however, and if the signatures are not cached the client 
will again have to do sequential remote calls to lookup signatures.
Usually, signatures for all classes are loaded and cached at the 
beginning of the debugging session (which can be done by a single 
command), but visibleClasses includes unprepared classes that are not 
part of the initial caching.
So if there are many unprepared classes visibleClasses can spend a lot 
of time doing remote calls to load signatures.

Solution:
Stop including classes that are not prepared. No other commands include 
non-prepared classes (see JDK-4368402 
<https://bugs.openjdk.java.net/browse/JDK-4368402>), and I think it is 
an oversight that visibleClasses includes them.
This is the changes to ClassLoaderReferenceImpl.c, and they make 
visibleClasses behave like allClasses1 and classesForSignature in 
VirtualMachineImpl.c.

Regards,
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20151021/9a7d92e1/attachment.html>


More information about the serviceability-dev mailing list