search

eclipse-openj9 / openj9

Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.
Other
3.27k stars 721 forks source link

breakOnThrow JIT option on non-x86 platforms #8675

Open 0xdaryl opened 4 years ago

0xdaryl commented 4 years ago

Many years ago the x86 JIT introduced a "breakOnThrow" option which inserts a user breakpoint in JITed code just prior to the point of throwing an exception that matches some regex. Presumably this is useful for halting at the precise point in compiled code where a particular exception is thrown. This feature does not exist on any other platform. If it is useful then it should be.

I haven't kept up with the state-of-the-art in RAS techniques in the VM over the years to know whether or not there is some equivalent functionality in Xdump or Xtrace that should be used instead.

Did anyone even know this feature exists on x86? :-) It's implementation is a bit hacky (my opinion) and I would remove it if there isn't any value to it.

@andrewcraik @fjeremic @gita-omr @knn-k

fjeremic commented 4 years ago

Never knew about this. Definitely interested in knowing whether other people have used it and if it has been useful. I don't recall ever needing something like this.

knn-k commented 4 years ago

I usually don't debug the JIT on x86, and I didn't know the feature.

gacholio commented 4 years ago

I often use breakOnEntry once I've narrowed a problem down to a small number of compiled methods (and I imagine this one can be used with a regex as well).

x86 has a break instruction, which the debugger will allow you to step past. Is this true on any other platform? If not, you'd need to insert a call to a dummy function and break there in the debugger - certainly less convenient, but better than not having the feature at all.

0xdaryl commented 4 years ago

I believe all architectures support some variant of breakOnEntry. That option has proven its worth time and again and is not going anywhere.

The breakOnThrow option appears to have been introduced when someone checked in their diagnostic code that they used to investigate a bug. From the responses here (and lack of responses) it is clear it isn't well known at all even in x86 circles. I'm debating whether or not to purge it (because it feels bolted on and a bit hacky) or advocate its implementation on all other platforms.

0xdaryl commented 4 years ago

I've decided to remove this. If it has been in the codebase for 6+ years and no one either knows of its existence nor ever felt the need to implement something with similar functionality in order to diagnose a problem in the time since then I feel this is technical debt we don't need.