Closed marschall closed 4 years ago
Hi @marschall I believe this is related to https://github.com/AdoptOpenJDK/jitwatch/issues/282
When I started JITWatch I didn't consider lambdas or other synthesised methods where the bytecode is not written to disk. I made an assumption that the class files would always be available at time of analysis.
The fix for this is a redesign of the JITWatch internal model so that methods whose bytecode is not present at analysis time can still be represented via their signatures in the LogCompilation report. Obviously the bytecode will not be available for display/analysis but the assembly and source should be so I think this is worth trying to fix.
Yeah, sounds like the same issue. Should I close as a duplicate?
Yes please. I will try and find some time to come up with a design for fixing this.
Duplicate of #282
For my future reference, this error is also seen when you don't have the right classpath directory set in the configuration screen.
Hi @chrisseaton I've been working on a new class file library that will replace JITWatch's use of javap and make it much more robust in the case of missing classes. Once that's in place I will be making JITWatch support "skeleton" metaclass creation based on LogCompilation BCIs which will better support lambdas (no classfile available) and where the classes are not configured.
Yeah but that's not quite what I mean - I mean if you don't have classes configured, even for normal methods, it doesn't say 'I couldn't find this class - maybe you need to add it to the configuration' it says 'MetaMember not found'.
Agreed, it's a bit cryptic. Will try and think of a non-intrusive way of presenting that.
The attached file was generated with JDK 11 and generated the following parse errors. Jitwatch is built from the current master branch:
hotspot_pid212229.log