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 for JDK-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.