AdoptOpenJDK / jitwatch

Log analyser / visualiser for Java HotSpot JIT compiler. Inspect inlining decisions, hot methods, bytecode, and assembly. View results in the JavaFX user interface.
Other
3.07k stars 437 forks source link

Parsing Error with Incorrectly Ordered Log #251

Closed dkonik closed 7 years ago

dkonik commented 7 years ago

Similar to this post, JitWatch throws an exception when the log is slightly mangled. Namely:

Decoding compiled method 0x00007f0c9d4b4f10:
Code:
[Entry Point]
[Constants]
  # {method} {0x00007f0c65616268} 'getName' '()Ljava/lang/Str[Loaded java.util.concurrent.locks.AbstractOwnableSynchronizer from /usr/java/jre1.8.0_101-x86_64/lib/rt.jar]
ing;' in 'java/lang/reflect/Field'
  #           [sp+0x40]  (sp of caller)

(The entire Loading bit in the middle of the "String".) And the stack trace for this is:

21:15:13.240 [Thread-6] ERROR o.a.j.c.AssemblyProcessor - Could not parse MSP from line: # {method} {0x00007f0c65616268} 'getName' '()Ljava/lang/Str[Loaded java.util.concurrent.locks.AbstractOwnableSynchronizer from /usr/java/jre1.8.0_101-x86_64/lib/rt.jar]ing;' in 'java/lang/reflect/Field'
org.adoptopenjdk.jitwatch.model.LogParseException: Could not parse types: Ljava/lang/Str[Loaded java.util.concurrent.locks.AbstractOwnableSynchronizer from /usr/java/jre1.8.0_101-x86_64/lib/rt.jar]ing;
    at org.adoptopenjdk.jitwatch.util.ParseUtil.getClassTypes(ParseUtil.java:359)
    at org.adoptopenjdk.jitwatch.model.MemberSignatureParts.setParamsAndReturn(MemberSignatureParts.java:375)
    at org.adoptopenjdk.jitwatch.model.MemberSignatureParts.fromAssembly(MemberSignatureParts.java:363)
    at org.adoptopenjdk.jitwatch.core.AssemblyProcessor.attachAssemblyToMembers(AssemblyProcessor.java:186)
    at org.adoptopenjdk.jitwatch.core.HotSpotLogParser.parseAssemblyLines(HotSpotLogParser.java:394)
    at org.adoptopenjdk.jitwatch.core.HotSpotLogParser.parseLogFile(HotSpotLogParser.java:306)

Wasn't sure if it was possible to make the parser more robust to be able to handle such cases or not? Also, the above was run using commit 5412297.

chriswhocodes commented 7 years ago

Thanks for the report. I'll see if I can improve the parser around TraceClassLoading statements.

chriswhocodes commented 7 years ago

Hi, I've taken a look at this and I think it would complicate the parse too much / slow down the parsing to check for this particular type of mangling. Would also not fix all possible mangling examples.

Will have to close this for now. Maybe one day LogCompilation will be retrofitted to unified logging (JDK9) and this problem will go away.