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
