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

TypeVersionMapper doesn't handle MonitorInfo correctly

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Not an Issue
    • Affects Version/s: 9
    • Fix Version/s: None
    • Component/s: core-svc
    • Labels:
      None

      Description

      TypeVersionMapper::getVersionnedCompositeType will first look whether a filter exists for the composite type given as argument, and if no filter is found, then it will assume that no further processing is needed and simply return the given composite type.

      This doesn't take into account the fact that a composite type that hasn't changed between two versions can reference a composite type that has changed.

      This is the case for MonitorInfo. MonitorInfo itself has not changed, but it includes a field (lockedStackFrame) whose composite data has changed in JDK 9.

      As a result, if TypeVersionMapper is asked to retrieved the composite type of MonitorInfo for version 6, then that composite type will still reference types that are new in JDK 9 (it will contain the JDK 9 version of StackTraceElement which has module name and module version).
      This will impair the ability of a JDK 9 jvisualvm (or jconsole) to interoperate properly with a JDK 8 (or earlier) process.

        Issue Links

          Activity

          Hide
          dfuchs Daniel Fuchs added a comment - - edited
          I am no longer sure that this issue will have observable effect. If you manage to connect a JDK9 jvisualvm to a JDK 8 (update 122 or later) process (and conversely) then this bug might be closed as not an issue.
          I stumbled on the issue when I tried to force a JDK 9 process to generate a JDK 8 ThreadInfo composite data. If we ever wanted to do that then this bug would need to be fixed. However we don't have any such a requirement (I was just trying to work around JDK-8139870 - which had not been backported to 8 yet at the time).

          I have written a test (attached) that will verify that ThreadInfo composite data serialized with different version of the JDK can be converted back to ThreadInfo.
          At the least this test should be added to jdk9/dev and backported to jdk8u/dev as well (the backport is trivial - the test is designed to run on both versions). Note that the test depends on JDK-8139870.
          Show
          dfuchs Daniel Fuchs added a comment - - edited I am no longer sure that this issue will have observable effect. If you manage to connect a JDK9 jvisualvm to a JDK 8 (update 122 or later) process (and conversely) then this bug might be closed as not an issue. I stumbled on the issue when I tried to force a JDK 9 process to generate a JDK 8 ThreadInfo composite data. If we ever wanted to do that then this bug would need to be fixed. However we don't have any such a requirement (I was just trying to work around JDK-8139870 - which had not been backported to 8 yet at the time). I have written a test (attached) that will verify that ThreadInfo composite data serialized with different version of the JDK can be converted back to ThreadInfo. At the least this test should be added to jdk9/dev and backported to jdk8u/dev as well (the backport is trivial - the test is designed to run on both versions). Note that the test depends on JDK-8139870 .
          Hide
          mchung Mandy Chung added a comment -
          I agree that JDK 9 does not need to support generating JDK 8 ThreadInfo composite data. In fact, a JMX client running on JDK 8 update 122 or later should successfully connect to a running VM on JDK 9 and reconstruct a JDK 8 ThreadInfo on a JDK 8 client.
          Show
          mchung Mandy Chung added a comment - I agree that JDK 9 does not need to support generating JDK 8 ThreadInfo composite data. In fact, a JMX client running on JDK 8 update 122 or later should successfully connect to a running VM on JDK 9 and reconstruct a JDK 8 ThreadInfo on a JDK 8 client.
          Hide
          hb Harsha Wardhana B added a comment -
          Closing this as not an issue. Will raise a seperate bug to check-in test case
          Show
          hb Harsha Wardhana B added a comment - Closing this as not an issue. Will raise a seperate bug to check-in test case

            People

            • Assignee:
              hb Harsha Wardhana B
              Reporter:
              dfuchs Daniel Fuchs
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: