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

Robert Toyonaga duke at openjdk.org
Wed Jan 7 14:08:34 UTC 2026


On Wed, 7 Jan 2026 00:15:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> 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 fixed exception in a callee as well.

Okay this makes sense to me. Thank you for your explanation.

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

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


More information about the hotspot-jfr-dev mailing list