Re: RFR: 8331670: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal [v3]

2024-05-24 Thread Daniel Fuchs
On Tue, 21 May 2024 07:26:17 GMT, Alan Bateman wrote: >> This is the implementation changes for JEP 471. >> >> The methods in sun.misc.Unsafe for on-heap and off-heap access are >> deprecated for removal. This means a removal warning at compile time. No >> methods have been removed. A

Re: RFR: 8331987: Enhance stacktrace clarity for CompletableFuture CancellationException [v2]

2024-05-15 Thread Daniel Fuchs
On Mon, 13 May 2024 23:59:17 GMT, Viktor Klang wrote: >> This change adds wrapping of the CancellationException produced by >> CompletableFuture::get() and CompletableFuture::join() to add more >> diagnostic information and align better with FutureTask. >> >> Running the sample code from the

Re: RFR: 8332086: Remove the usage of ServiceLoader in j.u.r.RandomGeneratorFactory

2024-05-14 Thread Daniel Fuchs
On Mon, 13 May 2024 17:12:33 GMT, Raffaello Giulietti wrote: >> Not sure if that's an issue - but if you wanted/needed to delay the loading >> of those random generator classes that will not be used until something >> actually wants to use them, you could consider using a `Supplier> extends

Re: RFR: 8332086: Remove the usage of ServiceLoader in j.u.r.RandomGeneratorFactory

2024-05-13 Thread Daniel Fuchs
On Mon, 13 May 2024 13:21:23 GMT, Raffaello Giulietti wrote: >> A followup PR is fine. I think once this PR which addresses the API aspects >> (like removal of ServiceLoader and then updates to the create() method >> javadoc) is integrated, then the subsequent PR can just be all internal >>

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v3]

2024-05-13 Thread Daniel Fuchs
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and

Re: RFR: 8331876: JFR: Move file read and write events to java.base [v3]

2024-05-09 Thread Daniel Fuchs
On Thu, 9 May 2024 11:19:14 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 >> >> Thanks >> Erik > > Erik Gahlin has

Re: RFR: 8331514: Tests should not use the "Classpath" exception form of the legal header

2024-05-02 Thread Daniel Fuchs
On Thu, 2 May 2024 04:29:26 GMT, Jaikiran Pai wrote: > Can I please get a review of this copyright text only change which removes > the "Classpath" exception from the > `test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java` test file and > thus addresses

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base`

2024-04-19 Thread Daniel Fuchs
On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote: > Please review a set of updates to clean up use of `/**` comments in the > vicinity of declarations. > > There are various categories of update: > > * "Box comments" beginning with `/**` > * Misplaced doc comments before package or

Re: RFR: 8329138: Convert JFR FileForceEvent to static mirror event [v5]

2024-04-18 Thread Daniel Fuchs
On Wed, 17 Apr 2024 01:34:07 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

Re: RFR: 8329138: Convert JFR FileForceEvent to static mirror event [v2]

2024-04-16 Thread Daniel Fuchs
On Mon, 15 Apr 2024 20:41:10 GMT, Tim Prinzing wrote: >> test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 50: >> >>> 48: >>> 49: public static void main(String[] args) throws Throwable { >>> 50: File blah = File.createTempFile("blah", null); >> >> Can you

Re: RFR: 8310994: Add JFR event for selection operations [v3]

2024-04-11 Thread Daniel Fuchs
On Thu, 11 Apr 2024 16:08:31 GMT, Alan Bateman wrote: >> We should probably find a way to not emit the event if n == 0 and the >> operation was interrupted by `Selector.wakeUp`. Since we have another issue >> logged to emit a spin event, I wonder if we should only commit the event >> here if

Re: RFR: 8310994: Add JFR event for selection operations [v3]

2024-04-11 Thread Daniel Fuchs
On Mon, 26 Feb 2024 17:40:59 GMT, Alan Bateman wrote: >> Is n == 0 intended to detect a spinning condition where the selector goes >> back into select when the event has not been handled? >> >> In that case should we still emit an event if a timeout is present and the >> duration is greater

Result: New Core Libraries Group Member: Per-Ake Minborg

2024-04-03 Thread Daniel Fuchs
Hi, The vote for Per-Ake Minborg (pminborg) [1] is now closed. Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. best regards, -- daniel [1]

Re: RFR: 8329013: StackOverflowError when starting Apache Tomcat with signed jar [v2]

2024-04-02 Thread Daniel Fuchs
On Tue, 2 Apr 2024 14:59:33 GMT, Sean Coffey wrote: >> Calling extra logging calls during initialization of Logger libraries can >> cause recursion leading to StackOverflowError >> This patch adds logic to the EventHelper class to detect recursion and >> prevent it. > > Sean Coffey has updated

Re: RFR: 8329013: StackOverflowError when starting Apache Tomcat with signed jar [v2]

2024-04-02 Thread Daniel Fuchs
On Tue, 2 Apr 2024 13:38:00 GMT, Daniel Fuchs wrote: >> Sean Coffey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> incorporate testcase feedback from Daniel > > test/jdk/jdk/security/logging/RecursiveEven

Re: RFR: 8329013: StackOverflowError when starting Apache Tomcat with signed jar

2024-04-02 Thread Daniel Fuchs
On Thu, 28 Mar 2024 15:55:12 GMT, Sean Coffey wrote: > Calling extra logging calls during initialization of Logger libraries can > cause recursion leading to StackOverflowError > This patch adds logic to the EventHelper class to detect recursion and > prevent it. The code changes LGTM. Some

Re: RFR: 8325579: Inconsistent behavior in com.sun.jndi.ldap.Connection::createSocket [v9]

2024-03-21 Thread Daniel Fuchs
On Wed, 20 Mar 2024 21:19:38 GMT, Christoph Langer wrote: >> During analysing a customer case I figured out that we have an inconsistency >> between documentation and actual behavior in class >> com.sun.jndi.ldap.Connection. The [method documentation of >>

CFV: New Core Libraries Group Member: Per-Ake Minborg

2024-03-19 Thread Daniel Fuchs
Hi, I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the Core Libraries Group [4]. Per-Ake is an OpenJDK Reviewer, a committer in the Leyden and Panama projects, and a member of Oracle’s Java Core Libraries team. Per-Ake has been actively participating in the development of

Re: RFR: 8325579: Inconsistent behavior in com.sun.jndi.ldap.Connection::createSocket [v8]

2024-03-15 Thread Daniel Fuchs
On Thu, 14 Mar 2024 21:59:54 GMT, Christoph Langer wrote: >> During analysing a customer case I figured out that we have an inconsistency >> between documentation and actual behavior in class >> com.sun.jndi.ldap.Connection. The [method documentation of >>

Re: RFR: 8328066: WhiteBoxResizeTest failure on linux-x86: Could not reserve enough space for 2097152KB object heap

2024-03-14 Thread Daniel Fuchs
On Thu, 14 Mar 2024 04:11:14 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which proposes to address > https://bugs.openjdk.org/browse/JDK-8328066? > > The test launches a JVM with 2G heap (`-Xmx2G`) and as noted in that issue, > the failure was observed on

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v3]

2024-03-07 Thread Daniel Fuchs
On Tue, 5 Mar 2024 19:53:46 GMT, Weijun Wang wrote: >> Subject is stored in the RMIConnectionImpl: >> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java >> >> (That is complicated by SubjectDelegation, which we deprecated for removal. >> I have the PR

Re: RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc

2024-02-27 Thread Daniel Fuchs
On Mon, 26 Feb 2024 19:55:47 GMT, Lance Andersen wrote: > This PR updates the javadoc and comments within java.util.zip/jar and zipfs > module summary so that it is consistent with the use of "ZIP". > > In addition, open/src/java.base/share/classes/java/util/zip/package-info.java > has been

Re: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer [v4]

2024-02-26 Thread Daniel Fuchs
On Mon, 15 Jan 2024 08:36:43 GMT, Stefan Karlsson wrote: >> Tests using ProcessTools.executeProcess gets the following output written to >> stdout: >> [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117 >> [2023-11-24T09:58:23.070781345Z] Waiting for completion for process

Re: RFR: 8310994: Add JFR event for selection operations [v3]

2024-02-26 Thread Daniel Fuchs
On Wed, 3 Jan 2024 11:11:40 GMT, Alan Bateman wrote: >> Tim Prinzing has updated the pull request incrementally with one additional >> commit since the last revision: >> >> add select timeout field to the event > > src/java.base/share/classes/sun/nio/ch/SelectorImpl.java line 153: > >> 151:

Re: RFR: 8310994: Add JFR event for selection operations [v2]

2024-02-26 Thread Daniel Fuchs
On Wed, 13 Dec 2023 18:49:08 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

Re: RFR: 8310994: Add JFR event for selection operations [v2]

2024-02-26 Thread Daniel Fuchs
On Wed, 13 Dec 2023 18:58:40 GMT, Tim Prinzing wrote: >> src/java.base/share/classes/jdk/internal/event/SelectorSelectEvent.java line >> 41: >> >>> 39: public class SelectorSelectEvent extends Event { >>> 40: >>> 41: public int selectionKeyCount; >> >> I still believe we should record

Re: CFV: New Core Libraries Group Member: Viktor Klang

2024-02-20 Thread Daniel Fuchs
Vote: yes best regards, -- daniel On 19/02/2024 23:40, Stuart Marks wrote: I hereby nominate Viktor Klang [6] to Membership in the Core Libraries Group [4].

Re: RFR: 8325579: Inconsistent behavior in com.sun.jndi.ldap.Connection::createSocket [v5]

2024-02-16 Thread Daniel Fuchs
On Fri, 16 Feb 2024 10:27:11 GMT, Christoph Langer wrote: >> During analysing a customer case I figured out that we have an inconsistency >> between documentation and actual behavior in class >> com.sun.jndi.ldap.Connection. The [method documentation of >>

Re: CFV: New Core Libraries Group Member: Raffaello Giulietti

2024-02-14 Thread Daniel Fuchs
Vote: yes best regards, -- daniel On 13/02/2024 20:25, Brian Burkhalter wrote: I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.

Re: RFR: 8325558: Add jcheck whitespace checking for properties files

2024-02-12 Thread Daniel Fuchs
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote: > This is an attempt to finally implement the idea brought forward in > JDK-8295729: Properties files is essentially source code. It should have the > same whitespace checks as all other source code, so we don't get spurious >

Re: RFR: 8325558: Add jcheck whitespace checking for properties files

2024-02-09 Thread Daniel Fuchs
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote: > This is an attempt to finally implement the idea brought forward in > JDK-8295729: Properties files is essentially source code. It should have the > same whitespace checks as all other source code, so we don't get spurious >

Re: RFR: JDK-8325189: Enable this-escape javac warning in java.base

2024-02-06 Thread Daniel Fuchs
On Tue, 6 Feb 2024 17:29:25 GMT, Joe Darcy wrote: >> src/java.base/share/classes/sun/net/www/MessageHeader.java line 53: >> >>> 51: } >>> 52: >>> 53: @SuppressWarnings("this-escape") >> >> An alternative here could be to make the class final. AFAICS it's not >> subclassed anywhere.

Re: RFR: JDK-8325189: Enable this-escape javac warning in java.base

2024-02-06 Thread Daniel Fuchs
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the > base module was not updated to be able to compile with this warning enabled. > This PR makes the necessary changes to allow the base module to build with > the

Re: RFR: 8325109: Sort method modifiers in canonical order

2024-02-01 Thread Daniel Fuchs
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on > [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the > bin/blessed-modifier-order.sh on the entire code base, and manually checked > the result. I have reverted all but these trivial

Re: RFR: 8325001: Typo in the javadocs for the Arena::ofShared method

2024-01-31 Thread Daniel Fuchs
On Wed, 31 Jan 2024 13:12:10 GMT, Per Minborg wrote: > This PR fixes a typo in the documentation for the `Arena::ofShared`. LGTM - Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17653#pullrequestreview-1854679366

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs

2024-01-30 Thread Daniel Fuchs
On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang wrote: > This code change adds an alternative implementation of user-based > authorization `Subject` APIs that doesn't depend on Security Manager APIs. > Depending on if the Security Manager is allowed, the methods store the > current subject

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs

2024-01-30 Thread Daniel Fuchs
On Tue, 30 Jan 2024 13:53:37 GMT, Daniel Fuchs wrote: >> This code change adds an alternative implementation of user-based >> authorization `Subject` APIs that doesn't depend on Security Manager APIs. >> Depending on if the Security Manager is allowed, the methods store the

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs

2024-01-30 Thread Daniel Fuchs
On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang wrote: > This code change adds an alternative implementation of user-based > authorization `Subject` APIs that doesn't depend on Security Manager APIs. > Depending on if the Security Manager is allowed, the methods store the > current subject

Re: RFR: 8324053: Use the blessed modifier order for sealed in java.base

2024-01-18 Thread Daniel Fuchs
On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo wrote: > Please review this trivial PR to reorder the `sealed` class or interface > modifier. For context of this change see: > https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396. LGTM - Marked as reviewed by dfuchs

Re: RFR: 8323562: SaslInputStream.read() may return wrong value

2024-01-12 Thread Daniel Fuchs
On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov wrote: > SaslInputStream.read() should return a value in the range from 0 to 255 per > the spec of InputStream.read() but it returns the signed byte from the inBuf > as is. Marked as reviewed by dfuchs (Reviewer). - PR Review:

Re: RFR: 8323562: SaslInputStream.read() may return wrong value

2024-01-12 Thread Daniel Fuchs
On Fri, 12 Jan 2024 11:54:06 GMT, Alan Bateman wrote: > I think this one will require digging into whether the no-arg read is used in > the authentication or not. It might not be, in which case it's not testable > with something that emulates LDAPv3. However if it is used then we should >

Re: RFR: 8275338: Add JFR events for notable serialization situations [v12]

2024-01-10 Thread Daniel Fuchs
On Tue, 9 Jan 2024 10:46:27 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java >> line 70: >> >>> 68: privilegedCheckAccessibleMethod(cl, WRITE_REPLACE_NAME, >>> 69: WRITE_REPLACE_PARAM_TYPES,

Re: RFR: 8275338: Add JFR events for notable serialization situations [v12]

2024-01-09 Thread Daniel Fuchs
On Tue, 9 Jan 2024 10:42:58 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java >> line 87: >> >>> 85: } >>> 86: if (cl.isEnum()) { >>> 87: commitEvent(cl, SUID_NAME + " in an enum class is not >>>

Re: RFR: 8275338: Add JFR events for notable serialization situations [v3]

2023-12-20 Thread Daniel Fuchs
On Tue, 19 Dec 2023 19:39:22 GMT, Roger Riggs wrote: >> What about fixed `String`s rather than `int`s for the kind of error? >> Something like `"SUID_INEFFECTIVE_ON_ENUM"`, and so on? >> It would be nice to be able to use enums, but AFAIK that's not supported in >> JFR. > > You could define

Re: RFR: 8275338: Add JFR events for notable serialization situations [v4]

2023-12-20 Thread Daniel Fuchs
On Tue, 19 Dec 2023 16:00:09 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/jdk/internal/event/SerializationMisdeclarationEvent.java >> line 94: >> >>> 92: >>> 93: /* >>> 94: * These constants are not final on purpose. >> >> Just curious - what's the purpose? I

Re: RFR: 8310994: Add JFR event for selection operations [v2]

2023-12-13 Thread Daniel Fuchs
On Wed, 13 Dec 2023 18:38:11 GMT, Tim Prinzing wrote: >>> It could also be interesting to provide the `timeout` that was given to the >>> selection operation. >> >> I've tried to work through issues, esp. around selector spinning, and being >> able to distinguish select from selectNow is

Re: RFR: 8310994: Add JFR event for selection operations [v2]

2023-12-13 Thread Daniel Fuchs
On Wed, 13 Dec 2023 18:38:09 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

Re: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite)

2023-11-27 Thread Daniel Fuchs
On Mon, 27 Nov 2023 15:00:54 GMT, Daniel Fuchs wrote: >> On the Property name: there is an existing System Property >> "sun.rmi.transport.connectionTimeout" which is a 15-second idle timeout. >> Having a "connectionTimeout" and this new one as "c

Re: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite)

2023-11-27 Thread Daniel Fuchs
On Mon, 27 Nov 2023 14:35:07 GMT, Kevin Walls wrote: >> wrt to the property name initialConnectTimeout might infer that it is an >> initial value which can be subsequentually modified, but that is not >> possible. As such, would sun.rmi.transport.tcp.connectTimeout be more >> appropriate --

Re: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite)

2023-11-24 Thread Daniel Fuchs
On Fri, 24 Nov 2023 12:13:56 GMT, Kevin Walls wrote: >> (Look for socket factories in the module `jdk.management.agent`) > > OK yes, we also have: > java.rmi/share/classes/javax/rmi/ssl/SslRMIClientSocketFactory.java > with its own createSocket(String host, int port) method. This is used if we

Re: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite)

2023-11-23 Thread Daniel Fuchs
On Thu, 23 Nov 2023 17:17:34 GMT, Daniel Fuchs wrote: >>> I see Integer.getInteger handles the obvious Exceptions, so specifying a >>> strange value does not immediately break us. >> >> Oh - right. It's `Integer.getInteger`, not `Integer.parseInt` Ok, then - I

Re: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite)

2023-11-23 Thread Daniel Fuchs
On Thu, 23 Nov 2023 17:14:52 GMT, Daniel Fuchs wrote: >>> IIRC, the default agent uses / may use its own socket factories - are we >>> still coming here even with those factories? >> >> We do get here, yes (not saying you can't customise your way out of getting &

Re: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite)

2023-11-23 Thread Daniel Fuchs
On Thu, 23 Nov 2023 12:43:33 GMT, Kevin Walls wrote: >>> An exception here will prevent the class from being initialized... >> >> Maybe we can break it, but this new property is following the same pattern I >> think as the neighbouring file >>

Re: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite)

2023-11-23 Thread Daniel Fuchs
On Tue, 21 Nov 2023 17:57:32 GMT, Kevin Walls wrote: > RMI Connections (in general) should use a timeout on the Socket connect call > by default. > > JMX connections use RMI and some connection failures never terminate. The > hang described in 8316649 is hard to reproduce manually: the

Re: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite)

2023-11-23 Thread Daniel Fuchs
On Thu, 23 Nov 2023 11:35:11 GMT, Daniel Fuchs wrote: >> RMI Connections (in general) should use a timeout on the Socket connect call >> by default. >> >> JMX connections use RMI and some connection failures never terminate. The >> hang described in 8316649

Re: RFR: 8310994: Add JFR event for selection operations

2023-11-22 Thread Daniel Fuchs
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::lockAndDoSelect > > Test at

Re: RFR: JDK-8319569: Several java/util tests should be updated to accept VM flags [v2]

2023-11-20 Thread Daniel Fuchs
On Fri, 17 Nov 2023 20:20:43 GMT, Justin Lu wrote: >> Please review this PR which allows these _j.util_ tests to launch new JVM >> processes with VM flags, >> >> This is primarily done using by switching to >> `ProcessTools::createTestJavaProcessBuilder`. >> >> _PropertiesTest.sh_ was

Re: RFR: 8317834: java/lang/Thread/IsAlive.java timed out

2023-11-14 Thread Daniel Fuchs
On Tue, 14 Nov 2023 16:41:31 GMT, Darragh Clarke wrote: > Currently the `IsAlive` test occasionally times out. > > This PR changes the timeout from `10` to `25` which I think is an adequate > increase based on the failures I've seen. Though I'd be happy to change it to > another value if

Re: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v3]

2023-11-10 Thread Daniel Fuchs
On Fri, 10 Nov 2023 09:32:17 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional > commits since the last revision: > > - Multiple improvements to Gatherer and

Re: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2]

2023-11-09 Thread Daniel Fuchs
On Thu, 9 Nov 2023 09:34:26 GMT, Viktor Klang wrote: >> I think it's still better to specify this for every method. Many developers >> read the documentation only for the specific method they are going to call, >> using IDE features like quick documentation. > > Yeah, I agree with @amaembo, I

Re: RFR: 8319374: JFR: Remove instrumentation for exception events [v3]

2023-11-08 Thread Daniel Fuchs
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:

Re: RFR: 8316144: Remove unused field jdk.internal.util.xml.impl.XMLStreamWriterImpl.Element._Depth

2023-09-29 Thread Daniel Fuchs
On Wed, 27 Sep 2023 09:22:35 GMT, Andrey Turbanov wrote: > BTW, Who is Joe? I believe that would be @JoeWang-Java - PR Comment: https://git.openjdk.org/jdk/pull/15692#issuecomment-1741186962

Re: RFR: 8317141: Remove unused validIndex method from URLClassPath$JarLoader

2023-09-29 Thread Daniel Fuchs
On Fri, 29 Sep 2023 05:41:11 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes unused (internal) > method from the `private` `URLClassPath$JarLoader`? > > The `validIndex` method which is being removed here was being used when JAR > index was supported. We

Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v6]

2023-09-20 Thread Daniel Fuchs
On Tue, 19 Sep 2023 20:51:41 GMT, Tim Prinzing wrote: > The existing JFR tests TestSocketChannelEvents and TestSocketEvents in > jdk.jfr.event.io verify the events are still emitted as expected. Thanks Tim. Should 8308995 be listed in the `@bug` clause of these two tests? - PR

Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v3]

2023-09-19 Thread Daniel Fuchs
On Thu, 7 Sep 2023 21:54:44 GMT, Tim Prinzing wrote: > No. I think it's a relic from the distant past though. I think the timeout > field should be removed. It's not used on SocketChannel at all, and it > doesn't seem useful on Socket. Should we log an RFE to that effect? - PR

Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v5]

2023-09-19 Thread Daniel Fuchs
On Thu, 7 Sep 2023 21:50:17 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

Re: RFR: 8316087: Test SignedLoggerFinderTest.java is still failing

2023-09-13 Thread Daniel Fuchs
On Wed, 13 Sep 2023 11:26:30 GMT, Sean Coffey wrote: > Some log messages from the test may be dropped if the bootstraplogger is in > use at time of log call. (bootstap logger logs at INFO level, the security > event logger logs at DEBUG level) > > Modify the test to use a patched EventHelper

Re: RFR: 8277954: Replace use of monitors with explicit locks in the JDK LDAP provider implementation

2023-09-08 Thread Daniel Fuchs
On Thu, 31 Aug 2023 22:48:30 GMT, Aleksei Efimov wrote: > The change proposed in this PR improves the behavior of the JDK JNDI/LDAP > provider when running in a virtual thread. Currently, when an LDAP operation > is performed from a virtual thread context a pinned carrier thread is >

Re: RFR: 8315696: SignedLoggerFinderTest.java test failed

2023-09-08 Thread Daniel Fuchs
On Tue, 5 Sep 2023 20:06:41 GMT, Sean Coffey wrote: > Update the recently added LoggerFinder tests to cater for a possible > condition where the test finishes before the boot logger executor service has > flushed its pending data. > > By simulating a slow thread in the ExecutorService used in

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v12]

2023-09-07 Thread Daniel Fuchs
On Thu, 7 Sep 2023 19:27:14 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current >> implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v11]

2023-09-07 Thread Daniel Fuchs
On Thu, 7 Sep 2023 18:22:40 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current >> implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per

Re: RFR: 8267174: Many test files have the wrong Copyright header

2023-09-06 Thread Daniel Fuchs
On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect > copyright header, which includes the "classpath" exception text. This patch > removes that text from all test files that I could find it in. I did this > using

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v8]

2023-08-30 Thread Daniel Fuchs
On Tue, 29 Aug 2023 20:51:56 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current >> implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v7]

2023-08-29 Thread Daniel Fuchs
On Tue, 29 Aug 2023 16:39:56 GMT, Mandy Chung wrote: >> src/java.base/share/classes/java/lang/StackWalker.java line 73: >> >>> 71: * 1. To find the first caller filtering a known list of >>> implementation class: >>> 72: * {@snippet lang="java" : >>> 73: * StackWalker walker = >>>

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v7]

2023-08-29 Thread Daniel Fuchs
On Tue, 29 Aug 2023 00:16:40 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current >> implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per

Re: RFR: 8314263: Signed jars triggering Logger finder recursion and StackOverflowError [v6]

2023-08-29 Thread Daniel Fuchs
On Tue, 29 Aug 2023 11:58:14 GMT, Sean Coffey wrote: >> Recursive initialization calls possible during loading of LoggerFinder >> service. >> >> This fix detects the recursive call and returns a temporary LoggerFinder >> that is backed by a lazy logger. Automated test case developed to

Re: RFR: 8314263: Signed jars triggering Logger finder recursion and StackOverflowError [v5]

2023-08-28 Thread Daniel Fuchs
On Mon, 28 Aug 2023 18:49:40 GMT, Daniel Fuchs wrote: >> Sean Coffey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix up test cases > > test/jdk/java/lang/System/LoggerFinder/RecursiveLoading/PlatformRec

Re: RFR: 8314263: Signed jars triggering Logger finder recursion and StackOverflowError [v5]

2023-08-28 Thread Daniel Fuchs
On Mon, 28 Aug 2023 18:45:03 GMT, Sean Coffey wrote: >> Recursive initialization calls possible during loading of LoggerFinder >> service. >> >> This fix detects the recursive call and returns a temporary LoggerFinder >> that is backed by a lazy logger. Automated test case developed to

Re: RFR: 8314263: Signed jars triggering Logger finder recursion and StackOverflowError [v4]

2023-08-28 Thread Daniel Fuchs
On Mon, 28 Aug 2023 17:29:16 GMT, Sean Coffey wrote: >> Recursive initialization calls possible during loading of LoggerFinder >> service. >> >> This fix detects the recursive call and returns a temporary LoggerFinder >> that is backed by a lazy logger. Automated test case developed to

Re: RFR: 8314263: Signed jars triggering Logger finder recursion and StackOverflowError [v4]

2023-08-28 Thread Daniel Fuchs
On Mon, 28 Aug 2023 17:42:34 GMT, Daniel Fuchs wrote: >> Sean Coffey has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Tidy up SignedLoggerFinderTest.java >> - Code contribution from Daniel included. N

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v6]

2023-08-28 Thread Daniel Fuchs
On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current >> implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v4]

2023-08-24 Thread Daniel Fuchs
On Wed, 23 Aug 2023 20:27:38 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current >> implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per

Re: RFR: 8314759: VirtualThread.parkNanos timeout adjustment when pinned should be replaced

2023-08-24 Thread Daniel Fuchs
On Wed, 23 Aug 2023 16:41:23 GMT, Alan Bateman wrote: > If yielding fails due to the pinning then VirtualThread.parkNanos parks on > the carrier thread with the remaining time. The calculation of the remaining > time needs to be replaced so that it obviously uses the difference between > the

Re: RFR: 8314759: VirtualThread.parkNanos timeout adjustment when pinned should be replaced

2023-08-24 Thread Daniel Fuchs
On Wed, 23 Aug 2023 16:41:23 GMT, Alan Bateman wrote: > If yielding fails due to the pinning then VirtualThread.parkNanos parks on > the carrier thread with the remaining time. The calculation of the remaining > time needs to be replaced so that it obviously uses the difference between > the

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v3]

2023-08-23 Thread Daniel Fuchs
On Tue, 22 Aug 2023 19:01:53 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current >> implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per

Re: RFR: 8314263: Signed jars triggering Logger finder recursion and StackOverflowError

2023-08-23 Thread Daniel Fuchs
On Wed, 23 Aug 2023 15:41:16 GMT, Sean Coffey wrote: > Recursive initialization calls possible during loading of LoggerFinder > service. > > This fix detects the recursive call and returns a temporary LoggerFinder that > is backed by a lazy logger. Automated test case developed to simulate

Re: RFR: 8314263: Signed jars triggering Logger finder recursion and StackOverflowError

2023-08-23 Thread Daniel Fuchs
On Wed, 23 Aug 2023 17:15:03 GMT, Daniel Fuchs wrote: >> Recursive initialization calls possible during loading of LoggerFinder >> service. >> >> This fix detects the recursive call and returns a temporary LoggerFinder >> that is backed by a lazy logger.

Re: RFR: 8313768: Reduce interaction with volatile field in j.u.l.StreamHandler

2023-08-08 Thread Daniel Fuchs
On Fri, 4 Aug 2023 14:51:35 GMT, Sergey Tsypanov wrote: > In `publish0()`, `flush0()` and `flushAndClose()`methods of `StreamHandler` > we read multiple times from volatile writer. The access number can be reduced > by reading the field into local variable once. LGTM - Marked as

Re: [jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC

2023-07-31 Thread Daniel Fuchs
On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes wrote: > Main changes are to use 21 instead of 21-ea. In addition the following files > contain additional updates from the closed sources: > > - src/java.base/share/man/java.1 > > [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131):

Re: RFR: 8310892: ScopedValue throwing StructureViolationException should be clearer [v3]

2023-07-10 Thread Daniel Fuchs
On Mon, 10 Jul 2023 05:05:13 GMT, Alan Bateman wrote: >> Docs only update to add a missing `@throws StructureViolationException` and >> make it clearer when the exception is thrown. In the future we might >> re-visit this so that the description is in one place rather than in each >> method.

Integrated: 8310987: Missing @since tag(s) in java/util/logging/ErrorManager.java

2023-06-30 Thread Daniel Fuchs
On Fri, 30 Jun 2023 09:06:20 GMT, Daniel Fuchs wrote: > Please find here a trivial doc fix to add a missing `@since 1.4` to the > java.util.logging.ErrorManager class. This pull request has now been integrated. Changeset: e8ff74c7 Author:Daniel Fuchs URL: https://git.openj

RFR: 8310987: Missing @since tag(s) in java/util/logging/ErrorManager.java

2023-06-30 Thread Daniel Fuchs
Please find here a trivial doc fix to add a missing `@since 1.4` to the java.util.logging.ErrorManager class. - Commit messages: - 8310987 Changes: https://git.openjdk.org/jdk/pull/14725/files Webrev: https://webrevs.openjdk.org/?repo=jdk=14725=00 Issue:

Re: RFR: 8311030: ResourceBundle.handleKeySet() is racy

2023-06-29 Thread Daniel Fuchs
On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov wrote: > Double-checked locking should rely on local variable to avoid racy reads from > volatile field. The new code makes it more visible that 1. keySet is expected to be volatile and 2. that there is no path were code could be reordered

Re: RFR: 8310892: ScopedValue throwing StructureViolationException should be clearer

2023-06-27 Thread Daniel Fuchs
On Tue, 27 Jun 2023 15:34:58 GMT, Alan Bateman wrote: > Docs only update to add a missing `@throws StructureViolationException` and > make it clearer when the exception is thrown. In the future we might re-visit > this so that the description is in one place rather than in each method. I like

Re: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]

2023-06-27 Thread Daniel Fuchs
On Tue, 27 Jun 2023 13:38:11 GMT, Chen Liang wrote: >>> It's a bit smelly to have a public static field of type array. Static >>> analysers are likely to flag this. It would be better to make the field >>> private and have a public static method that returns DIGITS.clone() - then >>> each

Re: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]

2023-06-27 Thread Daniel Fuchs
On Tue, 27 Jun 2023 11:27:18 GMT, 温绍锦 wrote: >> By optimizing the implementation of java.lang.Long#fastUUID, the performance >> of the java.util.UUID#toString method can be significantly improved. >> >> The following are the test results of JMH: >> >> Benchmark Mode Cnt

Re: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]

2023-06-22 Thread Daniel Fuchs
On Wed, 21 Jun 2023 15:03:12 GMT, Sergey Tsypanov wrote: >> Just a tiny clean-up to remove racy read within synchronized method > > Sergey Tsypanov has updated the pull request incrementally with one > additional commit since the last revision: > > Update

Re: RFR: 8308995: Update Network IO JFR events to be static mirror events

2023-06-22 Thread Daniel Fuchs
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. > > JDK19 added static

Re: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]

2023-06-21 Thread Daniel Fuchs
On Wed, 21 Jun 2023 14:27:26 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/io/PipedOutputStream.java line 166: >> >>> 164: @Override >>> 165: public synchronized void flush() throws IOException { >>> 166: PipedInputStream sink = this.sink; >> >> Suggestion: >> >>

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]

2023-06-14 Thread Daniel Fuchs
On Wed, 14 Jun 2023 13:13:50 GMT, Alan Bateman wrote: >> Replaced it with a ReentrantLock > >> Replaced it with a ReentrantLock > > The concern is that this is a system-wide lock and so creates the potential > for contention when many threads are bashing on Locale.of and other methods. >

  1   2   3   >