On Fri, 10 May 2024 00:43:32 GMT, Stuart Marks <sma...@openjdk.org> wrote:
>> Its purpose is to avoid loading the FileReadEvent class. When the class is
>> loaded, JFR will add fields and in some circumstances do other things. I
>> don't think the cost is high, but it may add up if the number of events
>> increases. Most Java applications don't run with JFR enabled, so this is to
>> prevent them from seeing a negative impact.
>>
>> I can update the text.
>
> Hm, I think this setup requires more discussion. The approach we had settled
> on was that at the call sites in the libraries, something like the following
> was done:
>
> public R operation(...) {
> if (SomeEvent.enabled()) {
> // perform operation0 with tracing
> // emit event if SomeEvent.shouldCommit(...) is true
> } else {
> return operation0(...); // perform operation without tracing
> }
> }
>
> private R operation0(...) { /* do the actual work */ }
>
> Now it looks like there's this additional flag `jfrTracing` that's set
> reflectively, and this flag is checked in a new layer of intermediate method
> calls:
>
> public R operation(...) {
> if (jfrTracing) {
> return traceOperation0(...);
> } else {
> return operation0(...);
> }
> }
>
> private R traceOperation0(...) {
> // stuff moved from public operation(...) above
> }
>
> That is, the former body of the public `operation(...)` method is moved into
> the new `traceOperation0(...)` method.
>
> I understand this is intended to help optimize startup time, but it adds
> clutter at each call site, and I'm wondering if it actually helps anything.
> The first time the application calls the `operation()` method, it's going to
> load a bunch of classes; the loading of this additional class is amortized
> over the loading and initialization of all the other classes in this area of
> the library. In addition, in the non-JFR case, the `enabled()` method
> implementation is simply `return false;` which can be inlined and which
> facilitiates dead code elimination.
>
> With `jfrTracing` added to the mix, it causes a load from a non-final boolean
> field that needs to be checked repeatedly. Maybe the JIT can optimize for the
> common case, but there's possibly an expense that needs to be paid here.
>
> At some point we should measure startup overhead for each case. I guess this
> can occur before or after this PR is integrated, depending on the urgency of
> things, but we should keep an eye on this issue.
If an event class is loaded before JFR is started, the event class needs to be
retransformed, but if it is loaded later, we can add instrumentation on class
load and avoid the retransformation. More happens when an event class is loaded
compared to ordinary class load, for example, a startTime field is added.
I did a JMH run and the difference between Event::enabled() and a boolean flag
was a fraction of nanosecond.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19129#discussion_r1597496811
