JDK-8074696 : Remote debugging session hangs for several minutes when calling findBootType
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-03-09
  • Updated: 2016-04-27
  • Resolved: 2015-11-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u101Fixed 9 b94Fixed
Related Reports
Relates :  
A remote debugging session can hang for long periods of time when calling findBootType on a high delay network.

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.

Since we have a signature that should match, we should use retrieveClassesBySignature command that only returns matching classes.
Then we would at worst have to loop over the number of active classloader since we want the class loaded by the boot classloader (null class loader);
UR SQE OK to take it in PSU16_01

Splitting this bug into two, and will use this bug to push the smaller change to findBootType. I'll use https://bugs.openjdk.java.net/browse/JDK-8140515 to track and push the similar problem that visibleClasses has.

The changes in JDK-6457137 will have to be done separately, I'll work towards pushing this fix as is.

Upon closer inspection the findBootType problem looks to be fixed in close to the same way I was planning. I think the visibleClasses problem is still there though.

Thanks for the pointer, however I took a quick look at the patch from that bug, and I think these are separate problems. This problem has to do with signature lookups on classes already transferred to the client. The problem in JDK-6457137 looks related to lots of classes being prepared and/or unloaded at once. I'll try applying the patch and see if it fixes the problem anyway.

Please have a look at JDK-6457137. I've already tried to address this issue, there is a patch attached. We should be able to get rid of the request for all loaded classes, IMHO.

Noreg-hard / noreg-perf justification: The problem is that commands take long time to execute on high delay network where lots of classes are loaded. I've been using linux netem (linux network emulator) to simulate high delays, but this requires root access to setup.