Closed pdeva closed 7 years ago
Can you post the HotSpot log please?
This error is displayed when a sanity check that a referenced bytecode instruction is of the correct type (in this case expected to find a branch referenced in a branch-taken LogCompilation statement).
Usual cause for this is mounting different class files in JITWatch to those that were present when the HotSpot log was generated.
If you could show me the output of javap -v on the class that was in the TriView I can compare against the LogCompilation.
The log is the same one i posted here: https://github.com/AdoptOpenJDK/jitwatch/issues/240
The class file i was examining was of this src: https://github.com/DataSketches/sketches-misc/blob/5f31118a2a3bebc6f579a3958dab68ee848090f8/src/main/java/com/yahoo/sketches/memory/MemoryPerformance.java
To build it, check out this revision of the repo: https://github.com/DataSketches/sketches-misc/tree/5f31118a2a3bebc6f579a3958dab68ee848090f8
Hi, I've tracked down the cause behind these bytecode mismatch problems - there is a <late_inline>
tag that can insert an additional <parse>
tag in the parsing phase after the main inlining tree of a method. Once I handle that correctly I believe this issue will be resolved.
False positive bytecode-mismatches should be fixed by https://github.com/AdoptOpenJDK/jitwatch/commit/009569602adfb8271b2b6f04621d5a73bd51a50f. Please let me know if that fixes it for you.
Assuming this fixed it for you? Please file another issue if the problem remains. Thanks.
Happens on latest version of jitwatch. Running using
gradlew run
on windows 10 java 8