Details
Description
The tests assumes that the clhsdb "printmdo -a" command will include ReceiverTypeData somewhere in the output. Normally it is from the following in the output:
MethodData 0x00007f097141b430 for method java/util/concurrent/ConcurrentHashMap.tabAt([Ljava/util/concurrent/ConcurrentHashMap$Node;I)Ljava/util/concurrent/ConcurrentHashMap$Node;@0x0000000800448820
0 bci: 15 VirtualCallData count(48) entries(0)
argument types 0: stack(1) ObjArrayKlass for InstanceKlass for java/util/concurrent/ConcurrentHashMap$Node
80 bci: 18 ReceiverTypeData flags(1) count(0) entries(1)
InstanceKlass for java/util/concurrent/ConcurrentHashMap$Node(3)
Sinced LingeredApp is used as the debuggee, the output of "printmdo -a" is very much subjected to the code executed by LingeredApp on startup, including any library code it calls. It is also subjected to how the VM is launched. Therefore there is no guarantee that the above mention of ReceiverTypeData will be present. We have had other issues like this in the past, thus the restrictions currently in place when running TestPrintMdo.java:
* @requires vm.flavor == "server" & !vm.emulatedClient & !(vm.opt.TieredStopAtLevel == 1)
And the LingeredApp is launched with:
app = LingeredApp.startApp("-XX:+ProfileInterpreter", "-XX:CompileThreshold=100");
I started running into problems with ReceiverTypeData not appearing in the output about 1% of the time while working on changes forJDK-8243455, which impacts code executed by LingeredApp on startup.
Rather than trying to make it so somehow we can (hopefully) guarantee that ReceiverTypeData is always present, which I'm not even sure we can do, I think it's best to just no longer rely on its presence, and not have to worry about this failure cropping up again.
MethodData 0x00007f097141b430 for method java/util/concurrent/ConcurrentHashMap.tabAt([Ljava/util/concurrent/ConcurrentHashMap$Node;I)Ljava/util/concurrent/ConcurrentHashMap$Node;@0x0000000800448820
0 bci: 15 VirtualCallData count(48) entries(0)
argument types 0: stack(1) ObjArrayKlass for InstanceKlass for java/util/concurrent/ConcurrentHashMap$Node
80 bci: 18 ReceiverTypeData flags(1) count(0) entries(1)
InstanceKlass for java/util/concurrent/ConcurrentHashMap$Node(3)
Sinced LingeredApp is used as the debuggee, the output of "printmdo -a" is very much subjected to the code executed by LingeredApp on startup, including any library code it calls. It is also subjected to how the VM is launched. Therefore there is no guarantee that the above mention of ReceiverTypeData will be present. We have had other issues like this in the past, thus the restrictions currently in place when running TestPrintMdo.java:
* @requires vm.flavor == "server" & !vm.emulatedClient & !(vm.opt.TieredStopAtLevel == 1)
And the LingeredApp is launched with:
app = LingeredApp.startApp("-XX:+ProfileInterpreter", "-XX:CompileThreshold=100");
I started running into problems with ReceiverTypeData not appearing in the output about 1% of the time while working on changes for
Rather than trying to make it so somehow we can (hopefully) guarantee that ReceiverTypeData is always present, which I'm not even sure we can do, I think it's best to just no longer rely on its presence, and not have to worry about this failure cropping up again.
Attachments
Issue Links
- blocks
-
JDK-8243455 Many SA tests can fail due to trying to get the stack trace of an active method
-
- Resolved
-
- duplicates
-
JDK-8258649 serviceability/sa/TestPrintMdo.java failed with "RuntimeException: 'ReceiverTypeData' missing from stdout/stderr"
-
- Resolved
-