On Wed, 8 Nov 2023 13:39:10 GMT, Daniel Fuchs wrote:
>> I agree, and I have looked into it, but I think it's better to do that
>> refactorization separately as it will impact other events.
>
> Just for my own understanding: in this particular case the time stamp is
> meaningless because the
On Wed, 8 Nov 2023 05:34:47 GMT, Erik Gahlin wrote:
>> src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 62:
>>
>>> 60: if (ExceptionThrownEvent.enabled()) {
>>> 61: long timestamp = ExceptionThrownEvent.timestamp();
>>> 62:
On Wed, 8 Nov 2023 05:13:04 GMT, David Holmes wrote:
>> Erik Gahlin has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rename field from tracing to jfrTracing
>
> src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 62:
On Tue, 7 Nov 2023 11:11:31 GMT, Erik Gahlin wrote:
>> Could I have a review of a PR that removes the bytecode instrumentation for
>> the exception events.
>>
>> Testing: jdk/jdk/jfr + tier1 + tier2
>
> Erik Gahlin has updated the pull request incrementally with one additional
> commit since
On Tue, 7 Nov 2023 11:11:31 GMT, Erik Gahlin wrote:
>> Could I have a review of a PR that removes the bytecode instrumentation for
>> the exception events.
>>
>> Testing: jdk/jdk/jfr + tier1 + tier2
>
> Erik Gahlin has updated the pull request incrementally with one additional
> commit since
On Tue, 7 Nov 2023 11:11:31 GMT, Erik Gahlin wrote:
>> Could I have a review of a PR that removes the bytecode instrumentation for
>> the exception events.
>>
>> Testing: jdk/jdk/jfr + tier1 + tier2
>
> Erik Gahlin has updated the pull request incrementally with one additional
> commit since
> Could I have a review of a PR that removes the bytecode instrumentation for
> the exception events.
>
> Testing: jdk/jdk/jfr + tier1 + tier2
Erik Gahlin has updated the pull request incrementally with one additional
commit since the last revision:
Rename field from tracing to jfrTracing
