JDK-8313655 : sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java frequently fails with SerialGC
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 22
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • Submitted: 2023-08-03
  • Updated: 2025-08-13
  • Resolved: 2025-08-13
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.
Other
tbdResolved
Related Reports
Relates :  
JDK-8307408 - Some jdk/sun/tools/jhsdb tests don't pass test JVM args to the debuggee JVM
Sub Tasks
JDK-8365184 :  
sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java Re-enable SerialGC flag on debuggee process - Resolved
Description
Although we frequently run this sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java with SerialGC, due to JDK-8307408 the debuggee process (jshell) is always run with the default GC (G1). When I fix JDK-8307408 to pass the test args to the debuggee process so SerialGC will get used, I see frequent failures. For example:

sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x00007f2fd6400000
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:111)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:78)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.Oop.getKlassForOopHandle(Oop.java:210)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:181)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.VMOopHandle.resolve(VMOopHandle.java:61)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.Klass.getJavaMirror(Klass.java:114)
	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter$5.visit(HeapHprofBinWriter.java:1242)
	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.classesDo(ClassLoaderData.java:107)
	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderDataGraph.classesDo(ClassLoaderDataGraph.java:84)
	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeClasses(HeapHprofBinWriter.java:1239)
	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:457)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:340)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500)

There are some other exceptions that can also be thrown, such as UnalignedAddressException. In all case the stack is the same up to ClassLoaderData.classesDo(), and maybe even a few frames above it.

It's not surprising that we see an issue once in a while since the debuggee process is active and might be in the middle of a GC. What is surprising perhaps is that don't sometimes see this with G1. I can only assume there are differences in how ClassLoaderData is handled between G1 and SerialGC.

This to me seems to be a test bug since JMap always is at risk of failing when used on an active process. The test should probably defend against it.

Since we can't problem list tests for just SerialGC, and I don't want to disable this test for G1, I'll just modify the test so it will use G1 in place of SerialGC.
Comments
I experimented without retry to catch any issue with SerialGC during first attempt. I didn't encounter any failure.
08-08-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/26690 Date: 2025-08-08 09:32:51 +0000
08-08-2025
It looks like the retry was added just a few months ago by JDK-8347779, so that would explain why we aren't seeing SerialGC failures now. If you removed the retry you would probably start seeing them. Something you might want to experiment with after removing the special handling for SerialGC.
05-08-2025
I think that is fine.
05-08-2025
The retry logic is already in place for HeapDumpTestWithActiveProcess too. From HeapDumpTestWithActiveProcess, JShellHeapDumpTest is called with "nosleep" which guarantees a retry. Given that SerialGC doesn't seem to cause issue anymore, I will remove its special handling. Hope its ok.
05-08-2025
If jmap gets an exception, the process exitCode should be non-zero. This is something the test could check and ignore. However, I don't think that is a good solution because if jmap were to be start failing all the time then we wouldn't notice it. I'd suggest a retry after failure. JShellHeapDumpTest does this. It allows one retry because failures are so rare that we are unlikely to ever see two in a row. Having said this, given that the test currently isn't failing, even with SerialGC, I don't think a change like this is worth doing. I'd suggest deferring this work until we see it reproducing again.
04-08-2025
Not able to reproduce the failure. [~cjplummer] Even if there is no failure, I can work on the test improvement. The only thing the test does is to check if the jmap was dumped. When you say that the test should probably defend against JMap failing, there is nothing left for test to verify.
04-08-2025
I suspect the reason we see this with SerialGC and not with G1 is because SerialGC does a lot more clobbering of moved object (clobbering the old location), whereas G1 is less disruptive and SA is probably getting way with accessing moved objects at their old location. This is just hypothetical. Could use a GC expert's opinion.
04-08-2023