Integrated: 8288744: Remove tools/jlink/plugins/CompressorPluginTest.java from problemlist

On Tue, 21 Jun 2022 06:40:36 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to remove the > `CompressorPluginTest` from the problemlist? > > This test was problem listed since it had intermittently failed with odd > exception in the past

Re: RFR: 8288744: Remove tools/jlink/plugins/CompressorPluginTest.java from problemlist

On Tue, 21 Jun 2022 06:40:36 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to remove the > `CompressorPluginTest` from the problemlist? > > This test was problem listed since it had intermittently failed with odd > exception in the past

Integrated: 8288529: broken link in java.xml

On Tue, 21 Jun 2022 16:52:52 GMT, Joe Wang wrote: > Some of the links cause redirection, iso.org in particular took 1-2 seconds, > that looks like was longer than the wait time of the doccheck and docs link > checker. Changed it to the current homepage to avoid redirection. Also > changed

Re: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in Integer and Long

On Fri, 10 Jun 2022 00:05:53 GMT, Sandhya Viswanathan wrote: >> I have added a benchmark for the intrinsic. The result is as follows, thanks >> a lot: >> >> Before After >> Benchmark (size) Mode Cnt Score

Re: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in Integer and Long [v3]

> Hi, > > This patch implements intrinsics for `Integer/Long::compareUnsigned` using > the same approach as the JVM does for long and floating-point comparisons. > This allows efficient and reliable usage of unsigned comparison in Java, > which is a basic operation and is important for range

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v33]

> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains

Integrated: Merge jdk19

On Tue, 21 Jun 2022 21:47:17 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 2bf5c9a6 Author:Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/2bf5c9a6877b51377a535c6021a9e38549c89029 Stats: 363 lines

Re: RFR: Merge jdk19 [v2]

> Forwardport JDK 19 -> JDK 20 Jesper Wilhelmsson 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 106 additional commits since the last revision: -

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

On Fri, 29 Apr 2022 18:49:26 GMT, Mandy Chung wrote: >> Joe Darcy 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 26 additional commits >>

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v32]

> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains

RFR: Merge jdk19

Forwardport JDK 19 -> JDK 20 - Commit messages: - Merge - 8287971: Throw exception for missing values in .jpackage.xml - 8288761: SegmentAllocator:allocate(long bytesSize) not throwing IAEx when bytesSize < 0 - 8288754: GCC 12 fails to build zReferenceProcessor.cpp - 8286103:

Re: RFR: 8288589: Files.readString ignores encoding errors for UTF-16 [v3]

On Tue, 21 Jun 2022 20:59:40 GMT, Andrey Turbanov wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Adding a test case in ReadWriteString.java > > test/jdk/java/lang/String/NoReplTest.java line 47: > >> 45:

Re: RFR: 8288589: Files.readString ignores encoding errors for UTF-16 [v5]

> This is a regression caused by the fix to > [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the > method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode > based on the comment "should not happen". Possibly this refers to the > `String(byte[], int,

Re: RFR: 8288589: Files.readString ignores encoding errors for UTF-16 [v4]

> This is a regression caused by the fix to > [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the > method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode > based on the comment "should not happen". Possibly this refers to the > `String(byte[], int,

Integrated: 8287971: Throw exception for missing values in .jpackage.xml

On Mon, 13 Jun 2022 17:01:48 GMT, Alexander Matveev wrote: > - Error will be thrown if app image is generated with another JDK version or > has malformed .jpackage.xml. > - Re-fixed as Alexey suggested in >

Integrated: 8288761: SegmentAllocator:allocate(long bytesSize) not throwing IAEx when bytesSize < 0

On Mon, 20 Jun 2022 21:22:42 GMT, Maurizio Cimadamore wrote: > The various SegmentAllocator subclasses do not check for the constraints > mentioned in the javadoc. > This patch pulls the checks into a common routine in the Utils class, and > then call that check routine from all the

Re: RFR: 8288589: Files.readString ignores encoding errors for UTF-16 [v3]

On Tue, 21 Jun 2022 18:12:23 GMT, Naoto Sato wrote: >> This is a regression caused by the fix to >> [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed >> the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE >> mode based on the comment "should not

Re: RFR: 8288589: Files.readString ignores encoding errors for UTF-16 [v2]

On Tue, 21 Jun 2022 08:55:09 GMT, Alan Bateman wrote: > My comment was mostly asking if we need to add more tests for > Files.writeString. I would have expected a test for that method to fail with > this bug. Maybe we need to create a new issue to expand the tests for this > method. Added a

Re: RFR: 8288529: broken link in java.xml

On Tue, 21 Jun 2022 16:52:52 GMT, Joe Wang wrote: > Some of the links cause redirection, iso.org in particular took 1-2 seconds, > that looks like was longer than the wait time of the doccheck and docs link > checker. Changed it to the current homepage to avoid redirection. Also > changed

Re: RFR: 8288589: Files.readString ignores encoding errors for UTF-16 [v3]

> This is a regression caused by the fix to > [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed the > method `String.decodeWithDecoder()` was only invoked with cs.REPLACE mode > based on the comment "should not happen". Possibly this refers to the > `String(byte[], int,

Re: RFR: 8287868: Localized names update in COMPAT locale provider [v3]

On Mon, 13 Jun 2022 22:58:43 GMT, Naoto Sato wrote: >> As the name suggests, `COMPAT` locale provider keeps compatibility with >> JDK8's locale data (before CLDR). This is useful for legacy applications, >> but some of its data got obsolete for later locale data updates, such as the >>

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v31]

> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains

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

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

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 a Cleaner registered

Re: RFR: 8287868: Localized names update in COMPAT locale provider [v3]

On Mon, 13 Jun 2022 22:58:43 GMT, Naoto Sato wrote: >> As the name suggests, `COMPAT` locale provider keeps compatibility with >> JDK8's locale data (before CLDR). This is useful for legacy applications, >> but some of its data got obsolete for later locale data updates, such as the >>

Re: RFR: 8288529: broken link in java.xml

On Tue, 21 Jun 2022 16:52:52 GMT, Joe Wang wrote: > Some of the links cause redirection, iso.org in particular took 1-2 seconds, > that looks like was longer than the wait time of the doccheck and docs link > checker. Changed it to the current homepage to avoid redirection. Also > changed

Re: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time

On Tue, 21 Jun 2022 09:35:34 GMT, Attila Szegedi wrote: >> This behaves slightly different from the old initialization; the concurrent >> hash map blocks when the mapping function is run, just in case if >> non-blocking instantiation is what we want. If that's not a problem, I would >> prefer

Re: RFR: 8288529: broken link in java.xml

On Tue, 21 Jun 2022 16:52:52 GMT, Joe Wang wrote: > Some of the links cause redirection, iso.org in particular took 1-2 seconds, > that looks like was longer than the wait time of the doccheck and docs link > checker. Changed it to the current homepage to avoid redirection. Also > changed

Re: RFR: 8287868: Localized names update in COMPAT locale provider

Ping. Naoto On 6/10/22 2:05 PM, Naoto Sato wrote: As the name suggests, `COMPAT` locale provider keeps compatibility with JDK8's locale data (before CLDR). This is useful for legacy applications, but some of its data got obsolete for later locale data updates, such as the country name

RFR: 8288529: broken link in java.xml

Some of the links cause redirection, iso.org in particular took 1-2 seconds, that looks like was longer than the wait time of the doccheck and docs link checker. Changed it to the current homepage to avoid redirection. Also changed other links within this package. I'm limiting the change to

Re: RFR: 8288840: StructureViolationException should not link to fork method

On Tue, 21 Jun 2022 11:20:49 GMT, Alan Bateman wrote: > StructureViolationException has a `@see` link to a fork method that does not > throw this exception. The link should be removed for JDK 19. We'll add the > link back once the JEP for Extent-Local Variables is integrated. Marked as

Re: RFR: 8288840: StructureViolationException should not link to fork method

On Tue, 21 Jun 2022 11:20:49 GMT, Alan Bateman wrote: > StructureViolationException has a `@see` link to a fork method that does not > throw this exception. The link should be removed for JDK 19. We'll add the > link back once the JEP for Extent-Local Variables is integrated. Marked as

Re: RFR: 8288761: SegmentAllocator:allocate(long bytesSize) not throwing IAEx when bytesSize < 0

On Mon, 20 Jun 2022 21:22:42 GMT, Maurizio Cimadamore wrote: > The various SegmentAllocator subclasses do not check for the constraints > mentioned in the javadoc. > This patch pulls the checks into a common routine in the Utils class, and > then call that check routine from all the

Re: RFR: 8288697: Clarify lifecycle of buffer segments and loader lookup

On Tue, 21 Jun 2022 16:10:24 GMT, Alan Bateman wrote: >> This is a dependent PR containing a cleanup of the so called *heap >> sessions*. Heap sessions are used in two cases: >> >> * when a buffer segment is created, to keep the original buffer instance >> reachable >> * when a loader symbol

Re: RFR: 8288697: Clarify lifecycle of buffer segments and loader lookup

On Fri, 17 Jun 2022 21:39:16 GMT, Maurizio Cimadamore wrote: > This is a dependent PR containing a cleanup of the so called *heap sessions*. > Heap sessions are used in two cases: > > * when a buffer segment is created, to keep the original buffer instance > reachable > * when a loader

Re: Bug JDK-8176553

Hi Ricardo, Thank you for discovering and reproducing the issue - it looks like JDK-8176553 was incomplete in solving how referrals are limited. At first glance the attached patch (fix + test) looks like a good change to have - I think it is PR worthy :) I've logged a bug for your change -

Re: RFR: 8287982: Concurrent implicit attach from native threads crashes VM

On Thu, 16 Jun 2022 13:34:18 GMT, Alan Bateman wrote: > If several native threads attach to the VM at around the same time, and > before any threads get an automatically generated name are created, then the > VM may crash attempting to access the thread status. The issue exists for > native

Re: Handling of USR2 signal in JVM on Linux

On Fri, Jun 17, 2022 at 1:05 AM Thomas Stüfe wrote: >> >> >> > > >> > > I see your point. I dislike crashes, especially ones they can be >> > > reliably triggered from outside. You never can be sure about the >> > > security implications either. >> > > >> > > If you dislike ignoring the signal,

RFR: 8288840: StructureViolationException should not link to fork method

StructureViolationException has a `@see` link to a fork method that does not throw this exception. The link should be removed for JDK 19. We'll add the link back once the JEP for Extent-Local Variables is integrated. - Commit messages: - Initial commit Changes:

Re: DirectBufferAllocTest fails after replacement of Thread.sleep() with Thread.onSpinWait()

> The takeaway from this exercise is that loops with sleeps can't always be > replaced by loops that busy-wait. > Functionally the logic is the same, but you can't just ignore the concurrency > aspects. Thanks for explanation! > Which indicates yielding is having a similar effect to sleeping -

[JMH results for IndexedLinkedList]

Hi, Data structure: IndexedLinkedList Benchmark: IndexedLinkedListBenchmark Benchmark output: https://github.com/coderodde/indexedLinkedList/#benchmark-output >From the benchmark output,

RFR: 8288838: jpackage: file association additional arguments

jpackage implementation of file association on Windows currently passes a selected filename as an only argument to associated executable. It is proposed to introduce additional option in file association property file to allow optionally support additional arguments using `%*` batch wildcard.

Re: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time

On Mon, 20 Jun 2022 15:01:55 GMT, liach wrote: >> src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line >> 319: >> >>> 317: store = prev; >>> 318: } >>> 319: } >> >> You could do better here and use `computeIfAbsent` with `createStore`

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

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

Re: RFR: 8288589: Files.readString ignores encoding errors for UTF-16 [v2]

On Sat, 18 Jun 2022 00:31:06 GMT, Naoto Sato wrote: >> This is a regression caused by the fix to >> [JDK-8286287](https://bugs.openjdk.org/browse/JDK-8286287), which assumed >> the method `String.decodeWithDecoder()` was only invoked with cs.REPLACE >> mode based on the comment "should not

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3]

On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf wrote: >> Please review this change to the cgroup v1 subsystem which makes it more >> resilient on some of the stranger systems. Unfortunately, I wasn't able to >> re-create a similar system as the reporter. The idea of using the longest >>

Integrated: 8288628: Unnecessary Hashtable usage in ConditionalSpecialCasing

On Wed, 15 Jun 2022 19:49:52 GMT, Andrey Turbanov wrote: > If a thread-safe implementation is not needed, it is recommended to use > HashMap in place of Hashtable. > `ConditionalSpecialCasing.entryTable` is read-only Map which is modified only > in `static` block. It means we can safely

Re: RFR: 8287982: Concurrent implicit attach from native threads crashes VM

On Tue, 21 Jun 2022 07:09:50 GMT, David Holmes wrote: > And I confirmed that the VM code will correctly handle a null name from the > current Java thread. Thanks, I checked that one. One thing that I'm wondering for the test is whether to move it to test/hotspot/jtreg/runtime/jni/ so it

Re: RFR: 8287982: Concurrent implicit attach from native threads crashes VM

On Thu, 16 Jun 2022 13:34:18 GMT, Alan Bateman wrote: > If several native threads attach to the VM at around the same time, and > before any threads get an automatically generated name are created, then the > VM may crash attempting to access the thread status. The issue exists for > native

Re: DirectBufferAllocTest fails after replacement of Thread.sleep() with Thread.onSpinWait()

On 20/06/2022 22:58, David Holmes wrote: Thread.onSpinWait _is_ busy-waiting, but it may (depending on architecture) actually execute a more (power) efficient form of busy-wait. The takeaway from this exercise is that loops with sleeps can't always be replaced by loops that busy-wait.

RFR: 8288744: Remove tools/jlink/plugins/CompressorPluginTest.java from problemlist

Can I please get a review for this change which proposes to remove the `CompressorPluginTest` from the problemlist? This test was problem listed since it had intermittently failed with odd exception in the past (https://bugs.openjdk.org/browse/JDK-8247407). Over the past several months I have

Re: RFR: 8288744: Remove tools/jlink/plugins/CompressorPluginTest.java from problemlist

On Tue, 21 Jun 2022 06:40:36 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to remove the > `CompressorPluginTest` from the problemlist? > > This test was problem listed since it had intermittently failed with odd > exception in the past

RFR: 8287982: Concurrent implicit attach from native threads crashes VM

If several native threads attach to the VM at around the same time, and before any threads get an automatically generated name are created, then the VM may crash attempting to access the thread status. The issue exists for native threads that attach explicitly with JNI AttachCurrentThread