Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-23 Thread Quan Anh Mai
On Wed, 24 Jan 2024 06:27:20 GMT, David Holmes wrote: >> I think of this as an expression that is always evaluated to the same value. >> The value itself is not interesting, it is the set of values that this >> expression can take that we are talking about. > > This seems really weird to me

Re: RFR: 8320712: Rewrite BadFactoryTest in pure Java [v2]

2024-01-23 Thread Jaikiran Pai
On Wed, 24 Jan 2024 06:50:36 GMT, Eirik Bjørsnøs wrote: >> Please review this PR which rewrites the BadFactoryTest to pure Java/JUnit. >> The test is currently implemented using a mix of shell script and a Java >> main method. >> >> Reviewers may notice the following changes: >> >> - The

Re: RFR: 8320712: Rewrite BadFactoryTest in pure Java

2024-01-23 Thread Eirik Bjørsnøs
On Wed, 24 Jan 2024 05:03:29 GMT, Jaikiran Pai wrote: > The only part that is unclear to me is the use of `@library > /javax/script/JDK_8196959`. Does the test fail if that isn't added? Thanks! I must have thought this was required to put the service definition file on the classpath. But it

Re: RFR: 8320712: Rewrite BadFactoryTest in pure Java [v2]

2024-01-23 Thread Eirik Bjørsnøs
> Please review this PR which rewrites the BadFactoryTest to pure Java/JUnit. > The test is currently implemented using a mix of shell script and a Java main > method. > > Reviewers may notice the following changes: > > - The shell script file `BadFactoryTest.sh` has been retired and jtreg

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-23 Thread David Holmes
On Tue, 23 Jan 2024 22:46:20 GMT, Quan Anh Mai wrote: >> src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 56: >> >>> 54: */ >>> 55: @IntrinsicCandidate >>> 56: public static boolean isCompileConstant(boolean expr) { >> >> Here and in other places: probably not

Re: RFR: 8323832: Load JVMCI with the platform class loader [v2]

2024-01-23 Thread David Holmes
On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon wrote: >> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform >> class loader instead of the boot class loader. This allows Native Image to >> load a version of JVMCI different than the version on top of which Native >>

Re: RFR: 8320712: Rewrite BadFactoryTest in pure Java

2024-01-23 Thread Jaikiran Pai
On Mon, 27 Nov 2023 17:44:24 GMT, Eirik Bjørsnøs wrote: > Please review this PR which rewrites the BadFactoryTest to pure Java/JUnit. > The test is currently implemented using a mix of shell script and a Java main > method. > > Reviewers may notice the following changes: > > - The shell

Withdrawn: 8320712: Rewrite BadFactoryTest in pure Java

2024-01-23 Thread duke
On Mon, 27 Nov 2023 17:44:24 GMT, Eirik Bjørsnøs wrote: > Please review this PR which rewrites the BadFactoryTest to pure Java/JUnit. > The test is currently implemented using a mix of shell script and a Java main > method. > > Reviewers may notice the following changes: > > - The shell

Re: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v41]

2024-01-23 Thread Vicente Romero
On Mon, 22 Jan 2024 18:42:56 GMT, Aggelos Biboudis wrote: >> This is the proposed patch for Primitive types in patterns, instanceof, and >> switch (Preview). >> >> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/ > > Aggelos Biboudis has updated the pull request with a

RFR: 8324573: HashMap::putAll should resize to sum of both map sizes

2024-01-23 Thread Joshua Cao
This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps. I used the command below to run the benchmarks. I set a high heap to reduce garbage

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v4]

2024-01-23 Thread Archie Cobbs
> Please consider this fix to ensure that going from `MessageFormat` to pattern > string via `toPattern()` and then back via `new MessageFormat()` results in a > format that is equivalent to the original. > > The quoting and escaping rules for `MessageFormat` pattern strings are really >

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v3]

2024-01-23 Thread Archie Cobbs
On Tue, 23 Jan 2024 22:15:40 GMT, Justin Lu wrote: >> Archie Cobbs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add @implNote to Javadoc for toPattern(). > > test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v3]

2024-01-23 Thread Justin Lu
On Tue, 23 Jan 2024 23:12:19 GMT, Archie Cobbs wrote: >> test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line >> 96: >> >>> 94: @ParameterizedTest >>> 95: @MethodSource("testCases") >>> 96: public void testRoundTrip(MessageFormat format1) { >> >> Can we

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v3]

2024-01-23 Thread Archie Cobbs
On Tue, 23 Jan 2024 23:00:29 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/text/MessageFormat.java line 556: >> >>> 554: * does not necessarily equal the previously applied pattern. >>> 555: * >>> 556: * @implNote The string returned by this method can be used to

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v3]

2024-01-23 Thread Archie Cobbs
On Tue, 23 Jan 2024 22:13:09 GMT, Justin Lu wrote: >> Archie Cobbs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add @implNote to Javadoc for toPattern(). > > src/java.base/share/classes/java/text/MessageFormat.java line 1: > >> 1:

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v3]

2024-01-23 Thread Naoto Sato
On Tue, 23 Jan 2024 22:13:14 GMT, Justin Lu wrote: >> Archie Cobbs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add @implNote to Javadoc for toPattern(). > > src/java.base/share/classes/java/text/MessageFormat.java line 556: > >>

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 20:01:45 GMT, Paul Sandoz wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> ident > > src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 32: > >> 30: *

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 17:42:40 GMT, Aleksey Shipilev wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> ident > > src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 56: > >> 54: */ >> 55:

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 17:40:52 GMT, Aleksey Shipilev wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> ident > > src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 119: > >> 117: * @see

Integrated: JDK-8321545: Override toString() for Format subclasses

2024-01-23 Thread Justin Lu
On Wed, 10 Jan 2024 21:05:38 GMT, Justin Lu wrote: > Please review this PR which implements toString() for the `Format` > subclasses. Corresponding CSR: > [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088) > > The general specification follows a template that provides the locale (if

Re: RFR: JDK-6503196: API doc for DecimalFormat::getMaximumIntegerDigits is unclear

2024-01-23 Thread Iris Clark
On Tue, 23 Jan 2024 18:40:42 GMT, Justin Lu wrote: > Please review this PR which clarifies some confusion for the digit getter and > setter methods of DecimalFormat. > > When formatting non `BigInteger` and `BigDecimal` values, DecimalFormat uses > 309/340 as hard limits for integer and

Re: RFR: JDK-6503196: API doc for DecimalFormat::getMaximumIntegerDigits is unclear

2024-01-23 Thread Naoto Sato
On Tue, 23 Jan 2024 18:40:42 GMT, Justin Lu wrote: > Please review this PR which clarifies some confusion for the digit getter and > setter methods of DecimalFormat. > > When formatting non `BigInteger` and `BigDecimal` values, DecimalFormat uses > 309/340 as hard limits for integer and

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v3]

2024-01-23 Thread Justin Lu
On Fri, 19 Jan 2024 23:30:43 GMT, Archie Cobbs wrote: >> Please consider this fix to ensure that going from `MessageFormat` to >> pattern string via `toPattern()` and then back via `new MessageFormat()` >> results in a format that is equivalent to the original. >> >> The quoting and escaping

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v8]

2024-01-23 Thread Naoto Sato
On Tue, 23 Jan 2024 18:53:39 GMT, Jim Laskey wrote: >> Currently String::translateEscapes does not support unicode escapes, >> reported as a IllegalArgumentException("Invalid escape sequence: ..."). >> String::translateEscapes should translate unicode escape sequences to >> provide full

Re: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong

2024-01-23 Thread Chen Liang
On Tue, 23 Jan 2024 18:24:59 GMT, Jorn Vernee wrote: >> Should we make these unaligned access modes throw ISE like before, when the >> given index is unaligned? > > You mean `get` and `set`? They should never throw, as unaligned access is > fine. For other access modes, we can never guarantee

Re: Gatherer: spliterator characteristics are not propagated

2024-01-23 Thread forax
> From: "Viktor Klang" > To: "Remi Forax" > Cc: "core-libs-dev" , "Paul Sandoz" > > Sent: Monday, January 22, 2024 10:06:27 PM > Subject: Re: Gatherer: spliterator characteristics are not propagated >> The flags are in sync with the implementation because the only way to create >> a >>

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-23 Thread Paul Sandoz
On Tue, 23 Jan 2024 17:21:47 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch introduces `JitCompiler::isConstantExpression` which can be used >> to statically determine whether an expression has been constant-folded by >> the Jit compiler, leading to more constant-folding opportunities. For

Re: RFR: JDK-8321545: Override toString() for Format subclasses [v6]

2024-01-23 Thread Justin Lu
> Please review this PR which implements toString() for the `Format` > subclasses. Corresponding CSR: > [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088) > > The general specification follows a template that provides the locale (if the > class is localized) and any relevant patterns.

Re: RFR: 8323832: Load JVMCI with the platform class loader

2024-01-23 Thread Doug Simon
On Tue, 23 Jan 2024 17:00:20 GMT, xxDark wrote: > Passing `null` as parent class loader would suffice as boot loader just uses > `findBootstrapClassOrNull` in `JavaLangAccess` either way Thanks! I've simplified the test accordingly: 1642276ea22a5d789e01a5ecb1059d8c5c8be284 - PR

Re: RFR: 8323832: Load JVMCI with the platform class loader [v2]

2024-01-23 Thread Doug Simon
> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform > class loader instead of the boot class loader. This allows Native Image to > load a version of JVMCI different than the version on top of which Native > Image is running. This capability is demonstrated and tested

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v8]

2024-01-23 Thread Jim Laskey
> Currently String::translateEscapes does not support unicode escapes, reported > as a IllegalArgumentException("Invalid escape sequence: ..."). > String::translateEscapes should translate unicode escape sequences to provide > full coverage, Jim Laskey has updated the pull request

RFR: JDK-6503196: API doc for DecimalFormat::getMaximumIntegerDigits is unclear

2024-01-23 Thread Justin Lu
Please review this PR which clarifies some confusion for the digit getter and setter methods of DecimalFormat. When formatting non `BigInteger` and `BigDecimal` values, DecimalFormat uses 309/340 as hard limits for integer and fraction digit limits, regardless of the value set by the user.

Re: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong

2024-01-23 Thread Jorn Vernee
On Tue, 23 Jan 2024 14:43:24 GMT, Chen Liang wrote: > Also curious, is there any documentation (like JVMS) that allows JVMs to make > no offset into byte arrays aligned for larger access? Would be helpful if we > can have a reference here. There is simply no guarantee in the JVMS that array

Re: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong

2024-01-23 Thread Jorn Vernee
On Tue, 23 Jan 2024 14:30:08 GMT, Chen Liang wrote: >> Good idea. Thanks > > Should we make these unaligned access modes throw ISE like before, when the > given index is unaligned? You mean `get` and `set`? They should never throw, as unaligned access is fine. For other access modes, we can

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v3]

2024-01-23 Thread Aleksey Shipilev
On Tue, 23 Jan 2024 16:01:05 GMT, Aleksey Shipilev wrote: >> Would it be possible to list further examples where this might be used? >> Asking because I'm wondering about the usability and maintainability of >> if-then-else code. > >> Would it be possible to list further examples where this

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-23 Thread Aleksey Shipilev
On Tue, 23 Jan 2024 17:21:47 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch introduces `JitCompiler::isConstantExpression` which can be used >> to statically determine whether an expression has been constant-folded by >> the Jit compiler, leading to more constant-folding opportunities. For

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v3]

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 16:01:05 GMT, Aleksey Shipilev wrote: >> Would it be possible to list further examples where this might be used? >> Asking because I'm wondering about the usability and maintainability of >> if-then-else code. > >> Would it be possible to list further examples where this

Re: RFR: 8322149: ConcurrentHashMap smarter presizing for copy constructor and putAll [v3]

2024-01-23 Thread Volker Simonis
On Mon, 22 Jan 2024 22:10:44 GMT, Joshua Cao wrote: >> test/micro/org/openjdk/bench/java/util/concurrent/Maps.java line 122: >> >>> 120: @Benchmark >>> 121: public ConcurrentHashMap >>> testConcurrentHashMapPutAll() { >>> 122: ConcurrentHashMap map = new >>>

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-23 Thread Quan Anh Mai
> Hi, > > This patch introduces `JitCompiler::isConstantExpression` which can be used > to statically determine whether an expression has been constant-folded by the > Jit compiler, leading to more constant-folding opportunities. For example, it > can be used in

Re: RFR: 8322149: ConcurrentHashMap smarter presizing for copy constructor and putAll [v4]

2024-01-23 Thread Volker Simonis
On Mon, 22 Jan 2024 22:13:50 GMT, Joshua Cao wrote: >> ConcurrentHashMap's copy constructor calls `putAll()` -> `tryPresize()` -> >> `transfer()`. When coming from the copy constructor, the Map is empty, so >> there is nothing to transfer. But `transfer()` will still copy all the empty >>

Re: RFR: 8323832: Load JVMCI with the platform class loader

2024-01-23 Thread xxDark
On Mon, 22 Jan 2024 17:34:16 GMT, Doug Simon wrote: > This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform > class loader instead of the boot class loader. This allows Native Image to > load a version of JVMCI different than the version on top of which Native > Image is

Re: RFR: 8323515: Create test alias "all" for all test roots [v3]

2024-01-23 Thread Aleksey Shipilev
On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev wrote: >> Since recent work to improve `tier4` performance, we actually test >> `tier{1,2,3,4}` often, which includes all the tests in current tree. It >> would be more convenient to just have the `all` test group/alias, so that we >> can do

Integrated: 8323515: Create test alias "all" for all test roots

2024-01-23 Thread Aleksey Shipilev
On Mon, 15 Jan 2024 11:05:09 GMT, Aleksey Shipilev wrote: > Since recent work to improve `tier4` performance, we actually test > `tier{1,2,3,4}` often, which includes all the tests in current tree. It would > be more convenient to just have the `all` test group/alias, so that we can do >

Re: RFR: 8323515: Create test alias "all" for all test roots [v3]

2024-01-23 Thread Leonid Mesnik
On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev wrote: >> Since recent work to improve `tier4` performance, we actually test >> `tier{1,2,3,4}` often, which includes all the tests in current tree. It >> would be more convenient to just have the `all` test group/alias, so that we >> can do

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v3]

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 15:44:40 GMT, Aleksey Shipilev wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> add more overloads > > src/hotspot/share/classfile/vmIntrinsics.hpp line 927: > >> 925:

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v4]

2024-01-23 Thread Quan Anh Mai
> Hi, > > This patch introduces `JitCompiler::isConstantExpression` which can be used > to statically determine whether an expression has been constant-folded by the > Jit compiler, leading to more constant-folding opportunities. For example, it > can be used in

Re: RFR: 8323832: Load JVMCI with the platform class loader

2024-01-23 Thread Doug Simon
On Mon, 22 Jan 2024 17:34:16 GMT, Doug Simon wrote: > This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform > class loader instead of the boot class loader. This allows Native Image to > load a version of JVMCI different than the version on top of which Native > Image is

RFR: 8323832: Load JVMCI with the platform class loader

2024-01-23 Thread Doug Simon
This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform class loader instead of the boot class loader. This allows Native Image to load a version of JVMCI different than the version on top of which Native Image is running. This capability is demonstrated and tested by

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v3]

2024-01-23 Thread Aleksey Shipilev
On Tue, 23 Jan 2024 15:52:29 GMT, Alan Bateman wrote: > Would it be possible to list further examples where this might be used? > Asking because I'm wondering about the usability and maintainability of > if-then-else code. A similar thing is already used in JDK:

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v3]

2024-01-23 Thread Alan Bateman
On Tue, 23 Jan 2024 11:18:43 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch introduces `JitCompiler::isConstantExpression` which can be used >> to statically determine whether an expression has been constant-folded by >> the Jit compiler, leading to more constant-folding opportunities. For

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v3]

2024-01-23 Thread Aleksey Shipilev
On Tue, 23 Jan 2024 11:18:43 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch introduces `JitCompiler::isConstantExpression` which can be used >> to statically determine whether an expression has been constant-folded by >> the Jit compiler, leading to more constant-folding opportunities. For

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v15]

2024-01-23 Thread Severin Gehwolf
> Please review this patch which adds a jlink mode to the JDK which doesn't > need the packaged modules being present. A.k.a run-time image based jlink. > Fundamentally this patch adds an option to use `jlink` even though your JDK > install might not come with the packaged modules (directory

Re: RFR: 8323515: Create test alias "all" for all test roots [v3]

2024-01-23 Thread Aleksey Shipilev
On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev wrote: >> Since recent work to improve `tier4` performance, we actually test >> `tier{1,2,3,4}` often, which includes all the tests in current tree. It >> would be more convenient to just have the `all` test group/alias, so that we >> can do

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v3]

2024-01-23 Thread Kim Barrett
On Tue, 23 Jan 2024 11:18:43 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch introduces `JitCompiler::isConstantExpression` which can be used >> to statically determine whether an expression has been constant-folded by >> the Jit compiler, leading to more constant-folding opportunities. For

Re: RFR: 8323717: Introduce test keyword for tests that need external dependencies

2024-01-23 Thread Aleksey Shipilev
On Tue, 23 Jan 2024 14:42:20 GMT, Roger Riggs wrote: > Is there any place to document the new keyword or its usage; it does not seem > very discoverable just existing in the TEST.ROOT and some tests. I don't think there is a place to describe keywords, except in the relevant `TEST.ROOT`-s.

Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v6]

2024-01-23 Thread Kim Barrett
On Wed, 10 Jan 2024 22:12:40 GMT, Brent Christian wrote: >> Classes in the `java.lang.ref` package would benefit from an update to bring >> the spec in line with how the VM already behaves. The changes would focus on >> _happens-before_ edges at some key points during reference processing. >>

Re: RFR: 8322768: Optimize non-subword vector compress and expand APIs for AVX2 target. [v9]

2024-01-23 Thread Emanuel Peter
On Tue, 23 Jan 2024 11:56:58 GMT, Jatin Bhateja wrote: >> Hi, >> >> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 >> only targets. >> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 >> instruction set. >> These are very frequently used APIs

Re: RFR: JDK-8321545: Override toString() for Format subclasses [v5]

2024-01-23 Thread Roger Riggs
On Fri, 12 Jan 2024 22:41:46 GMT, Justin Lu wrote: >> Please review this PR which implements toString() for the `Format` >> subclasses. Corresponding CSR: >> [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088) >> >> The general specification follows a template that provides the locale

Re: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong

2024-01-23 Thread Chen Liang
On Thu, 16 Nov 2023 18:10:28 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4518: >> >>> 4516: * Only plain {@linkplain VarHandle.AccessMode#GET get} and >>> {@linkplain VarHandle.AccessMode#SET set} >>> 4517: * access modes are

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v13]

2024-01-23 Thread Severin Gehwolf
On Thu, 18 Jan 2024 21:35:06 GMT, Mandy Chung wrote: > > > If I read the code correctly, the image created with this option will > > > enable multi-hops unconditionally? i.e. no timestamp file created and > > > disable the check completely. I think the .stamp file should be present > > > in

Re: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong

2024-01-23 Thread Chen Liang
On Wed, 15 Nov 2023 22:46:03 GMT, Jorn Vernee wrote: > See the JBS issue for an extended problem description. > > This patch changes the specification and implementation of > `MethodHandles::byteArrayViewVarHandle`, > `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and

Re: RFR: 8323717: Introduce test keyword for tests that need external dependencies

2024-01-23 Thread Roger Riggs
On Mon, 15 Jan 2024 10:48:23 GMT, Aleksey Shipilev wrote: > Some jtreg tests require resolvable external dependencies. This resolution is > delegated to JIB, which is not used in vanilla OpenJDK testing. It would be > convenient to add a keyword that marks tests that require these external >

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v14]

2024-01-23 Thread Severin Gehwolf
> Please review this patch which adds a jlink mode to the JDK which doesn't > need the packaged modules being present. A.k.a run-time image based jlink. > Fundamentally this patch adds an option to use `jlink` even though your JDK > install might not come with the packaged modules (directory

Integrated: 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed

2024-01-23 Thread sendaoYan
On Mon, 22 Jan 2024 09:31:43 GMT, sendaoYan wrote: > 8323640: [TESTBUG]testMemoryFailCount in > jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because > OOM killed This pull request has now been integrated. Changeset: 791b427f Author:sendaoYan Committer: Severin

Re: RFR: 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed [v3]

2024-01-23 Thread Severin Gehwolf
On Tue, 23 Jan 2024 13:04:43 GMT, sendaoYan wrote: >> 8323640: [TESTBUG]testMemoryFailCount in >> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail >> because OOM killed > > sendaoYan has updated the pull request incrementally with one additional > commit since the last

Re: RFR: 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed [v3]

2024-01-23 Thread sendaoYan
On Tue, 23 Jan 2024 13:04:43 GMT, sendaoYan wrote: >> 8323640: [TESTBUG]testMemoryFailCount in >> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail >> because OOM killed > > sendaoYan has updated the pull request incrementally with one additional > commit since the last

Re: RFR: 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed [v3]

2024-01-23 Thread sendaoYan
> 8323640: [TESTBUG]testMemoryFailCount in > jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because > OOM killed sendaoYan has updated the pull request incrementally with one additional commit since the last revision: 8323640: [TESTBUG]testMemoryFailCount in

Re: RFR: 8322768: Optimize non-subword vector compress and expand APIs for AVX2 target. [v8]

2024-01-23 Thread Jatin Bhateja
On Tue, 23 Jan 2024 08:17:13 GMT, Emanuel Peter wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Review comments resolution > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5301: > >> 5299:

Re: RFR: 8322768: Optimize non-subword vector compress and expand APIs for AVX2 target. [v9]

2024-01-23 Thread Jatin Bhateja
> Hi, > > Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 only > targets. > Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 > instruction set. > These are very frequently used APIs in columnar database filter operation. > > Implementation uses a

Re: RFR: 8323515: Create test alias "all" for all test roots [v3]

2024-01-23 Thread Jan Lahoda
On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev wrote: >> Since recent work to improve `tier4` performance, we actually test >> `tier{1,2,3,4}` often, which includes all the tests in current tree. It >> would be more convenient to just have the `all` test group/alias, so that we >> can do

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v3]

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 11:18:43 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch introduces `JitCompiler::isConstantExpression` which can be used >> to statically determine whether an expression has been constant-folded by >> the Jit compiler, leading to more constant-folding opportunities. For

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v3]

2024-01-23 Thread Quan Anh Mai
> Hi, > > This patch introduces `JitCompiler::isConstantExpression` which can be used > to statically determine whether an expression has been constant-folded by the > Jit compiler, leading to more constant-folding opportunities. For example, it > can be used in

[jdk22] RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64

2024-01-23 Thread Goetz Lindenmaier
I backport this to fix this issue in 22. We see it failing there in our CI. - Commit messages: - Backport c2e77e2f17b624e750dea8fd51bbfde99596690e Changes: https://git.openjdk.org/jdk22/pull/95/files Webrev: https://webrevs.openjdk.org/?repo=jdk22=95=00 Issue:

Re: RFR: 8323717: Introduce test keyword for tests that need external dependencies

2024-01-23 Thread Aleksey Shipilev
On Tue, 23 Jan 2024 01:32:45 GMT, David Holmes wrote: > Seems quite reasonable. Thanks! I shall wait for more reviewers, in case someone has an issue with `external-dep` as the flag name. - PR Comment: https://git.openjdk.org/jdk/pull/17421#issuecomment-1905719123

Withdrawn: 8318966: Some methods make promises about Java array element alignment that are too strong

2024-01-23 Thread duke
On Wed, 15 Nov 2023 22:46:03 GMT, Jorn Vernee wrote: > See the JBS issue for an extended problem description. > > This patch changes the specification and implementation of > `MethodHandles::byteArrayViewVarHandle`, > `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and

Re: RFR: 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed [v2]

2024-01-23 Thread Severin Gehwolf
On Tue, 23 Jan 2024 01:58:40 GMT, sendaoYan wrote: >> 8323640: [TESTBUG]testMemoryFailCount in >> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail >> because OOM killed > > sendaoYan has updated the pull request incrementally with one additional > commit since the last

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler

2024-01-23 Thread Aleksey Shipilev
On Tue, 23 Jan 2024 09:31:51 GMT, Quan Anh Mai wrote: > Maybe I am ignorant but doesn't the definition of an intrinsics contain the > signature of the method as well? The definitions in `vmIntrinsics`, sure, they require full signature for `@IntrinsicCandidate` methods. It would yield some

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler

2024-01-23 Thread Aleksey Shipilev
On Tue, 23 Jan 2024 08:16:07 GMT, Aleksey Shipilev wrote: >> Hi, >> >> This patch introduces `JitCompiler::isConstantExpression` which can be used >> to statically determine whether an expression has been constant-folded by >> the Jit compiler, leading to more constant-folding opportunities.

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 08:16:07 GMT, Aleksey Shipilev wrote: > I would suggest we just do the private > `java.lang.{Integer,...}.isCompileConstant` methods and bind them to that > intrinsic. Maybe I am ignorant but doesn't the definition of an intrinsics contain the signature of the method as

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler

2024-01-23 Thread Quan Anh Mai
On Tue, 23 Jan 2024 08:16:07 GMT, Aleksey Shipilev wrote: >> Hi, >> >> This patch introduces `JitCompiler::isConstantExpression` which can be used >> to statically determine whether an expression has been constant-folded by >> the Jit compiler, leading to more constant-folding opportunities.

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v2]

2024-01-23 Thread Quan Anh Mai
> Hi, > > This patch introduces `JitCompiler::isConstantExpression` which can be used > to statically determine whether an expression has been constant-folded by the > Jit compiler, leading to more constant-folding opportunities. For example, it > can be used in

Re: RFR: 8322768: Optimize non-subword vector compress and expand APIs for AVX2 target. [v8]

2024-01-23 Thread Emanuel Peter
On Sat, 20 Jan 2024 09:55:45 GMT, Jatin Bhateja wrote: >> Hi, >> >> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2 >> only targets. >> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2 >> instruction set. >> These are very frequently used APIs

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler

2024-01-23 Thread Aleksey Shipilev
On Tue, 23 Jan 2024 08:10:54 GMT, Quan Anh Mai wrote: > Hi, > > This patch introduces `JitCompiler::isConstantExpression` which can be used > to statically determine whether an expression has been constant-folded by the > Jit compiler, leading to more constant-folding opportunities. For

RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler

2024-01-23 Thread Quan Anh Mai
Hi, This patch introduces `JitCompiler::isConstantExpression` which can be used to statically determine whether an expression has been constant-folded by the Jit compiler, leading to more constant-folding opportunities. For example, it can be used in `MemorySessionImpl::checkValidStateRaw` to