On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing 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 f
On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing wrote:
> I think it's useful if trying to trace the calls (i.e. set to 0ms).
> Apparently the security manager was being used for that by some.
The SM isn't called once connected so I don't think anyone could have every
done that. Yes, you could se
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.
>>
>> JDK19 added sta
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.
>>
>> JDK19 added sta
On Tue, 27 Jun 2023 18:29:45 GMT, Tim Prinzing wrote:
>> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 408:
>>
>>> 406: @Override
>>> 407: public int read(ByteBuffer buf) throws IOException {
>>> 408: if (!SocketReadEvent.enabled()) {
>>
>> The read/write wi
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.
>>
>> JDK19 added sta
On Wed, 2 Aug 2023 20:09:39 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
> for selec
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.
>>
>> JDK19 added sta
On Wed, 2 Aug 2023 18:19:27 GMT, Tim Prinzing wrote:
> I believe this has all requested changes or has separate bug reports to
> address changes yet needing to be made.
> https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling
> https://bugs.openjdk.org/browse/JDK-8310978 - mis
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.
>>
>> JDK19 added sta
> 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
12 matches
Mail list logo