RFR: 8367949: JFR: MethodTrace double-counts methods that catch their own exceptions

Erik Gahlin egahlin at openjdk.org
Wed Jan 7 00:21:33 UTC 2026


On Tue, 6 Jan 2026 23:46:40 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> Could I have a review of a PR that changes how the instrumentation of the MethodTrace and MethodTiming events is implemented, so they handle exceptions in a better way? 
>> 
>> For constructors, the current implementation is still used in certain corner cases. A proper implementation would require data-flow analysis, but for all practical purposes this code should work fine.
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> test/jdk/jdk/jfr/event/tracing/TestConstructors.java line 116:
> 
>> 114:             }
>> 115:             try {
>> 116:                 new Zebra(true);
> 
> This results in `Zebra(int)` getting traced but not `Zebra(boolean)` because the `Zebra(int)` constructor call throws but  [is outside the `try` block](https://github.com/openjdk/jdk/pull/28947/files#diff-68a37600bc91d54808ea1ca427ade6af8a600889877f262e20782c550eded410R160) so execution never reaches the `catch` block that applies tracing. Is this intended?  Shouldn't a method be traced every time it is called?  In contrast, `new Zebra(false);` causes both `Zebra(int)` and `Zebra(boolean)` to be traced.
> 
> Additionally, with the old approach, `new Cat();` would not cause `Cat()` to be traced at all, since its callee, `methodThatThrows()`, prevents execution ever reaching `Cat()`'s `return` statement. I did a quick check on this by hardcoding `simplifiedInstrumentation = true`. Now, with the new approach in this PR,  `new Cat();` causes `Cat()` to be traced exactly once. This makes sense to me, but is different than before.

We can't place a try block around a call to super(...) or this(...). This is why two try blocks are used, one before and one after the call to this(...) or super(...).

With try blocks, we can now also track when an exception occurs in a callee. This is a behavioral change, but I believe it is for the better. I was aware of this limitation when I did the initial implementation, but I didn't think it was worth the added complexity that try blocks bring. What I didn’t realize at the time was the double-count issue, so now that we have the mechanics for try blocks, I decided to fix exception in a callee as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28947#discussion_r2666661004


More information about the hotspot-jfr-dev mailing list