Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8263326

Remove ReceiverTypeData check from serviceability/sa/TestPrintMdo.java

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 17
    • Fix Version/s: 17
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b14

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

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              cjplummer Chris Plummer
              Reporter:
              cjplummer Chris Plummer
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: