RFR: 8282239 [testbug, AIX] ProcessBuilder/Basic.java fails with incorrect LIBPATH

This test had two failing sections on AIX related to an incorrect expected value for LIBPATH. The two (previously failing) test sections are below. - Test Runtime.exec(...envp...) with envstrings with initial `=' - Test Runtime.exec(...envp...) with envstrings containing NULs This PR modifies

Re: RFR: 8282239 [testbug, AIX] ProcessBuilder/Basic.java fails with incorrect LIBPATH [v2]

> This test had two failing sections on AIX related to an incorrect expected > value for LIBPATH. The two (previously failing) test sections are below. > > - Test Runtime.exec(...envp...) with envstrings with initial `=' > - Test Runtime.exec(...envp...) with envstrings containing NULs > >

Re: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v2]

On Tue, 22 Feb 2022 17:20:25 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following >> change was

Re: RFR: 8279598: Provide adapter from RandomGenerator to Random [v6]

On Sun, 20 Feb 2022 06:39:26 GMT, liach wrote: >> Yasser Bazzi has updated the pull request incrementally with one additional >> commit since the last revision: >> >> remove missed whitespace > > src/java.base/share/classes/java/util/Random.java line 95: > >> 93: private static class

Re: RFR: 8282239 [testbug, AIX] ProcessBuilder/Basic.java fails with incorrect LIBPATH [v2]

On Tue, 22 Feb 2022 22:52:58 GMT, Roger Riggs wrote: > fyi, the noreg-* labels apply to the bug report, not the PR. (and yes, they > are informative when reviewing). Thanks for pointing that out. I thought I may have been reading some old documentation. > One of

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

> 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: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v2]

On Tue, 22 Feb 2022 17:31:14 GMT, Naoto Sato wrote: >> Jaikiran Pai has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - implement review comments >> - copyright years > > test/jdk/java/util/Properties/PropertiesStoreTest.java line 50: >

Re: RFR: 8282239 [testbug, AIX] ProcessBuilder/Basic.java fails with incorrect LIBPATH [v2]

On Tue, 22 Feb 2022 22:04:38 GMT, Tyler Steele wrote: >> This test had two failing sections on AIX related to an incorrect expected >> value for LIBPATH. The two (previously failing) test sections are below. >> >> - Test Runtime.exec(...envp...) with envstrings with initial `=' >> - Test

Re: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale

On Mon, 21 Feb 2022 14:09:50 GMT, Jaikiran Pai wrote: > Can I please get a review of this test only change which fixes the issue > noted in https://bugs.openjdk.java.net/browse/JDK-8282023? > > As noted in that JBS issue these tests fail when the default locale under > which those tests are

Re: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v2]

> Can I please get a review of this test only change which fixes the issue > noted in https://bugs.openjdk.java.net/browse/JDK-8282023? > > As noted in that JBS issue these tests fail when the default locale under > which those tests are run isn't `en_US`. Both these tests were introduced as >

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

> 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: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v8]

> Hi all, > > Please review the attached patch to address > > - That JarFile::getInputStream did not check for a null ZipEntry passed as a > parameter > - Have Zip/JarFile::getInputStream throw a ZipException in the event that an > unexpected exception occurs > > Mach5 tiers1-3 runs are clean

Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v5]

> **Background:** > > In the Java Language, Enums can be tested for equality, so the constants in > an Enum type must be unique. Javac compiles an enum declaration like this: > > > public enum Day { SUNDAY, MONDAY ... } > > > to > > > public class Day extends java.lang.Enum { >

Re: RFR: 8279598: Provide adapter from RandomGenerator to Random [v8]

> Hi, could i get a review on this implementation proposed by Stuart Marks, i > decided to use the > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html > interface to create the default method `asRandom()` that wraps around the > newer algorithms

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

> 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: 8279508: Auto-vectorize Math.round API [v6]

On Thu, 17 Feb 2022 17:43:43 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar >> IR nodes for above intrinsics. >> - Test creation using new IR testing

Re: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream [v2]

On Thu, 17 Feb 2022 16:02:42 GMT, Volker Simonis wrote: >> Currently, `InflaterInputStream::read()` first does a native call to the >> underlying zlib `inflate()` function and only afterwards checks if the >> inflater requires input (i.e. `Inflater::needsInput()`) or has finished >> inflating

Replace simple iterations of Map.entrySet with Map.forEach calls

Hello, In the patch for 8281631 , xenoamess intentionally avoided repeatedly calling Map::size, for it may not be constant-timed due to being concurrent. This alerted me that the for

Re: RFR: 8279598: Provide adapter from RandomGenerator to Random [v7]

> Hi, could i get a review on this implementation proposed by Stuart Marks, i > decided to use the > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html > interface to create the default method `asRandom()` that wraps around the > newer algorithms

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

On Wed, 23 Feb 2022 00:40:44 GMT, Joe Darcy wrote: >> 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 >>

Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v6]

> **Background:** > > In the Java Language, Enums can be tested for equality, so the constants in > an Enum type must be unique. Javac compiles an enum declaration like this: > > > public enum Day { SUNDAY, MONDAY ... } > > > to > > > public class Day extends java.lang.Enum { >

Re: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v4]

On Sat, 19 Feb 2022 10:59:56 GMT, Alan Bateman wrote: > > Ok, thank you for the feedback. I just pushed a change with additional > > comments on the jar creation which hopefully will address your input above. > > It's a bit better but I think it needs a clear step-by-step instructions in a >

Re: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long

On Tue, 22 Feb 2022 09:24:47 GMT, Vamsi Parasa wrote: > Optimizes the divideUnsigned() and remainderUnsigned() methods in > java.lang.Integer and java.lang.Long classes using x86 intrinsics. This > change shows 3x improvement for Integer methods and upto 25% improvement for > Long. This

Re: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream [v2]

On Mon, 21 Feb 2022 18:05:08 GMT, Lance Andersen wrote: > > > The change looks innocuous so it is probably OK. I would like to kick of > > > our Mach5 runs to see if it shakes out any potential issues. > > > > > > @LanceAndersen , did you manage to get any Mach5 results? Did you find any > >

Re: RFR: 8279598: Provide adapter from RandomGenerator to Random [v6]

On Sun, 20 Feb 2022 03:15:22 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i >> decided to use the >> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html >> interface to create the default

Re: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build

On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeliński wrote: > Please review this PR that enables > [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) > compiler flag, which makes assigning a string literal

RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX

Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. The test was failed by: Incorrect handling of envstrings containing NULs According to my investigation, this issue was happened after following change was applied. JDK-8272600: (test) Use native "sleep" in Basic.java test.nativepath

Re: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build

On Tue, 22 Feb 2022 11:33:52 GMT, Magnus Ihse Bursie wrote: >> Please review this PR that enables >> [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) >> compiler flag, which makes assigning a string

Re: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build

On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeliński wrote: > Please review this PR that enables > [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) > compiler flag, which makes assigning a string literal

Re: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX

On Tue, 22 Feb 2022 12:17:59 GMT, Ichiroh Takiguchi wrote: > Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. > The test was failed by: > Incorrect handling of envstrings containing NULs > > According to my investigation, this issue was happened after following change > was

Re: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build [v2]

> Please review this PR that enables > [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) > compiler flag, which makes assigning a string literal to a non-const pointer > a compile-time error. > > This

Re: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build [v2]

On Tue, 22 Feb 2022 16:35:09 GMT, Magnus Ihse Bursie wrote: >> Done > > Did you forget to push the fix? Push works better when connected... this time it's pushed for real. - PR: https://git.openjdk.java.net/jdk/pull/7565

Re: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build [v2]

On Tue, 22 Feb 2022 14:13:43 GMT, Daniel Jeliński wrote: >> make/autoconf/flags-cflags.m4 line 136: >> >>> 134: CFLAGS_WARNINGS_ARE_ERRORS="-WX" >>> 135: >>> 136: WARNINGS_ENABLE_ALL="-W3 -Zc:strictStrings" >> >> This is not strictly a flag to enable warnings. I'd recommend you

Integrated: 8276686: Malformed Javadoc inline tags in JDK source in /java/util/regex/Pattern.java

On Thu, 17 Feb 2022 18:02:20 GMT, Ian Graves wrote: > Adding a missing period per this doc bug. This pull request has now been integrated. Changeset: 41355e2d Author:Ian Graves URL: https://git.openjdk.java.net/jdk/commit/41355e2daa43fa8433bf77ed187979c49d453f4a Stats: 1 line

Re: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v9]

On Sat, 19 Feb 2022 16:06:35 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), >> by design, duplicate initialization of ReflectionFactory should be safe as >> it performs side-effect-free property read actions, and the suggesting of >> making

RFR: 8209784: Include hsdis in the JDK

This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting this, together with a valid backend using `--with-hsdis`, will bundle the generated hsdis library with the JDK. The PR also includes a refactoring of the hsdis handling in autoconf, breaking it out to a separate file

Integrated: 8281315: Unicode, (?i) flag and backreference throwing IndexOutOfBounds Exception

On Wed, 16 Feb 2022 18:45:29 GMT, Ian Graves wrote: > This is a fix in the buggy way CIBackRef traverses unicode characters that > could be variable-length. Originally it followed the approach that BackRef > does, but failed to account for unicode characters that could be 2 > chars-long. The

Re: RFR: 8209784: Include hsdis in the JDK

On Tue, 22 Feb 2022 16:10:22 GMT, Magnus Ihse Bursie wrote: > This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting > this, together with a valid backend using `--with-hsdis`, will bundle the > generated hsdis library with the JDK. > > The PR also includes a refactoring of

Integrated: 8282042: [testbug] FileEncodingTest.java depends on default encoding

On Thu, 17 Feb 2022 22:50:37 GMT, Tyler Steele wrote: > FileEncodingTest expects all non-Windows platforms will have > `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set > to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. > > According to

Re: RFR: 8209784: Include hsdis in the JDK

On Tue, 22 Feb 2022 16:10:22 GMT, Magnus Ihse Bursie wrote: > This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting > this, together with a valid backend using `--with-hsdis`, will bundle the > generated hsdis library with the JDK. Maybe I missed it, but are there

Integrated: 8261407: ReflectionFactory.checkInitted() is not thread-safe

On Sun, 19 Dec 2021 03:21:55 GMT, liach wrote: > Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), > by design, duplicate initialization of ReflectionFactory should be safe as it > performs side-effect-free property read actions, and the suggesting of making > the

Re: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build [v2]

On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeliński wrote: >> Please review this PR that enables >> [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) >> compiler flag, which makes assigning a string

Re: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v2]

> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. > The test was failed by: > Incorrect handling of envstrings containing NULs > > According to my investigation, this issue was happened after following change > was applied. > JDK-8272600: (test) Use native "sleep" in Basic.java > >

Re: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v2]

On Tue, 22 Feb 2022 17:20:25 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following >> change was

Re: RFR: 8209784: Include hsdis in the JDK

On Tue, 22 Feb 2022 16:54:21 GMT, Andrew Haley wrote: > Maybe I missed it, but are there instructions somewhere about how to build > this, and what should be downloaded? See https://github.com/openjdk/jdk/blob/master/src/utils/hsdis/README.md - PR:

Re: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v2]

On Tue, 22 Feb 2022 17:20:25 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following >> change was

RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long

Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division

Re: RFR: 8282188: Unused static field MathContext.DEFAULT_DIGITS

On Fri, 18 Feb 2022 19:07:15 GMT, Andrey Turbanov wrote: > 8282188: Unused static field MathContext.DEFAULT_DIGITS Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7538

Re: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale

On Mon, 21 Feb 2022 14:09:50 GMT, Jaikiran Pai wrote: > Can I please get a review of this test only change which fixes the issue > noted in https://bugs.openjdk.java.net/browse/JDK-8282023? > > As noted in that JBS issue these tests fail when the default locale under > which those tests are

RFR: 8277474: jarsigner does not check if algorithm parameters are disabled

This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned.

Withdrawn: 8277474: jarsigner does not check if algorithm parameters are disabled

On Tue, 22 Feb 2022 20:18:19 GMT, Hai-May Chao wrote: > This fixes jarsigner to enforce checking against algorithm constraint > properties so when the signature algorithms parameters use disabled or legacy > algorithms, it will emit warnings accordingly. If the algorithm used in > parameters