JDK-8167099 : TypeVersionMapper doesn't handle MonitorInfo correctly
  • Type: Bug
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2016-10-04
  • Updated: 2018-02-23
  • Resolved: 2016-11-29
Related Reports
Relates :  
JDK-8139587 - ThreadMXBean.dumpAllThreads() may fail with "java.io.InvalidObjectException: Failed to invoke from(CompositeData)"
Relates :  
JDK-8170456 - Test conversion of ThreadInfo to/from CompositeData between different versions of the JDK
Relates :  
JDK-8139870 - sun.management.LazyCompositeData.isTypeMatched() fails for composite types with items of ArrayType
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.
Comments
Closing this as not an issue. Will raise a seperate bug to check-in test case
29-11-2016
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.
08-11-2016
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.
04-11-2016