On Fri, 29 Mar 2024 00:52:46 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.
>
>
On Mon, 29 Apr 2024 20:01:38 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.
>
On Thu, 11 Apr 2024 16:39:24 GMT, Daniel Fuchs wrote:
>> I think it's okay for now. If there is another phase of this work to help
>> diagnose spinning issues then it will need to re-visited. I'm very concerned
>> about the possible changes for that second phase, but this first phase of
>>
> 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 at jdk.jfr.event.io.TestSelectionEve
nts.FileForceEvent to be a mirror event.
>
> Updated FileChannelImpl to use the jdk internal event static methods, and
> removed the force() method from FileChannelImplInstrumentor.
>
> Uses the existing tests.
Tim Prinzing has updated the pull request incrementally with one
nts.FileForceEvent to be a mirror event.
>
> Updated FileChannelImpl to use the jdk internal event static methods, and
> removed the force() method from FileChannelImplInstrumentor.
>
> Uses the existing tests.
Tim Prinzing has updated the pull request with a new target base due
nts.FileForceEvent to be a mirror event.
>
> Updated FileChannelImpl to use the jdk internal event static methods, and
> removed the force() method from FileChannelImplInstrumentor.
>
> Uses the existing tests.
Tim Prinzing has updated the pull request incrementally with one
nts.FileForceEvent to be a mirror event.
>
> Updated FileChannelImpl to use the jdk internal event static methods, and
> removed the force() method from FileChannelImplInstrumentor.
>
> Uses the existing tests.
Tim Prinzing has updated the pull request incrementally with one
On Thu, 18 Apr 2024 18:46:36 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.
>
nts.FileForceEvent to be a mirror event.
>
> Updated FileChannelImpl to use the jdk internal event static methods, and
> removed the force() method from FileChannelImplInstrumentor.
>
> Uses the existing tests.
Tim Prinzing has updated the pull request incrementally with one
On Thu, 18 Apr 2024 14:32:28 GMT, Erik Gahlin wrote:
>> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 66:
>>
>>> 64: FileWriteEvent.class,
>>> 65: SocketReadEvent.class,
>>> 66: SocketWriteEvent.class,
>>
>> I'm guessing that this change
On Tue, 16 Apr 2024 15:49:08 GMT, Daniel Fuchs wrote:
>> I'm not sure what you mean about the recording. The file is the
>> AsynchronousFileChannel under test and does not contain the event recording.
>
> It's anyway better to create temporary files in the test scratch directory
> rather than
nts.FileForceEvent to be a mirror event.
>
> Updated FileChannelImpl to use the jdk internal event static methods, and
> removed the force() method from FileChannelImplInstrumentor.
>
> Uses the existing tests.
Tim Prinzing has updated the pull request incrementally with one
> 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 at jdk.jfr.event.io.TestSelectionEve
nts.FileForceEvent to be a mirror event.
>
> Updated FileChannelImpl to use the jdk internal event static methods, and
> removed the force() method from FileChannelImplInstrumentor.
>
> Uses the existing tests.
Tim Prinzing has updated the pull request incrementally with one
> 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 at jdk.jfr.event.io.TestSelectionEve
On Tue, 2 Apr 2024 04:48:37 GMT, Alan Bateman wrote:
>> Tim Prinzing has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add support for AsynchronousFileChannel.force().
>
> src/java.base/share/classes/jdk/inte
nts.FileForceEvent to be a mirror event.
>
> Updated FileChannelImpl to use the jdk internal event static methods, and
> removed the force() method from FileChannelImplInstrumentor.
>
> Uses the existing tests.
Tim Prinzing has updated the pull request incrementally with one
> 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 at jdk.jfr.event.io.TestSelectionEve
nts.FileForceEvent to be a mirror event.
>
> Updated FileChannelImpl to use the jdk internal event static methods, and
> removed the force() method from FileChannelImplInstrumentor.
>
> Uses the existing tests.
Tim Prinzing has updated the pull request incrementally with one
On Fri, 29 Mar 2024 00:52:46 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.
>
>
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.FileForceEvent, and changed
jdk.jfr.events.FileForceEvent to be a mirror
> 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 at jdk.jfr.event.io.TestSelectionEve
On Fri, 17 Nov 2023 16:27:44 GMT, Tim Prinzing wrote:
> Updated to use ProcessTool helper class to run test passing flags.
This pull request has now been integrated.
Changeset: b78896b9
Author: Tim Prinzing
Committer: Mandy Chung
URL:
https://git.openjdk.org/jdk/com
> 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 at jdk.jfr.event.io.TestSelectionEve
> 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 at jdk.jfr.event.io.TestSelectionEve
On Wed, 13 Dec 2023 18:47:50 GMT, Daniel Fuchs wrote:
>> Tim Prinzing has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 12 addi
On Thu, 23 Nov 2023 11:18:45 GMT, Erik Gahlin wrote:
>> src/jdk.jfr/share/classes/jdk/jfr/events/SelectionEvent.java line 43:
>>
>>> 41:
>>> 42: @Label("Selection Count")
>>> 43: @Description("Number of channels selected")
>>
>> I suspect you'll need to rename this event to something
On Fri, 8 Dec 2023 06:30:21 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/jdk/internal/event/SelectionEvent.java line 38:
>>
>>> 36: public class SelectionEvent extends Event {
>>> 37:
>>> 38: public int count;
>>
>> It could also be interesting to provide the `timeout` that was
> 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 at jdk.jfr.event.io.TestSelectionEve
On Fri, 17 Nov 2023 16:22:55 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::lockAndDoS
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 at jdk.jfr.event.io.TestSelectionEvents
-
Commit messages:
-
> Marked as flagless.
Tim Prinzing has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes brought in
by the merge/rebase. The pull request contains four additional commits since
the last revision:
-
Marked as flagless.
-
Commit messages:
- 8319571: Update jni/nullCaller/NullCallerTest.java to accept flags or mark
as flagless
Changes: https://git.openjdk.org/jdk/pull/16711/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=16711=00
Issue:
On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing wrote:
> The socket read/write JFR events currently use instrumentation of java.base
> code using templates in the jdk.jfr modules. This results in some java.base
> code residing in the jdk.jfr module which is undesirable.
>
> JDK
On Tue, 19 Sep 2023 15:35:11 GMT, Tim Prinzing wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
e at runtime with
> annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in
> make/test/BuildMicrobenchmark.gmk
Tim Prinzing has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 12 co
On Tue, 22 Aug 2023 07:18:21 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/net/Socket.java line 1133:
>>
>>> 1131: return parent.getSoTimeout();
>>> 1132: } catch (Throwable t) {
>>> 1133: // ignored - avoiding exceptions in jfr event
e at runtime with
> annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in
> make/test/BuildMicrobenchmark.gmk
Tim Prinzing has updated the pull request incrementally with one additional
commit since the last revision:
More changes
On Tue, 22 Aug 2023 07:31:36 GMT, Alan Bateman wrote:
> > https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling
> > https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event
> > generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking,
> > event
On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
e at runtime with
> annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in
> make/test/BuildMicrobenchmark.gmk
Tim Prinzing has updated the pull request incrementally with one additional
commit since the last revision:
less exception fi
e at runtime with
> annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in
> make/test/BuildMicrobenchmark.gmk
Tim Prinzing has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains
e at runtime with
> annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in
> make/test/BuildMicrobenchmark.gmk
Tim Prinzing has updated the pull request incrementally with one additional
commit since the last revision:
Avoid exc
On Thu, 22 Jun 2023 13:39:51 GMT, Erik Gahlin wrote:
> In cases where the implRead/implWrite call throws an exception, shouldn't the
> event contain that exception, or at least exception message? If it doesn't
> should it be emitted at all, or should another event be emitted instead?
Added
On Thu, 22 Jun 2023 10:21:46 GMT, Alan Bateman wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
>>
>> JDK19 added
The socket read/write JFR events currently use instrumentation of java.base
code using templates in the jdk.jfr modules. This results in some java.base
code residing in the jdk.jfr module which is undesirable.
JDK19 added static support for event classes. The old instrumentor classes
should be
47 matches
Mail list logo
