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 a

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 (https://bugs.openj

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 withou

Re:Re: jvm crash on memmove_ssse3_back

David: Thanks!- 回复邮件 -发信人:David Holmes 收信人:"Yan Gang" ,"core-libs-dev" 时  间:2022年06月21日 13时11分43秒主  题:Re: jvm crash on memmove_ssse3_backHi,On 21/06/2022 2:35 pm, Yan Gang wrote:> hi all:>  I have jvm crash issue

Re: jvm crash on memmove_ssse3_back

Hi, On 21/06/2022 2:35 pm, Yan Gang wrote: hi all:  I have jvm crash issue. not get core,only hs_err_pid6443.log. These mailing lists are not for general bug reports but to discuss development of OpenJDK. Your hs_err file states: # The crash happened outside the Java Virtual Machine in na

Integrated: 8287672: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run

On Wed, 1 Jun 2022 15:41:57 GMT, Rob McKenna wrote: > Test change to silently pass if the test environment encounters a > NoRouteToHostException. These are intermittent at the moment but I will > attempt to find an alternative to the use of example.com in some follow up > work. This pull requ

Re: RFR: 8287672: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run [v2]

> Test change to silently pass if the test environment encounters a > NoRouteToHostException. These are intermittent at the moment but I will > attempt to find an alternative to the use of example.com in some follow up > work. Rob McKenna has updated the pull request with a new target base due

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

On 21/06/2022 12:49 am, Сергей Цыпанов wrote: Do you get the OOME using Thread.yield() or just a busy-wait? I reproduce it with busy-wait involving Thread.onSpinWait() and only when the test is run with -XX:MaxDirectMemorySize=128m -XX:-ExplicitGCInvokesConcurrent If I either drop mentioned

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

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 `allocate` implementations. - Commit messages: - Add comments in al

Integrated: Merge jdk19

On Mon, 20 Jun 2022 18:20:21 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 7039c661 Author:Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/7039c6616ad1b67320f08e7ea4763e8ff4977430 Stats: 752 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 96 additional commits since the last revision: - Me

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 wit

RFR: Merge jdk19

Forwardport JDK 19 -> JDK 20 - Commit messages: - Merge - 8288527: broken link in java.base/java/util/zip/package-summary.html - 8288741: JFR: Change package name of snippet files - 8288663: JFR: Disabling the JfrThreadSampler commits only a partially disabled state - 8287800: J

Re: Inconsistencies in the return value (type) of string functions toLower() and toUpper().

What you are suggesting is what we call "specifying the implementation", which is generally not a very good idea. The specification for these methods says "returns a String following properties>".  That's a good specification!  It says what you can expect from the result.  It says nothing about

Integrated: 8288527: broken link in java.base/java/util/zip/package-summary.html

On Fri, 17 Jun 2022 16:33:16 GMT, Lance Andersen wrote: > Hi all, > > Please review this patch for JDK 19 to address a broken link due to PKWare > moving the location for APPNOTE.txt > > Best, > Lance This pull request has now been integrated. Changeset: 453e8beb Author:Lance Andersen U

Re: Inconsistencies in the return value (type) of string functions toLower() and toUpper().

1. Like I already said “==” should be avoided in the first place, and the issue(s) described, 100 % are the bad programming behaviors. No debate there. 2. And, my point is not to return a new object or literal (I a am not trying to drive this one specific behavior one way or another)

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

On Mon, 20 Jun 2022 09:11:31 GMT, Attila Szegedi wrote: >> Instead of separate ConcurrentHashMap.get call, we can use result of >> previous putIfAbsent call. > > src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line > 319: > >> 317: store = prev; >> 318:

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

> Do you get the OOME using Thread.yield() or just a busy-wait? I reproduce it with busy-wait involving Thread.onSpinWait() and only when the test is run with -XX:MaxDirectMemorySize=128m -XX:-ExplicitGCInvokesConcurrent If I either drop mentioned VM options or use Thread.sleep() OOME will nev

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

> Do you get the OOME using Thread.yield() or just a busy-wait? I reproduce it with busy-wait involving Thread.onSpinWait() and only when the test is run with -XX:MaxDirectMemorySize=128m -XX:-ExplicitGCInvokesConcurrent If I either drop mentioned VM options or use Thread.sleep() OOME will never

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

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 bein

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

On 20/06/2022 7:43 pm, Сергей Цыпанов wrote: Hello, while playing with Thread.onSpinWait() in busy-wait loops I've replaced Thread.sleep() with preferable (at least as it appears from the JavaDoc) Thread.onSpinWait() in java.nio.Bits. Immediately after that DirectBufferAllocTest started to fa

Integrated: 8288011: StringConcatFactory: Split application of stringifiers

On Wed, 8 Jun 2022 10:20:37 GMT, Claes Redestad wrote: > To take optimal advantage of the pre-existing optimization for repeated > filters we could split the application of different types of stringifiers. > > The resulting difference in order of evaluation is not observable by > conventional

Re: RFR: 8288011: StringConcatFactory: Split application of stringifiers [v2]

On Thu, 9 Jun 2022 16:04:43 GMT, Claes Redestad wrote: >> To take optimal advantage of the pre-existing optimization for repeated >> filters we could split the application of different types of stringifiers. >> >> The resulting difference in order of evaluation is not observable by >> conventi

Re: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64

On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai wrote: > Can I please get a review of this change to the build system which now makes > bundled zlib as the default for macos aarch64 systems? > > We have been running into various intermittent failures on macos aarch64 > systems for several mont

RFR: 8288732: Reduce runtime of java.util.concurrent microbenchmarks

- Refactor so that various baseline micros are not run repeatedly with different parameter values that does not affect the baseline - Tune iteration times, counts, forks.. Reduces runtime of java.util.concurrent micros from an estimated 14h43m to 1h21m - Commit messages: - Copyrigh

Integrated: 8288667: Reduce runtime of java.text microbenchmarks

On Fri, 17 Jun 2022 12:59:17 GMT, Claes Redestad wrote: > - Refactor micro using a range of parameters to a simpler benchmark that > tests different values in one pass > - Reduce iterations and their runtimes, but add forks (important to be able > to detect run-to-run variation anomalies) > >

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

On Sat, 18 Jun 2022 10:43:08 GMT, Andrey Turbanov wrote: > Instead of separate ConcurrentHashMap.get call, we can use result of previous > putIfAbsent call. src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line 319: > 317: store = prev; > 318:

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

Hello, while playing with Thread.onSpinWait() in busy-wait loops I've replaced Thread.sleep() with preferable (at least as it appears from the JavaDoc) Thread.onSpinWait() in java.nio.Bits. Immediately after that DirectBufferAllocTest started to fail with OOME. This is surprising, as the chang

Re: RFR: 8288667: Reduce runtime of java.text microbenchmarks [v2]

On Sun, 19 Jun 2022 00:27:27 GMT, David Schlosnagle wrote: >> Claes Redestad has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Add OperationsPerInvocation > > test/micro/org/openjdk/bench/java/text/DefFormatterBench.java line 65: > >> 63:

Re: RFR: 8288667: Reduce runtime of java.text microbenchmarks [v2]

> - Refactor micro using a range of parameters to a simpler benchmark that > tests different values in one pass > - Reduce iterations and their runtimes, but add forks (important to be able > to detect run-to-run variation anomalies) > > Just one micro modified in this package, but reduces total

Integrated: 8288485: jni/nullCaller/NullCallerTest.java failing (ppc64)

On Wed, 15 Jun 2022 13:25:21 GMT, Martin Doerr wrote: > I'd like to revert to "" functions like it was before > [JDK-8281001](https://bugs.openjdk.org/browse/JDK-8281001), except that I'm > using stderr in order to preserve the new behavior. Also see JBS issue. This pull request has now been i

Re: RFR: 8288485: jni/nullCaller/NullCallerTest.java failing (ppc64)

On Wed, 15 Jun 2022 13:25:21 GMT, Martin Doerr wrote: > I'd like to revert to "" functions like it was before > [JDK-8281001](https://bugs.openjdk.org/browse/JDK-8281001), except that I'm > using stderr in order to preserve the new behavior. Also see JBS issue. Thanks for the reviews! I've add

Re: RFR: 8288485: jni/nullCaller/NullCallerTest.java failing (ppc64)

On Wed, 15 Jun 2022 13:25:21 GMT, Martin Doerr wrote: > I'd like to revert to "" functions like it was before > [JDK-8281001](https://bugs.openjdk.org/browse/JDK-8281001), except that I'm > using stderr in order to preserve the new behavior. Also see JBS issue. Marked as reviewed by parttimen.

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

Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. - Commit messages: - [PATCH] Avoid redundant ConcurrentHashMap.get call in java.time Changes: https://git.openjdk.org/jdk/pull/9208/files Webrev: https://webrevs.openjdk.org/?repo=jdk&p

Re: RFR: 8278863: Add method ClassDesc::ofInternalName [v3]

> The symbolic constants API (`java.lang.constant`) was designed, in part, to > provide bytecode parsing and generation APIs with a validated, common, > symbolic form for constants in Java class files. > > There is an easy way to create a `ClassDesc` from a binary name > (`ClassDesc::of`) or a