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