On Wed, 16 Jul 2025 13:24:35 GMT, Erik Gahlin wrote:
> 8361640: JFR: RandomAccessFile::readLine emits events for each character
This pull request has now been integrated.
Changeset: 93260d63
Author: Erik Gahlin
URL:
https://git.openjdk.org/jdk/com
8361640: JFR: RandomAccessFile::readLine emits events for each character
-
Commit messages:
- Backport 9bef2d1610647dec18f9e81cbac3dddbbf99dd6d
Changes: https://git.openjdk.org/jdk/pull/26349/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26349&range=00
Issue: https://bu
On Wed, 9 Jul 2025 05:45:01 GMT, Erik Gahlin wrote:
> Could I have a review of the change that prevents RandomAccessFile::readLine
> from emitting an event per character? This leads to unnecessary overhead,
> both with or without JFR enabled.
>
> Testing: tier1 + tier2
On Tue, 15 Jul 2025 16:09:38 GMT, Alan Bateman wrote:
>> Erik Gahlin has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove traceImplReadLine
>
> src/java.base/share/classes/java/io/RandomAccessF
> Could I have a review of the change that prevents RandomAccessFile::readLine
> from emitting an event per character? This leads to unnecessary overhead,
> both with or without JFR enabled.
>
> Testing: tier1 + tier2 + jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has
On Wed, 9 Jul 2025 05:45:01 GMT, Erik Gahlin wrote:
> Could I have a review of the change that prevents RandomAccessFile::readLine
> from emitting an event per character? This leads to unnecessary overhead,
> both with or without JFR enabled.
>
> Testing: tier1 + tier2
On Wed, 9 Jul 2025 09:01:00 GMT, Alan Bateman wrote:
> > Testing: tier1 + jdk/jdk/jfr
>
> The tests for this area are in tier2 (not tier1).
I ran tier2. It was fine.
-
PR Comment: https://git.openjdk.org/jdk/pull/26210#issuecomment-3053405518
On Wed, 9 Jul 2025 09:01:52 GMT, Alan Bateman wrote:
> I think we'll need to see if a test can be added as it's way too easy to
> refactor this code and re-introduce the issue.
I'm planning a follow-up PR that will check the top frame. Here's the draft:
https://github.com/openjdk/jdk/pull/26211
Could I have a review of the change that prevents RandomAccessFile::readLine
from emitting an event per character? This leads to unnecessary overhead, both
with or without JFR enabled.
Testing: tier1 + jdk/jdk/jfr
Thanks
Erik
-
Commit messages:
- Remove mistakenly added file
- I
On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin wrote:
> Could I have review of an enhancement that adds rate-limited sampling to Java
> events, including five events in the JDK (SocketRead, SocketWrite, FileRead,
> FileWrite, and JavaExceptionThrow).
>
> Testing: test/jdk/jdk/
On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin wrote:
>> Could I have review of an enhancement that adds rate-limited sampling to
>> Java events, including five events in the JDK (SocketRead, SocketWrite,
>> FileRead, FileWrite, and JavaExceptionThrow).
>>
>
On Thu, 5 Jun 2025 10:35:10 GMT, Alan Bateman wrote:
>> Erik Gahlin has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move the timestamp to before the try block, change bytes to bytesWritten
>> and r
On Thu, 5 Jun 2025 09:51:51 GMT, Alan Bateman wrote:
>> Erik Gahlin has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Remove the mistakenly added file.
>> - Fix whitespace
>
> src/jdk.jfr/share/conf
> Could I have review of an enhancement that adds rate-limited sampling to Java
> events, including five events in the JDK (SocketRead, SocketWrite, FileRead,
> FileWrite, and JavaExceptionThrow).
>
> Testing: test/jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has
On Thu, 5 Jun 2025 00:21:45 GMT, Stuart Marks wrote:
>> We need some indication of which events are throttleable and looking at the
>> mirror event may not work in some scenarios.
>>
>> We need to sample the endTime, because the startTime may be several minutes
>> in the past. We could use com
> Could I have review of an enhancement that adds rate-limited sampling to Java
> events, including five events in the JDK (SocketRead, SocketWrite, FileRead,
> FileWrite, and JavaExceptionThrow).
>
> Testing: test/jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has
> Could I have review of an enhancement that adds rate-limited sampling to Java
> events, including five events in the JDK (SocketRead, SocketWrite, FileRead,
> FileWrite, and JavaExceptionThrow).
>
> Testing: test/jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has
> Could I have review of an enhancement that adds rate-limited sampling to Java
> events, including five events in the JDK (SocketRead, SocketWrite, FileRead,
> FileWrite, and JavaExceptionThrow).
>
> Testing: test/jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has updated
> Could I have review of an enhancement that adds rate-limited sampling to Java
> events, including five events in the JDK (SocketRead, SocketWrite, FileRead,
> FileWrite, and JavaExceptionThrow).
>
> Testing: test/jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has updated
> Could I have review of an enhancement that adds rate-limited sampling to Java
> events, including five events in the JDK (SocketRead, SocketWrite, FileRead,
> FileWrite, and JavaExceptionThrow).
>
> Testing: test/jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has updated
On Wed, 4 Jun 2025 14:32:31 GMT, Alan Bateman wrote:
>> Erik Gahlin has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix adjust boundary
>
> src/java.base/share/classes/java/net/Socket.java line 970:
&
On Wed, 4 Jun 2025 14:16:56 GMT, Alan Bateman wrote:
>> Erik Gahlin has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix adjust boundary
>
> src/jdk.jfr/share/classes/jdk/jfr/Throttle.java line 77:
>
>
On Tue, 3 Jun 2025 12:50:49 GMT, Erik Gahlin wrote:
>> Could I have review of an enhancement that adds rate-limited sampling to
>> Java events, including five events in the JDK (SocketRead, SocketWrite,
>> FileRead, FileWrite, and JavaExceptionThrow).
>>
>
> Could I have review of an enhancement that adds rate-limited sampling to Java
> event, including five events in the JDK (SocketRead, SocketWrite, FileRead,
> FileWrite, and JavaExceptionThrow).
>
> Testing: test/jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has
On Mon, 2 Jun 2025 08:59:57 GMT, Volkan Yazici wrote:
>> Erik Gahlin has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Some reviewer feedback
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.
On Sat, 31 May 2025 21:20:17 GMT, Markus Grönlund wrote:
>> Erik Gahlin has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Some reviewer feedback
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrument
> Could I have review of an enhancement that adds rate-limited sampling to Java
> event, including five events in the JDK (SocketRead, SocketWrite, FileRead,
> FileWrite, and JavaExceptionThrow).
>
> Testing: test/jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has
On Sat, 31 May 2025 20:13:01 GMT, Markus Grönlund wrote:
>> Could I have review of an enhancement that adds rate-limited sampling to
>> Java event, including five events in the JDK (SocketRead, SocketWrite,
>> FileRead, FileWrite, and JavaExceptionThrow).
>>
>> Testing: test/jdk/jdk/jfr
>>
>>
Could I have review of an enhancement that adds rate-limited sampling to Java
event, including five events in the JDK (SocketRead, SocketWrite, FileRead,
FileWrite, and JavaExceptionThrow).
Testing: test/jdk/jdk/jfr
Thanks
Erik
-
Commit messages:
- Consistent annotation
- Fix ty
On Thu, 19 Dec 2024 19:16:55 GMT, Erik Gahlin wrote:
>> I'm not sure if one or two events are most suitable. If possible, I would
>> like to discuss it with Markus to get some more input. He will back in
>> January.
>
> Regarding one or two events. I'm fi
On Thu, 12 Dec 2024 03:58:29 GMT, Erik Gahlin wrote:
>> We need to help Tim on the question of whether there is one or two events.
>>
>> An application that makes outbound network connections may run slowly for
>> several reasons. A duration event may help to diagno
On Wed, 4 Dec 2024 12:26:20 GMT, Alan Bateman wrote:
>> We could have two views with only one event. The query for the view could
>> filter for exceptionMessage != null or a failure property. The advantage of
>> having two events is that the failure event could have a threshold of 0 ms.
>>
>>
On Tue, 3 Dec 2024 12:34:20 GMT, Alan Bateman wrote:
>> A connection failure introduces a latency in the application, so probably
>> best to have such an event durational as well.
>
> @egahlin The updated PR proposes two duration events: jdk.SocketConnect for
> when a connection is established,
On Fri, 29 Nov 2024 12:20:02 GMT, Nizar Benalla wrote:
>> Can I please get a review for this PR that add tests to verify the value of
>> `@since` tags to the Tools area modules. The test is described in this
>> [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html).
>> Th
On Mon, 25 Nov 2024 12:00:52 GMT, Alan Bateman wrote:
>>> If a connection cannot be established then it might be immediate, 10s of
>>> milliseconds, maybe 60+ seconds in some cases. A slow down or stall waiting
>>> for a connection to be established seems a useful event to have recorded.
>>
>>
On Mon, 25 Nov 2024 07:54:34 GMT, Alan Bateman wrote:
> If a connection cannot be established then it might be immediate, 10s of
> milliseconds, maybe 60+ seconds in some cases. A slow down or stall waiting
> for a connection to be established seems a useful event to have recorded.
If it's imm
On Sat, 23 Nov 2024 08:02:42 GMT, Alan Bateman wrote:
>> Tim Prinzing has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added more tests for socket connect events.
>>
>> - SocketAdapter connect
>> - SocketAdapter connect with except
On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo
wrote:
> This is the implementation of JEP 491: Synchronize Virtual Threads without
> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
> further details.
>
> In order to make the code review easier the changes hav
On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the changes
On Thu, 29 Aug 2024 21:46:52 GMT, Chen Liang wrote:
>> `CodeBuilder::loadConstant(Opcode, ConstantDesc)` is error-prone and
>> confusing. Users should almost always use `loadConstant(ConstantDesc)` for
>> optimized instructions, or use specific factories `iconst_0` etc. or
>> `bipush` with arg
On Wed, 21 Aug 2024 18:26:20 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> Explicitly pin a virtual thread before acquiring the JFR string pool monitor
>> because migrating a carrier thread local event writer object onto another
>> carrier thread is impossible.
>>
>> During event commit, th
On Thu, 15 Aug 2024 12:26:38 GMT, David Holmes wrote:
>> Markus Grönlund has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> update test comment
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/StringPool.java line 86:
>
>> 84:
>> 85: pr
On Tue, 7 May 2024 19:32:57 GMT, Erik Gahlin wrote:
> Hi,
>
> Could I have a review of a change that moves the jdk.FileRead and
> jdk.FileWrite events to java.base to remove the use of the ASM
> instrumentation.
>
> Testing: jdk/jdk/jfr, tier1-tier4
>
> Thanks
&g
On Fri, 24 May 2024 15:45:07 GMT, Erik Gahlin wrote:
>> Collapsing the extra layer of methods and combining the test into
>>
>> if (jfrTracing && FileReadEvent.enabled())
>>
>> would indeed keep things a little neater.
>>
>> I'm stil
> Hi,
>
> Could I have a review of a change that moves the jdk.FileRead and
> jdk.FileWrite events to java.base to remove the use of the ASM
> instrumentation.
>
> Testing: jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has updated the pull request incrementally wit
> Hi,
>
> Could I have a review of a change that moves the jdk.FileRead and
> jdk.FileWrite events to java.base to remove the use of the ASM
> instrumentation.
>
> Testing: jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has updated the pull request incrementally wit
On Tue, 21 May 2024 22:41:12 GMT, Stuart Marks wrote:
>> I think `if (jfrTracing && FileReadEvent.enabled())` would be more readable
>> as it would avoid calling going through the traceXXX methods when the flag
>> is enabled but the specific event is not enabled.
>
> Collapsing the extra layer
> Hi,
>
> Could I have a review of a change that moves the jdk.FileRead and
> jdk.FileWrite events to java.base to remove the use of the ASM
> instrumentation.
>
> Testing: jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has updated the pull request incrementally wit
> Hi,
>
> Could I have a review of a change that moves the jdk.FileRead and
> jdk.FileWrite events to java.base to remove the use of the ASM
> instrumentation.
>
> Testing: jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has updated the pull request incrementally
On Sat, 11 May 2024 15:00:09 GMT, Alan Bateman wrote:
>> A compromise between performance and readability is:
>>
>> if (JFRTracing.isEnabled()) {
>> ...
>> }
>>
>> One additional class is loaded, but it's more clear where it comes from. I
>> didn't want to do that for the ThrowableTracer
On Fri, 10 May 2024 00:43:32 GMT, Stuart Marks 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
>> increase
On Thu, 9 May 2024 15:41:42 GMT, Erik Gahlin wrote:
>> src/java.base/share/classes/jdk/internal/event/JFRTracing.java line 51:
>>
>>> 49: field.setAccessible(true);
>>> 50: field.setBoolean(null, true);
>>> 51: }
>>
>> Using refl
On Thu, 9 May 2024 14:29:13 GMT, Daniel Fuchs wrote:
>> Erik Gahlin has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move methods
>
> src/java.base/share/classes/jdk/internal/event/JFR
On Thu, 9 May 2024 14:25:27 GMT, Daniel Fuchs wrote:
>> Erik Gahlin has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move methods
>
> src/java.base/share/classes/java/io/FileInputStream.java line 63:
>
On Thu, 9 May 2024 07:33:22 GMT, Erik Gahlin wrote:
>> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 78:
>>
>>> 76:
>>> 77: // Flag that determines if file reads/writes should be traced by JFR
>>> 78: private static boolean jfr
> Hi,
>
> Could I have a review of a change that moves the jdk.FileRead and
> jdk.FileWrite events to java.base to remove the use of the ASM
> instrumentation.
>
> Testing: jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has updated the pull request incrementally wit
> Hi,
>
> Could I have a review of a change that moves the jdk.FileRead and
> jdk.FileWrite events to java.base to remove the use of the ASM
> instrumentation.
>
> Testing: jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has updated the pull request incrementally wit
On Thu, 9 May 2024 07:20:55 GMT, Alan Bateman wrote:
>> Hi,
>>
>> Could I have a review of a change that moves the jdk.FileRead and
>> jdk.FileWrite events to java.base to remove the use of the ASM
>> instrumentation.
>>
>> Testing: jdk/jdk/jfr
>>
>> Thanks
>> Erik
>
> src/java.base/share/cl
Hi,
Could I have a review of a change that moves the jdk.FileRead and jdk.FileWrite
events to java.base to remove the use of the ASM instrumentation.
Testing: jdk/jdk/jfr
Thanks
Erik
-
Commit messages:
- Update comment
- Initial
Changes: https://git.openjdk.org/jdk/pull/19129/f
On Thu, 18 Apr 2024 18:59:20 GMT, Tim Prinzing wrote:
>> Currently the JFR event FileForceEvent is generated by instrumenting the
>> sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer
>> mirror events with static methods.
>>
>> Added the event at jdk.internal.event.Fil
On Thu, 18 Apr 2024 15:14:10 GMT, Tim Prinzing wrote:
>> I think it might be the cause for
>> https://bugs.openjdk.org/browse/JDK-8329330 I have sent out a PR to remove
>> those separately so the fix can be backported.
>> https://github.com/openjdk/jdk/pull/18843
>
> That's correct, it is an u
On Wed, 17 Apr 2024 14:05:28 GMT, Daniel Fuchs wrote:
>> Tim Prinzing has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> test file local to test
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 66:
>
>> 64:
On Mon, 15 Apr 2024 21:37:15 GMT, Tim Prinzing wrote:
>> Added mirror event with static methods: jdk.internal.event.SelectionEvent
>> that provides the duration of select calls and the count of how many keys
>> are available.
>>
>> Emit the event from SelectorImpl::lockAndDoSelect
>>
>> Test
On Wed, 10 Apr 2024 23:51:34 GMT, Tim Prinzing wrote:
>> Added mirror event with static methods: jdk.internal.event.SelectionEvent
>> that provides the duration of select calls and the count of how many keys
>> are available.
>>
>> Emit the event from SelectorImpl::lockAndDoSelect
>>
>> Test
On Wed, 10 Apr 2024 23:51:34 GMT, Tim Prinzing wrote:
>> Added mirror event with static methods: jdk.internal.event.SelectionEvent
>> that provides the duration of select calls and the count of how many keys
>> are available.
>>
>> Emit the event from SelectorImpl::lockAndDoSelect
>>
>> Test
On Tue, 19 Mar 2024 17:58:46 GMT, Bill Huang wrote:
>> This task addresses an essential aspect of our testing infrastructure: the
>> proper handling and cleanup of temporary files and socket files created
>> during test execution. The motivation behind these changes is to prevent the
>> accumu
On Fri, 5 Jan 2024 15:17:13 GMT, Adam Sotona wrote:
> `java.lang.classfile.CodeBuilder` contains more than 230 API methods.
> Existing ClassFile API use cases proved the concept one big CodeBuilder is
> comfortable. However there are some redundancies, glitches in the naming
> conventions, some
On Mon, 15 Jan 2024 14:17:40 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Removed useless event settings in test.
Marked as rev
On Tue, 19 Dec 2023 17:53:49 GMT, Erik Gahlin wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Changes according to reviewer's comments.
>
>> You mean, in the @descrip
On Thu, 21 Dec 2023 09:36:06 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Removed @module from test.
src/jdk.jfr/share/classes/
On Tue, 19 Dec 2023 17:37:50 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java
>> line 39:
>>
>>> 37: import static java.lang.reflect.Modifier.*;
>>> 38:
>>> 39: final class SerializationMisdeclarationChecker {
>>
>> Is there a rea
On Tue, 19 Dec 2023 16:45:04 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Changes according to reviewer's comments.
> You mean,
On Tue, 19 Dec 2023 16:28:03 GMT, Raffaello Giulietti
wrote:
> However, the cache can be emptied under high memory pressure, so the
> `ObjectStreamClass` instance might be recreated later, thus re-invoking the
> serialization checker once again.
I think it would be good to state in the descri
On Tue, 19 Dec 2023 16:00:59 GMT, Raffaello Giulietti
wrote:
>> test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 50:
>>
>>> 48: * @requires vm.hasJFR
>>> 49: * @library /test/lib
>>> 50: * @run junit/othervm
>>> jdk.jfr.event.io.TestSerializationMisdeclarationEvent
>
On Tue, 19 Dec 2023 16:45:04 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Changes according to reviewer's comments.
src/java.ba
On Tue, 19 Dec 2023 12:17:38 GMT, Raffaello Giulietti
wrote:
>> src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java
>> line 48:
>>
>>> 46:
>>> 47: @Label("Kind")
>>> 48: public int kind;
>>
>> What is the use case for error codes? Are they public or an impl
On Mon, 18 Dec 2023 17:49:04 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Event enabled on profile.jfc but disabled on default.j
On Sat, 16 Dec 2023 01:27:17 GMT, Erik Gahlin wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Restrict accessibility of nested classes.
>
> It seems correct to have the event d
On Fri, 15 Dec 2023 22:26:04 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Restrict accessibility of nested classes.
It seems co
On Wed, 22 Nov 2023 12:25:45 GMT, Alan Bateman wrote:
>> Added mirror event with static methods: jdk.internal.event.SelectionEvent
>> that provides the duration of select calls and the count of how many keys
>> are available.
>>
>> Emit the event from SelectorImpl::lockAndDoSelect
>>
>> Test
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 dur
On Fri, 3 Nov 2023 12:19:07 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
This pull request has now been integrated.
Changeset: e8418972
Author: Erik
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/even
> 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 t
On Tue, 7 Nov 2023 09:27:51 GMT, Alan Bateman wrote:
>> I filed an issue to investigate if there is a problem with SOE, or if the
>> OOM check is really needed now.
>> https://bugs.openjdk.org/browse/JDK-8319579
>>
>> Regardless of outcome, It would be good to document the results of the
>> in
On Tue, 7 Nov 2023 09:24:20 GMT, Alan Bateman wrote:
>> Erik Gahlin has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove SecurityException and IllegalArgumentException from throws clause
>
> src/jav
On Mon, 6 Nov 2023 22:41:17 GMT, Erik Gahlin wrote:
>> src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 44:
>>
>>> 42:
>>> 43: public static void traceError(Class clazz, String message) {
>>> 44: if (OutOfM
> 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:
Remove SecurityE
On Mon, 6 Nov 2023 15:49:02 GMT, Alan Bateman wrote:
>> Could I have a review of a PR that removes the bytecode instrumentation for
>> the exception events.
>>
>> Testing: jdk/jdk/jfr + tier1 + tier2
>
> src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 37:
>
>> 35:
Could I have a review of a PR that removes the bytecode instrumentation for the
exception events.
Testing: jdk/jdk/jfr + tier1 + tier2
-
Commit messages:
- Remove Throwable and Error from instrumentation list
- Initial
Changes: https://git.openjdk.org/jdk/pull/16493/files
Webrev
On Sun, 15 Oct 2023 20:20:48 GMT, Erik Gahlin wrote:
> Hi,
>
> Could I have a review of an enhancement that replaces the use of ASM with the
> new Class-File API. This change only deals with bytecode that writes event
> data into buffers. Bytecode transformations carried ou
On Sun, 15 Oct 2023 23:46:45 GMT, Chen Liang wrote:
>> Erik Gahlin has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Blessed order
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java li
ter stage.
>
> Testing: tier1-3 + jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has updated the pull request incrementally with one additional
commit since the last revision:
Blessed order
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16195/files
- new: https
On Mon, 16 Oct 2023 05:56:00 GMT, Chen Liang wrote:
>> I could not get it to work with findAttribute. No annotations were found.
>
> The existing code will silently finish the loop no-op and return `null` if no
> RVAA is present. So if `findAttribute` returns `Optional.empty()`, you should
> ju
On Mon, 16 Oct 2023 06:01:01 GMT, Chen Liang wrote:
>> Erik Gahlin has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updates
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrument
ter stage.
>
> Testing: tier1-3 + jdk/jdk/jfr
>
> Thanks
> Erik
Erik Gahlin has updated the pull request incrementally with one additional
commit since the last revision:
Updates
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16195/files
- new: https
On Sun, 15 Oct 2023 23:45:05 GMT, Chen Liang wrote:
>> Erik Gahlin has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updates
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line
On Sun, 15 Oct 2023 23:34:01 GMT, Chen Liang wrote:
>> Hi,
>>
>> Could I have a review of an enhancement that replaces the use of ASM with
>> the new Class-File API. This change only deals with bytecode that writes
>> event data into buffers. Bytecode transformations carried out by classes in
Hi,
Could I have a review of an enhancement that replaces the use of ASM with the
new Class-File API. This change only deals with bytecode that writes event data
into buffers. Bytecode transformations carried out by classes in
jdk.jfr.internal.intrument package are kept as is. Plan is to try to
Hi,
The events for socket read and socket write retrieves the remote address even
in cases where the event didn't exceed the threshold. By moving the
shouldCommit check earlier, it can be avoided.
Testing: jdk/jdk/jfr
Thanks
Erik
-
Commit messages:
- Socket write event
- Initi
1 - 100 of 116 matches
Mail list logo
