Re: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly [v3]

2022-11-08 Thread Daniel Fuchs
On Tue, 8 Nov 2022 00:26:56 GMT, Aleksei Efimov wrote: >> ### The Proposed Change >> >> The proposed change updates JNDI's `DnsClient` internal implementation to >> use `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS). >> The main motivation behind this change is to make

Re: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly [v2]

2022-11-07 Thread Daniel Fuchs
On Mon, 7 Nov 2022 15:39:55 GMT, Aleksei Efimov wrote: >> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 470: >> >>> 468: } while (timeoutLeft > MIN_TIMEOUT); >>> 469: // no matching packet received within the timeout >>> 470:

Re: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly [v2]

2022-11-07 Thread Daniel Fuchs
On Mon, 7 Nov 2022 19:28:56 GMT, Aleksei Efimov wrote: >> ### The Proposed Change >> >> The proposed change updates JNDI's `DnsClient` internal implementation to >> use `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS). >> The main motivation behind this change is to make

Integrated: 8294241: Deprecate URL public constructors

2022-11-03 Thread Daniel Fuchs
On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote: > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` > to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components > according to the escaping me

Re: RFR: 8294241: Deprecate URL public constructors [v5]

2022-11-03 Thread Daniel Fuchs
Some related > issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated chan

Re: RFR: 8294241: Deprecate URL public constructors [v3]

2022-11-03 Thread Daniel Fuchs
On Thu, 3 Nov 2022 07:42:44 GMT, ExE Boss wrote: >> Daniel Fuchs 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 six addi

Re: RFR: 8294241: Deprecate URL public constructors [v4]

2022-11-03 Thread Daniel Fuchs
On Thu, 3 Nov 2022 10:56:28 GMT, Michael McMahon wrote: >> Daniel Fuchs has updated the pull request incrementally with three >> additional commits since the last revision: >> >> - Update src/java.base/share/classes/java/net/URL.java >> >>Co-

Re: RFR: 8294241: Deprecate URL public constructors [v4]

2022-11-03 Thread Daniel Fuchs
Some related > issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision: - Update src/java.base/share/classe

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-11-01 Thread Daniel Fuchs
On Tue, 1 Nov 2022 14:47:49 GMT, Alan Bateman wrote: >> Actually... Maybe I could move up the paragraph that says that URL >> constructors are deprecated up here, just after the h2 title? Would >> that be better? > > Try it, it might be better. I think the main thing is that link brings the >

Re: RFR: 8294241: Deprecate URL public constructors [v3]

2022-11-01 Thread Daniel Fuchs
Some related > issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated chang

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-11-01 Thread Daniel Fuchs
On Tue, 1 Nov 2022 14:10:01 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/java/net/URL.java line 133: >> >>> 131: * specified. The optional fragment is not inherited. >>> 132: * >>> 133: * Constructing instances of >>> {@code U

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-11-01 Thread Daniel Fuchs
On Sat, 29 Oct 2022 14:24:09 GMT, Alan Bateman wrote: >> Daniel Fuchs 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 contai

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-11-01 Thread Daniel Fuchs
On Sat, 29 Oct 2022 14:17:12 GMT, Alan Bateman wrote: >> Daniel Fuchs 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 contai

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-11-01 Thread Daniel Fuchs
On Sat, 29 Oct 2022 14:16:24 GMT, Alan Bateman wrote: >> Daniel Fuchs 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 contai

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-11-01 Thread Daniel Fuchs
On Sat, 29 Oct 2022 14:14:22 GMT, Alan Bateman wrote: >> Daniel Fuchs 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 contai

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-11-01 Thread Daniel Fuchs
On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race wrote: > Deprecate URL constructors. Developers are encouraged to use java.net.URI to > parse or construct any URL. ... To construct a URL, using URI::toURL should > be preferred. > > You have jumped through some refactoring hoops to be able to

Re: RFR: 8295729: Add jcheck whitespace checking for properties files [v3]

2022-11-01 Thread Daniel Fuchs
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same >> whitespace checks as all other source code, so we don't get spurious >> trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to

Re: RFR: 8294241: Deprecate URL public constructors [v2]

2022-10-28 Thread Daniel Fuchs
Some related > issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated change

Re: RFR: 8294241: Deprecate URL public constructors

2022-10-27 Thread Daniel Fuchs
On Thu, 27 Oct 2022 17:50:37 GMT, Andrey Turbanov wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` >> to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components >> according to the escaping mechanism

Re: RFR: 8294241: Deprecate URL public constructors

2022-10-27 Thread Daniel Fuchs
On Thu, 27 Oct 2022 17:20:04 GMT, Joe Wang wrote: > Hi Daniel, if it's not a major improvement, we'd like to keep the java.xml > module at the JDK 8 code level. Can we remove the 'var' usage in a few > java.xml classes? No problem - I will make this change when we have settled on a name for

Re: RFR: 8294241: Deprecate URL public constructors

2022-10-27 Thread Daniel Fuchs
On 27/10/2022 07:26, Alan Bateman wrote: We have a strict URI 3986 implementation, which we use to create all URL instances from. Note also that though this change proposes to deprecate these constructors in order to provide a stronger warning against their potential misuse, it does not

Re: RFR: 8294241: Deprecate URL public constructors

2022-10-27 Thread Daniel Fuchs
On Thu, 27 Oct 2022 09:17:29 GMT, Michael McMahon wrote: >> Having unnamed local variables[^1] would probably be best for this. >> >> [^1]: https://openjdk.org/jeps/8294349 > > How about `_unused` or `_unused1`, `_unused2` then in the meantime? I'd be happy to make the change. Let's wait to

Re: RFR: 8294241: Deprecate URL public constructors

2022-10-26 Thread Daniel Fuchs
On Wed, 26 Oct 2022 17:39:56 GMT, Xue-Lei Andrew Fan wrote: >> `URLStreamHandler` really belongs to `java.net.URL`, and is an >> implementation detail of the infrastructure/SPI that makes it possible to >> eventually call `URL::openConnection`. I do not think it would be >> appropriate to

Re: RFR: 8294241: Deprecate URL public constructors

2022-10-26 Thread Daniel Fuchs
On Wed, 26 Oct 2022 17:09:20 GMT, Xue-Lei Andrew Fan wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` >> to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components >> according to the escaping

RFR: 8294241: Deprecate URL public constructors

2022-10-26 Thread Daniel Fuchs
Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any

Re: RFR: 8295823: Use enhanced-for cycle instead of Enumeration in java.naming

2022-10-24 Thread Daniel Fuchs
On Thu, 20 Oct 2022 20:28:37 GMT, Andrey Turbanov wrote: > `java.util.Enumeration` is a legacy interface from java 1.0. > There are couple of cycles which use it to iterate over collections. We can > replace this manual cycle with enchanced-for, which is shorter and easier to > read. LGTM

Re: RFR: 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation [v6]

2022-10-18 Thread Daniel Fuchs
On Mon, 17 Oct 2022 15:32:55 GMT, Aleksei Efimov wrote: >> ### Summary of the change >> This change introduces new system and security properties for specifying >> factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider >> implementations. >> >> These new properties allow more

Re: RFR: 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation [v5]

2022-10-14 Thread Daniel Fuchs
On Fri, 14 Oct 2022 16:19:41 GMT, Aleksei Efimov wrote: >> ### Summary of the change >> This change introduces new system and security properties for specifying >> factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider >> implementations. >> >> These new properties allow more

Re: RFR: 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation [v3]

2022-10-10 Thread Daniel Fuchs
On Mon, 10 Oct 2022 14:28:07 GMT, Aleksei Efimov wrote: >> ### Summary of the change >> This change introduces new system and security properties for specifying >> factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider >> implementations. >> >> These new properties allow more

Re: RFR: 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation [v2]

2022-10-10 Thread Daniel Fuchs
On Mon, 10 Oct 2022 12:07:38 GMT, Aleksei Efimov wrote: >> src/java.naming/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java >> line 99: >> >>> 97: return globalResult == Status.ALLOWED; >>> 98: } >>> 99: >> >> If I'm not mistaken there's no point in

Re: RFR: 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation [v2]

2022-10-10 Thread Daniel Fuchs
On Sun, 9 Oct 2022 11:52:18 GMT, Aleksei Efimov wrote: >> ### Summary of the change >> This change introduces new system and security properties for specifying >> factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider >> implementations. >> >> These new properties allow more

Re: RFR: 8290368: Introduce LDAP and RMI protocol-specific object factory filters to JNDI implementation

2022-10-06 Thread Daniel Fuchs
On Wed, 5 Oct 2022 15:23:43 GMT, Aleksei Efimov wrote: > ### Summary of the change > This change introduces new system and security properties for specifying > factory filters for the JNDI/LDAP and the JNDI/RMI JDK provider > implementations. > > These new properties allow more granular

Re: RFR: 8293810: Remove granting of RuntimePermission("stopThread") from tests

2022-10-05 Thread Daniel Fuchs
On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman wrote: > This is a test only change to remove the granting of > RuntimePermission("stopThread") from the tests. With Thread.stop changed to > throw UOE it means there is nothing that requires this permission. Changes to java.net and

Re: RFR: 8294697: java/lang/Thread/virtual/ThreadAPI.testGetStackTrace2 failed with non-empty stack trace

2022-10-05 Thread Daniel Fuchs
On Wed, 5 Oct 2022 14:05:38 GMT, Alan Bateman wrote: > This is a test-only change. ThreadAPI.testGetStackTrace2 tests the stack > trace of a virtual thread that has started but has not executed it. The test > currently attempts to saturate all carrier threads before starting a target >

Re: RFR: 8293940: Some tests for virtual threads take too long

2022-09-30 Thread Daniel Fuchs
On Wed, 28 Sep 2022 08:07:25 GMT, Alan Bateman wrote: > This is a test only change to split the execution of some of the larger tests > for virtual threads and reduce the execution time of a few others. > > The tests StructuredTaskScopeTest, ThreadFockTest and > ThreadPerTaskExecutorTest

Re: RFR: 8294456: Fix misleading-indentation warnings in JDK

2022-09-29 Thread Daniel Fuchs
On Thu, 29 Sep 2022 13:44:40 GMT, Raffaello Giulietti wrote: >> src/java.base/share/native/libfdlibm/e_asin.c line 102: >> >>> 100: } else >>> 101: t = x*x; >>> 102: p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5); >> >> should we add an opening brace

Re: RFR: 8294456: Fix misleading-indentation warnings in JDK

2022-09-29 Thread Daniel Fuchs
On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti wrote: > This fixes misleading indentations, which allows enabling the (currently > disabled) `misleading-indentation` warning flag on two `.gmk` files. src/java.base/share/native/libfdlibm/e_asin.c line 102: > 100: } else >

Re: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2]

2022-09-28 Thread Daniel Fuchs
On Wed, 28 Sep 2022 14:45:54 GMT, Michael Ernst wrote: >> Michael Ernst has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains six commits: >> >> - Reinstate typos in Apache code that is copied into the JDK >> - Merge ../jdk-openjdk

Re: RFR: 8294377: Prepare to stop auto-inheriting documentation for subclasses of exceptions whose documentation is inherited [v2]

2022-09-28 Thread Daniel Fuchs
On Tue, 27 Sep 2022 12:14:23 GMT, Pavel Rappo wrote: >> This adds exception documentation to JDK methods that would otherwise lose >> that documentation once JDK-8287796 is integrated. While adding this >> exception documentation now does not change [^1] the JDK API Documentation, >> it will

Re: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2]

2022-09-28 Thread Daniel Fuchs
On Tue, 27 Sep 2022 23:12:43 GMT, Michael Ernst wrote: > Feel free to break up the pull request if that is what is needed to free it > from red tape. Only you can do that @mernst - PR: https://git.openjdk.org/jdk/pull/10029

Integrated: 8293819: sun/util/logging/PlatformLoggerTest.java failed with "RuntimeException: Retrieved backing PlatformLogger level null is not the expected CONFIG"

2022-09-16 Thread Daniel Fuchs
On Thu, 15 Sep 2022 11:29:40 GMT, Daniel Fuchs wrote: > The sun/util/logging/PlatformLoggerTest.java is missing a couple of > Reference::reachabilityFence calls to maintain loggers alive while the test > is running. It has been observed failing under stress. This pull request has

Re: RFR: 8293819: sun/util/logging/PlatformLoggerTest.java failed with "RuntimeException: Retrieved backing PlatformLogger level null is not the expected CONFIG"

2022-09-15 Thread Daniel Fuchs
On Thu, 15 Sep 2022 13:57:37 GMT, Jaikiran Pai wrote: >> The sun/util/logging/PlatformLoggerTest.java is missing a couple of >> Reference::reachabilityFence calls to maintain loggers alive while the test >> is running. It has been observed failing under stress. > >

RFR: 8293819: sun/util/logging/PlatformLoggerTest.java failed with "RuntimeException: Retrieved backing PlatformLogger level null is not the expected CONFIG"

2022-09-15 Thread Daniel Fuchs
The sun/util/logging/PlatformLoggerTest.java is missing a couple of Reference::reachabilityFence calls to maintain loggers alive while the test is running. It has been observed failing under stress. - Commit messages: - Update Copyright year - 8293819 Changes:

Re: RFR: 8292698: Improve performance of DataInputStream [v4]

2022-09-12 Thread Daniel Fuchs
On Mon, 29 Aug 2022 08:46:20 GMT, Сергей Цыпанов wrote: >> I found out that reading from `DataInputStream` wrapping >> `ByteArrayInputStream` (as well as `BufferedInputStream` or any >> `InputStream` relying on `byte[]`) can be significantly improved by >> accessing volatile `in` field only

Re: RFR: 8290367: Update default value and extend the scope of com.sun.jndi.ldap.object.trustSerialData system property [v2]

2022-09-12 Thread Daniel Fuchs
On Fri, 9 Sep 2022 16:55:44 GMT, Aleksei Efimov wrote: >> ### Summary of the change >> >> The LDAP Naming Service Provider implementation's default settings are >> changed to disallow deserialization and reconstruction of Java objects from >> different LDAP attributes (RFC 2713). Currently,

Re: RFR: 8290367: Update default value and extend the scope of com.sun.jndi.ldap.object.trustSerialData system property

2022-09-09 Thread Daniel Fuchs
On Fri, 9 Sep 2022 14:13:09 GMT, Alan Bateman wrote: >> ### Summary of the change >> >> The LDAP Naming Service Provider implementation's default settings are >> changed to disallow deserialization and reconstruction of Java objects from >> different LDAP attributes (RFC 2713). Currently,

Re: RFR: 8292240: CarrierThread.blocking not reset when spare not activated

2022-09-09 Thread Daniel Fuchs
On Thu, 11 Aug 2022 16:11:02 GMT, Alan Bateman wrote: > Some blocking operations that pin a virtual thread to its carrier will > compensate by activating a spare carrier (essentially managed blocker). This > is done by wrapping the operation in a Blocker begin/end. This code is not > correct

Re: RFR: 8279283 - BufferedInputStream should override transferTo [v10]

2022-09-09 Thread Daniel Fuchs
On Fri, 9 Sep 2022 06:45:04 GMT, Markus KARG wrote: >> test/jdk/java/io/BufferedInputStream/TransferTo.java line 170: >> >>> 168: if (mark) { >>> 169: in.mark(1); >>> 170: } >> >> This just tests transferTo with a mark set, it doesn't appear to check that

Re: RFR: 8279283 - BufferedInputStream should override transferTo [v7]

2022-09-06 Thread Daniel Fuchs
On Tue, 6 Sep 2022 17:01:09 GMT, Markus KARG wrote: >>> @AlanBateman Async close leaves BIS in an invalid state. The JavaDocs say ` >>> The behavior for the case where the input and/or output stream is >>> asynchronously closed, or the thread interrupted during the transfer, is >>> highly

Re: RFR: 8279283 - BufferedInputStream should override transferTo [v7]

2022-09-06 Thread Daniel Fuchs
On Tue, 6 Sep 2022 13:00:23 GMT, Markus KARG wrote: >> Rebased and fixed locking, using your proposed code now. >> >> @AlanBateman Async close leaves BIS in an invalid state. The JavaDocs say ` >> The behavior for the case where the inputand/or output stream is >> asynchronously closed, or

Re: RFR: 8279283 - BufferedInputStream should override transferTo [v7]

2022-09-06 Thread Daniel Fuchs
On Tue, 6 Sep 2022 11:26:18 GMT, Markus KARG wrote: >> It's a well known behavior that overriding the`read(...)` method is >> sufficient to implement subclass behavior. This will no longer be the case >> if `transferTo(...)` no longer calls `this.read(...)` as it used to. There >> are many

Re: RFR: 8279283 - BufferedInputStream should override transferTo [v7]

2022-09-06 Thread Daniel Fuchs
On Tue, 6 Sep 2022 07:55:55 GMT, Markus KARG wrote: >> test/lib/jdk/test/lib/hexdump/HexPrinter.java line 1194: >> >>> 1192: byteOffset += size; >>> 1193: return size; >>> 1194: } >> >> This is an indication that overriding `transferTo()` in >>

Re: RFR: 8279283 - BufferedInputStream should override transferTo [v7]

2022-09-05 Thread Daniel Fuchs
On Mon, 5 Sep 2022 18:05:04 GMT, Markus KARG wrote: >> Implementation of JDK-8279283 > > Markus KARG has updated the pull request incrementally with one additional > commit since the last revision: > > HexPrinter::transferTo test/lib/jdk/test/lib/hexdump/HexPrinter.java line 1194: > 1192:

Re: RFR: 8291651: CleanerTest.java fails with "Cleanable was cleaned" [v2]

2022-08-31 Thread Daniel Fuchs
On Tue, 30 Aug 2022 18:33:24 GMT, Roger Riggs wrote: >> CleanerTest is failing intermittently on Aarch64, with -Xcomp, and using a >> VirtualThread for the Cleaner in the test. >> The extensively relies on references processing and invokes GC on a very >> short cycle. >> The existing 10ms

Re: RFR: 8291651: CleanerTest.java fails with "Cleanable was cleaned"

2022-08-29 Thread Daniel Fuchs
On Fri, 26 Aug 2022 19:09:45 GMT, Roger Riggs wrote: > CleanerTest is failing intermittently on Aarch64, with -Xcomp, and using a > VirtualThread for the Cleaner in the test. > The extensively relies on references processing and invokes GC on a very > short cycle. > The existing 10ms delay

Re: RFR: 8065554: MatchResult should provide values of named-capturing groups

2022-08-24 Thread Daniel Fuchs
On Wed, 24 Aug 2022 16:12:52 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/java/util/regex/MatchResult.java line 274: >> >>> 272: * might be preferable for other reasons. >>> 273: * >>> 274: * @since 20 >> >> Should the method declare that it throws

Re: RFR: 8065554: MatchResult should provide values of named-capturing groups

2022-08-24 Thread Daniel Fuchs
On Wed, 24 Aug 2022 15:48:38 GMT, Raffaello Giulietti wrote: > Add support for named groups to java.util.regex.MatchResult src/java.base/share/classes/java/util/regex/MatchResult.java line 274: > 272: * might be preferable for other reasons. > 273: * > 274: * @since 20

Re: RFR: 8292698: Improve performance of DataInputStream

2022-08-24 Thread Daniel Fuchs
On Wed, 24 Aug 2022 06:17:19 GMT, Alan Bateman wrote: > I can't imagine a subclass of DataInputStream setting 'in' to null. If it > handles async close then it's possible that it replaces it with an input > stream where read throws IOException unconditionally. This is why the > original patch

Re: RFR: 8292698: Improve performance of DataInputStream

2022-08-23 Thread Daniel Fuchs
On Tue, 23 Aug 2022 14:31:26 GMT, Сергей Цыпанов wrote: > > I agree that caution is warranted > > But assuming I've reverted the changes that are dubious, how could there be > bugs caused by replacement of multiple reads with a single one? I was sure > that such replacement improves thread

Re: RFR: 8292698: Improve performance of DataInputStream

2022-08-23 Thread Daniel Fuchs
On Sun, 21 Aug 2022 07:21:08 GMT, Alan Bateman wrote: > 'in' is a protected field so it requires thinking about subclasses that might > change 'in', say when the input stream is asynchronously closed. > BufferedInputStream is an example of a FilterInputStream that sets 'in' to > null when

Re: RFR: 8290036: Define and specify Runtime shutdown sequence [v6]

2022-08-11 Thread Daniel Fuchs
On Thu, 11 Aug 2022 04:00:39 GMT, Stuart Marks wrote: >> The concept of the shutdown sequence needs to be specified more clearly. >> This PR adds text for this into the class specification of >> `java.lang.Runtime`. Also includes adjustments to related areas in >> `addShutdownHook`, `halt`,

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v7]

2022-08-03 Thread Daniel Fuchs
On Wed, 20 Jul 2022 23:41:04 GMT, Brian Burkhalter wrote: >> Modify native multi-byte read-write code used by the `java.io` classes to >> limit the size of the allocated native buffer thereby decreasing off-heap >> memory footprint and increasing throughput. > > Brian Burkhalter has updated

Re: RFR: 8290300: Use standard String-joining tools where applicable [v5]

2022-08-03 Thread Daniel Fuchs
On Mon, 18 Jul 2022 18:40:51 GMT, Сергей Цыпанов wrote: >> Simplify code with `String.join()` > > Сергей Цыпанов has updated the pull request incrementally with one additional > commit since the last revision: > > 8290300: Revert erroneous changes Changes to HttpURLConnection look good to

Re: RFR: 8290178: failure_handler: run netstat without name lookups

2022-07-13 Thread Daniel Fuchs
On Tue, 12 Jul 2022 13:16:12 GMT, Daniel Jeliński wrote: > `netstat -av` in Mac OS X failure handler is frequently running into the 20 > second timeout, leaving us with no socket information. This PR proposes > running `netstat -anv` along with the existing `netstat -av`, so that we have > at

Re: RFR: 8289768: Clean up unused code [v2]

2022-07-06 Thread Daniel Fuchs
On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeliński wrote: >> This patch removes many unused variables and one unused label reported by >> the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list >> of disabled warnings

Re: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]

2022-07-01 Thread Daniel Fuchs
On Fri, 1 Jul 2022 14:26:24 GMT, Roger Riggs wrote: >> Thanks @XueleiFan, that's fine by me! > > When using Reference/ReferenceQueue there is no Cleaner, only normal > reference processing (via GC). I have tests that use Reference/ReferenceQueue to check that an object that uses a Cleaner has

Re: [External] : Re: Executable.hasRealParameterData() and Parameter.isNamePresent() don't work as expected

2022-07-01 Thread Daniel Fuchs
Hi Sergey, On 01/07/2022 10:22, Сергей Цыпанов wrote: And what about JavaDoc of Parameter.isNamePresent()? Should we keep it as is, I mean pointing out to 'MethodParameters' attribute of a class file? AFAIU that's accurate, but it would probably deserve at least a link to the JLS? best

Re: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]

2022-07-01 Thread Daniel Fuchs
On Fri, 1 Jul 2022 08:26:30 GMT, Xue-Lei Andrew Fan wrote: >> Maybe not for this PR - but it could be useful to have a version of ForceGC >> that takes as parameter a `ReferenceQueue` and a `Reference`. That >> would be more efficient than creating a new object and waiting for a >> different

Re: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]

2022-07-01 Thread Daniel Fuchs
On Thu, 30 Jun 2022 20:36:35 GMT, Roger Riggs wrote: >> I'm not sure if all unused object will be collected in one GC call always. >> The gc() specification says "When control returns from the method call, the >> Java Virtual Machine has made a best effort to reclaim space from all unused >>

Re: Executable.hasRealParameterData() and Parameter.isNamePresent() don't work as expected

2022-06-29 Thread Daniel Fuchs
Hi Sergey, I believe you need to compile with `-parameters` https://docs.oracle.com/en/java/javase/18/docs/specs/man/javac.html best regards, -- daniel On 29/06/2022 07:54, Сергей Цыпанов wrote: This question was asked originally here:

Re: RFR: 8288895: LdapContext doesn't honor set referrals limit [v3]

2022-06-29 Thread Daniel Fuchs
On Tue, 28 Jun 2022 14:22:48 GMT, rmartinc wrote: >> Fixes [JDK-8288895](https://bugs.openjdk.org/browse/JDK-8288895). >> >> Any `LimitExceededException` now quits the referral loop. >> >> Added class `ReferralLimitSearchTest`. It is a simple jtreg test which >> checks that

Integrated: JDK-8288746: HttpClient resources could be reclaimed more eagerly

2022-06-27 Thread Daniel Fuchs
On Mon, 20 Jun 2022 14:09:27 GMT, Daniel Fuchs wrote: > Hi, > > Please find here a patch that should help the HttpClient's SelectorManager > thread to terminate more timely, allowing the resources consumed by the > client to be released earlier. > > The idea is to use

Re: RFR: 8288895: LdapContext doesn't honor set referrals limit

2022-06-27 Thread Daniel Fuchs
On Thu, 23 Jun 2022 08:20:31 GMT, rmartinc wrote: > Fixes [JDK-8288895](https://bugs.openjdk.org/browse/JDK-8288895). > > Any `LimitExceededException` now quits the referral loop. > > Added class `ReferralLimitSearchTest`. It is a simple jtreg test which checks > that

Re: [jdk19] RFR: 8288596: Random:from() adapter does not delegate to supplied generator in all cases

2022-06-27 Thread Daniel Fuchs
On Fri, 17 Jun 2022 16:44:30 GMT, Raffaello Giulietti wrote: > Extend delegation by instance returned by Random.from() to all methods > exposed by RandomGenerator. just a stylistic comment in passing: it's a bit strange to see half of the methods call `this.generator` and the other half

Re: RFR: 8282036: [Test]: Update java/util/zip/ZipFile/DeleteTempJar.java to stop HttpServer cleanly in case of exceptions [v3]

2022-06-27 Thread Daniel Fuchs
On Mon, 27 Jun 2022 11:52:37 GMT, Thejasvi Voniadka wrote: >> This is a simple change to add some protective code to >> java/util/zip/ZipFile/DeleteTempJar.java so that the clean-up is more >> complete in the event of encountering an any exceptions while running. In >> the present state, the

Re: RFR: JDK-8288746: HttpClient resources could be reclaimed more eagerly

2022-06-27 Thread Daniel Fuchs
On Sun, 26 Jun 2022 06:08:07 GMT, Jaikiran Pai wrote: >> Hi, >> >> Please find here a patch that should help the HttpClient's SelectorManager >> thread to terminate more timely, allowing the resources consumed by the >> client to be released earlier. >> >> The idea is to use a Cleaner

Re: RFR: JDK-8288746: HttpClient resources could be reclaimed more eagerly

2022-06-27 Thread Daniel Fuchs
On Mon, 20 Jun 2022 14:09:27 GMT, Daniel Fuchs wrote: > Hi, > > Please find here a patch that should help the HttpClient's SelectorManager > thread to terminate more timely, allowing the resources consumed by the > client to be released earlier. > > The idea is to use

Re: RFR: JDK-8288746: HttpClient resources could be reclaimed more eagerly

2022-06-21 Thread Daniel Fuchs
On Tue, 21 Jun 2022 17:31:59 GMT, Brent Christian wrote: >> Hi, >> >> Please find here a patch that should help the HttpClient's SelectorManager >> thread to terminate more timely, allowing the resources consumed by the >> client to be released earlier. >> >> The idea is to use a Cleaner

Re: RFR: JDK-8288746: HttpClient resources could be reclaimed more eagerly

2022-06-21 Thread Daniel Fuchs
On Mon, 20 Jun 2022 18:28:36 GMT, Сергей Цыпанов wrote: > Shouldn't we use `Reference.refersTo()` instead of `Reference.get() == smth` > in lines 428 and 501? Hi Sergey, we could, and I'll do it for consistency. Though in those two cases it doesn't really matter since the facade referent is

RFR: JDK-8288746: HttpClient resources could be reclaimed more eagerly

2022-06-20 Thread Daniel Fuchs
Hi, Please find here a patch that should help the HttpClient's SelectorManager thread to terminate more timely, allowing the resources consumed by the client to be released earlier. The idea is to use a Cleaner registered with the HttpClientFacade to wakeup the Selector when the facade is

<    1   2   3