Re: RFR: 8313023: Return value corrupted when using CCS + isTrivial (mainline)

[Vladimir Ivanov]

On Tue, 25 Jul 2023 19:17:38 GMT, Jorn Vernee  wrote:

> Port of: https://github.com/openjdk/panama-foreign/pull/848 from the 
> panama-foreign repo.
> 
> Copying the PR body here for convenience:
> 
> Due to a bug in the downcall linker stub generation, we don't save the return 
> value when capturing call state for trivial functions, and the return value 
> gets corrupted.
> 
> We try not to save the return register around calls on the return path of a 
> downcall stub, if it is not needed. Currently we don't save the return 
> register when we're using a return buffer, since we write the return value to 
> the return buffer before the calls on the return path, which means it is safe 
> for those calls to overwrite the return register. But, the current logic also 
> says we don't need to save the return register if the function is trivial 
> (_needs_transition == false). The logic behind this was initially that, since 
> we don't have any calls on the return path, we don't need to save the return 
> register. But, after adding support for capturing call state, we now also 
> have a call on the return path for trivial functions that capture call state, 
> and around that call, we might need to save the return register.
> 
> The fix is to simply save the return register when capturing call state, 
> regardless of whether the function is trivial or not. In the case of just a 
> trivial function that doesn't capture call state, we still don't save the 
> return register around the return path calls for the thread state transition 
> (which is not needed), since we don't generate those thread state transitions 
> in the first first place.
> 
> Testing: jdk-tier1, jdk-tier2, jdk-tier5.

Looks good.

-

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15025#pullrequestreview-1553162267

RFR: 8306632: Add a JDK Property for specifying DTD support

[Joe Wang]

Add a JDK Impl specific property 'jdk.xml.dtd.support' for applications to 
specify how DTDs are handled. This property is uniformly supported across the 
JDK XML libraries. It complements, rather than replaces, the existing 
properties that are supportDTD for StAX and disallow-doctype-decl for DOM and 
SAX processors, which means the later will continue to work as they were and 
that if they are set, the new property will have no effect. Applications that 
use the existing properties continue to work as expected.

   This patch continues the path made previously with Xalan and XPath in which 
functions were moved into the jdk/xml classes. Similar changes are now made 
with the Xerces and XML classes, consolidating functions into the jdk/xml 
classes, reducing duplicate code for easier future maintenance.

Tests: new tests are added to cover the various processors.
   Existing tests pass. Only one was updated due to the change to the 
property impl.

-

Commit messages:
 - fix Whitespace errors
 - 8306632: Add a JDK Property for specifying DTD support

Changes: https://git.openjdk.org/jdk/pull/15075/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk=15075=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306632
  Stats: 3337 lines in 71 files changed: 2019 ins; 1135 del; 183 mod
  Patch: https://git.openjdk.org/jdk/pull/15075.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15075/head:pull/15075

PR: https://git.openjdk.org/jdk/pull/15075

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

[Brian Burkhalter]

On Wed, 26 Jul 2023 09:29:18 GMT, Alan Bateman  wrote:

> I think this is close to what you want

Modified as suggested in 9264975. The limit is increased to 1.5 Mb where it was 
in native malloc clamping. This appears to prevent any throughput degradation.

-

PR Comment: https://git.openjdk.org/jdk/pull/14981#issuecomment-1656245009

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

[Brian Burkhalter]

> Limit native memory allocation and move write loop from the native layer into 
> Java. This change should make the OOME reported in the issue much less likely.

Brian Burkhalter has updated the pull request incrementally with one additional 
commit since the last revision:

  6478546: Move buffer clamping up to Java layer; correct read behavior to 
match legacy

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/14981/files
  - new: https://git.openjdk.org/jdk/pull/14981/files/69941de4..92649751

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=14981=02
 - incr: https://webrevs.openjdk.org/?repo=jdk=14981=01-02

  Stats: 102 lines in 4 files changed: 48 ins; 20 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/14981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14981/head:pull/14981

PR: https://git.openjdk.org/jdk/pull/14981

Re: CFV: New Core Libraries Group Member: Joe Wang

[Lance Andersen]

Vote: Yes.


On 27/07/2023 19:36, Roger Riggs wrote:

I hereby nominate Joe Wang to Membership in the Core Libraries Group

Joe has been working in the core library team since 2012.
He has been maintaining and improving the XML library APIs and implementations
including DOM, SAX, StAX, Transform, Validation, XPath and Catalog.
Recently he has been updating and improving XML Security.

Votes are due by August 11th, 2023.

Only current Members of the Core Libraries Group [1] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs
[2] https://openjdk.org/groups/#member-vote

Re: CFV: New Core Libraries Group Member: Brent Christian

[Lance Andersen]

Vote: Yes.

On 27/07/2023 19:36, Roger Riggs wrote:

I hereby nominate Brent Christian to Membership in the Core Libraries Group

Brent has been working in the Core Library team at Oracle since 2012.
He has made contributions to many areas of OpenJDK including java.lang strings,
class loader, NIO Jar, and many more.  Most recently he has been working on
steps to deprecate and phase out finalization.

Previously he worked on OpenJDK AWT, Swing, and JavaFX before joining
the Core Libraries group.


Votes are due by August 11th, 2023.

Only current Members of the Core Libraries Group [1] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs
[2] https://openjdk.org/groups/#member-vote

Re: CFV: New Core Libraries Group Member: Brian Burkhalter

[Lance Andersen]

Vote: Yes.


On 27/07/2023 19:35, Roger Riggs wrote:

I hereby nominate Brian Burkhalter to Membership in the Core Libraries Group

Brian has been working in the Core Library team since 2012.
Brian's many contributions to the OpenJDK libraries include 
java.io subsystems,
NIO channels, files, and buffers. He applies his background in math and image
processing to OpenJDK development.

Previously, he led JavaFX Media team. Co-designed and implemented successor
Java audio and video playback and recording API using GStreamer, AV Foundation,
and libav.

Votes are due by August 11th, 2023.

Only current Members of the Core Libraries Group [1] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs
[2] https://openjdk.org/groups/#member-vote

Re: CFV: New Core Libraries Group Member: Joe Wang

[Chris Hegarty]

Vote: Yes.

-Chris

On 27/07/2023 19:36, Roger Riggs wrote:
|I hereby nominate Joe Wang||to Membership in the Core Libraries Group Joe has been working in the 
core library team since 2012. He has been maintaining and improving 
the XML library APIs and implementations including ||DOM, SAX, StAX, Transform, Validation, XPath and Catalog. Recently he 
has been updating and improving XML Security. Votes are due by August 
11th, 2023. Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
Votes must be cast in the open by replying to this mailing list For 
Lazy Consensus voting instructions, see [2]. Roger Riggs [1] 
https://openjdk.org/census#core-libs [2] 
https://openjdk.org/groups/#member-vote|

Re: CFV: New Core Libraries Group Member: Brent Christian

[Chris Hegarty]

Vote: Yes.

-Chris

On 27/07/2023 19:36, Roger Riggs wrote:
|I hereby nominate |Brent Christian|to Membership in the Core Libraries Group Brent has been working in 
the Core Library team at Oracle since 2012. He has made contributions 
to many areas of OpenJDK including java.lang strings, class loader, 
NIO Jar, and many more. Most recently he has been working on steps to 
deprecate and phase out finalization.|
||Previously he worked on OpenJDK AWT, Swing, and JavaFX before 
joining the Core Libraries group.| Votes are due by August 11th, 2023. 
Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
Votes must be cast in the open by replying to this mailing list For 
Lazy Consensus voting instructions, see [2]. Roger Riggs [1] 
https://openjdk.org/census#core-libs [2] 
https://openjdk.org/groups/#member-vote|

Re: CFV: New Core Libraries Group Member: Brian Burkhalter

[Chris Hegarty]

Vote: Yes.

-Chris

On 27/07/2023 19:35, Roger Riggs wrote:
|I hereby nominate |Brian Burkhalter|to Membership in the Core Libraries Group Brian has been working in 
the Core Library team since 2012. Brian's many contributions to the 
OpenJDK libraries include java.io subsystems, NIO channels, files, and 
buffers. He applies his background in math and image processing to 
OpenJDK development. ||Previously, he led JavaFX Media team. Co-designed and implemented 
successor Java audio and video playback and recording API using 
GStreamer, AV Foundation, and libav. Votes are due by August 11th, 
2023. Only current Members of the |||Core Libraries Group| [1] are eligible to vote on this nomination. 
Votes must be cast in the open by replying to this mailing list For 
Lazy Consensus voting instructions, see [2]. Roger Riggs [1] 
https://openjdk.org/census#core-libs [2] 
https://openjdk.org/groups/#member-vote|

Re: CFV: New Core Libraries Group Member: Brian Burkhalter

[Alan Bateman]

Vote: yes

Re: CFV: New Core Libraries Group Member: Brent Christian

[Alan Bateman]

Vote: yes

Re: RFR: 8310643: Misformatted copyright messages in FFM

[Amit Kumar]

On Wed, 26 Jul 2023 15:43:12 GMT, Per Minborg  wrote:

> This PR suggests updating some of the ill-formed copyright headers in the FFM 
> API and the implementation and test thereof.
> 
> Some of the test files will have now the "classpath" exception. Is this 
> correct?

Hi @minborg, 

Would you add below patch in this PR. This will add "classpath" exception 
copyright header for some files in java/lang/foreign dir. 

I have reverted the changes from my 
[PR](https://github.com/openjdk/jdk/pull/15070/commits/3958d9fe3a5fca3edebdf68ea7e082dd4768ce2f)
 as @mcimadamore  suggested. 

[java_lang_foreign_CP_exception.patch](https://github.com/openjdk/jdk/files/12196879/java_lang_foreign_CP_exception.patch)

-

PR Comment: https://git.openjdk.org/jdk/pull/15042#issuecomment-1656095047

Re: RFR: 8313312: Add missing classpath exception copyright header [v2]

[Amit Kumar]

> Adds `classpath exception` in multiple files, affects copyright header only.

Amit Kumar has updated the pull request incrementally with one additional 
commit since the last revision:

  revert java.lang.foreign changes

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/15070/files
  - new: https://git.openjdk.org/jdk/pull/15070/files/d8d7cdf3..3958d9fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=15070=01
 - incr: https://webrevs.openjdk.org/?repo=jdk=15070=00-01

  Stats: 12 lines in 4 files changed: 0 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15070/head:pull/15070

PR: https://git.openjdk.org/jdk/pull/15070

Integrated: 8312411: MessageFormat.formatToCharacterIterator() can be improved

[Justin Lu]

On Wed, 26 Jul 2023 07:39:09 GMT, Justin Lu  wrote:

> Please review this change which makes 
> `MessageFormat.formatToCharacterIterator` fail fast(er). The return statement 
> is also modified to call  toArray() as `toArray(new T[0])` over `toArray(new 
> T[size])`.

This pull request has now been integrated.

Changeset: 23755f90
Author:Justin Lu 
URL:   
https://git.openjdk.org/jdk/commit/23755f90c9fb69b0ddad0cdfcdf8add309b1d845
Stats: 7 lines in 1 file changed: 1 ins; 5 del; 1 mod

8312411: MessageFormat.formatToCharacterIterator() can be improved

Reviewed-by: naoto

-

PR: https://git.openjdk.org/jdk/pull/15035

Re: RFR: 8312491: Update Classfile API snippets and examples [v6]

[Adam Sotona]

On Thu, 27 Jul 2023 15:16:33 GMT, Adam Sotona  wrote:

>> src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 
>> 1239:
>> 
>>> 1237: return ldc(BytecodeHelpers.constantEntry(constantPool(), 
>>> value));
>>> 1238: }
>>> 1239: 
>> 
>> Method needs specification
>
> Right, we need to add a lot of missing javadoc.

I did first round of filling missing javadoc.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/14968#discussion_r1277807478

Re: RFR: 8312491: Update Classfile API snippets and examples [v6]

[Adam Sotona]

> This pull request updates Classfile API snippets and examples and adds 
> missing javadoc.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional 
commits since the last revision:

 - fixing javadoc
 - fixing javadoc

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/14968/files
  - new: https://git.openjdk.org/jdk/pull/14968/files/30d0507a..a2b4e858

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=14968=05
 - incr: https://webrevs.openjdk.org/?repo=jdk=14968=04-05

  Stats: 1464 lines in 3 files changed: 1385 ins; 0 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/14968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14968/head:pull/14968

PR: https://git.openjdk.org/jdk/pull/14968

Re: RFR: 8313307: java/util/Formatter/Padding.java fails on some Locales [v2]

[Naoto Sato]

On Fri, 28 Jul 2023 17:13:54 GMT, Aleksey Shipilev  wrote:

>> Fails like this:
>> 
>> 
>> $ CONF=macosx-aarch64-server-fastdebug make images test 
>> TEST=java/util/Formatter/Padding.java
>> 
>> ...
>> STARTED Padding::padding '[216] -001.2, % 010.1f, -1.2'
>> org.opentest4j.AssertionFailedError: expected: <-001.2> but was: 
>> <-001,2>
>> 
>> 
>> Looks like a locale problem in test, so the simplest fix is to ask for a 
>> neutral Locale there.
>
> Aleksey Shipilev has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Change to Locale.US

Marked as reviewed by naoto (Reviewer).

-

PR Review: https://git.openjdk.org/jdk/pull/15066#pullrequestreview-1552546716

Re: RFR: 8313307: java/util/Formatter/Padding.java fails on some Locales [v2]

[Aleksey Shipilev]

> Fails like this:
> 
> 
> $ CONF=macosx-aarch64-server-fastdebug make images test 
> TEST=java/util/Formatter/Padding.java
> 
> ...
> STARTED Padding::padding '[216] -001.2, % 010.1f, -1.2'
> org.opentest4j.AssertionFailedError: expected: <-001.2> but was: 
> <-001,2>
> 
> 
> Looks like a locale problem in test, so the simplest fix is to ask for a 
> neutral Locale there.

Aleksey Shipilev has updated the pull request incrementally with one additional 
commit since the last revision:

  Change to Locale.US

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/15066/files
  - new: https://git.openjdk.org/jdk/pull/15066/files/97084428..eaca173c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=15066=01
 - incr: https://webrevs.openjdk.org/?repo=jdk=15066=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15066/head:pull/15066

PR: https://git.openjdk.org/jdk/pull/15066

Re: RFR: 8313307: java/util/Formatter/Padding.java fails on some Locales [v2]

[Aleksey Shipilev]

On Fri, 28 Jul 2023 16:53:51 GMT, Naoto Sato  wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Change to Locale.US
>
> test/jdk/java/util/Formatter/Padding.java line 312:
> 
>> 310: @MethodSource
>> 311: void padding(String expected, String format, Object value) {
>> 312: assertEquals(expected, String.format(Locale.ROOT, format, 
>> value));
> 
> I suggest using `Locale.US` instead of `Locale.ROOT`. Although it works, 
> `Locale.ROOT` is an invariant locale where theoretically you cannot assume 
> the decimal point is a period. Using `Locale.US` assures that assumption, and 
> also aligns with other similar test cases.

Sure, changed to `Locale.US` in new commit.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/15066#discussion_r1277801468

Re: RFR: 8313307: java/util/Formatter/Padding.java fails on some Locales

[Naoto Sato]

On Fri, 28 Jul 2023 08:49:20 GMT, Aleksey Shipilev  wrote:

> Fails like this:
> 
> 
> $ CONF=macosx-aarch64-server-fastdebug make images test 
> TEST=java/util/Formatter/Padding.java
> 
> ...
> STARTED Padding::padding '[216] -001.2, % 010.1f, -1.2'
> org.opentest4j.AssertionFailedError: expected: <-001.2> but was: 
> <-001,2>
> 
> 
> Looks like a locale problem in test, so the simplest fix is to ask for a 
> neutral Locale there.

test/jdk/java/util/Formatter/Padding.java line 312:

> 310: @MethodSource
> 311: void padding(String expected, String format, Object value) {
> 312: assertEquals(expected, String.format(Locale.ROOT, format, 
> value));

I suggest using `Locale.US` instead of `Locale.ROOT`. Although it works, 
`Locale.ROOT` is an invariant locale where theoretically you cannot assume the 
decimal point is a period. Using `Locale.US` assures that assumption, and also 
aligns with other similar test cases.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/15066#discussion_r1277788433

Re: RFR: 8313307: java/util/Formatter/Padding.java fails on some Locales

[Justin Lu]

On Fri, 28 Jul 2023 08:49:20 GMT, Aleksey Shipilev  wrote:

> Fails like this:
> 
> 
> $ CONF=macosx-aarch64-server-fastdebug make images test 
> TEST=java/util/Formatter/Padding.java
> 
> ...
> STARTED Padding::padding '[216] -001.2, % 010.1f, -1.2'
> org.opentest4j.AssertionFailedError: expected: <-001.2> but was: 
> <-001,2>
> 
> 
> Looks like a locale problem in test, so the simplest fix is to ask for a 
> neutral Locale there.

LGTM

-

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15066#pullrequestreview-1552500764

Integrated: 8312416: Tests in Locale should have more descriptive names

[Justin Lu]

On Wed, 26 Jul 2023 07:11:16 GMT, Justin Lu  wrote:

> Please review this change which renames tests for Locale from 
> `bugNNN.java` to something more descriptive.
> 
> In addition to the name changes, accompanying copyright year, name usage 
> within the test, and other minor changes were included. The test 
> `bug4123285.java` was also removed, as it was never actually ran and 
> java.applet.Applet is deprecated and marked for removal.

This pull request has now been integrated.

Changeset: a9a3463a
Author:Justin Lu 
URL:   
https://git.openjdk.org/jdk/commit/a9a3463afb33b9df4cbf64d1866255bff638824f
Stats: 265 lines in 16 files changed: 93 ins; 138 del; 34 mod

8312416: Tests in Locale should have more descriptive names

Reviewed-by: lancea, naoto

-

PR: https://git.openjdk.org/jdk/pull/15032

[jdk21] Integrated: 8313260: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on linux-x86

[Sergey Bylokhov]

On Thu, 27 Jul 2023 18:21:45 GMT, Sergey Bylokhov  wrote:

> This patch adds the  java/lang/ScopedValue/StressStackOverflow.java to the 
> problem list for linux-x86 where it intermittently fails on a GA, ex: 
> https://github.com/openjdk/jdk21/pull/148
> 
> This is only for JDK 21, test passes on JDK 22.

This pull request has now been integrated.

Changeset: bb63b791
Author:Sergey Bylokhov 
URL:   
https://git.openjdk.org/jdk21/commit/bb63b79112852af3020fe64bac1974d26272b442
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod

8313260: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on 
linux-x86

Reviewed-by: clanger

-

PR: https://git.openjdk.org/jdk21/pull/149

Re: RFR: 8313312: Add missing classpath exception copyright header

[Maurizio Cimadamore]

On Fri, 28 Jul 2023 13:02:20 GMT, Amit Kumar  wrote:

> Adds `classpath exception` in multiple files, affects copyright header only.

Please leave the java.lang.foreign changes out of this. We already have another 
PR for those:
https://github.com/openjdk/jdk/pull/15042

-

PR Comment: https://git.openjdk.org/jdk/pull/15070#issuecomment-1655699357

Re: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex, length, initialValue)

[Pavel Rappo]

On Fri, 28 Jul 2023 10:05:01 GMT, Claes Redestad  wrote:

> I think we could consider dropping `vectorized` from `vectorizedHashCode`: 
> there's nothing in the library-side implementation for this that is 
> explicitly setting up for vectorization of each case (unlike the 
> `mismatch/vectorizedMismatch` pair).

Sounds good; I specifically dislike "vectorized" being in the name of the 
method that is called by clients who don't seem to require that behaviour. It's 
misleading.

Method naming aside, `ArraysSupport.vectorizedHashCode` has one additional 
wrinkle. One of its arguments, `int basicType`, accepts untyped constants whose 
names might be so counterintuitive that a reviewer might insist on adding an 
inline comment to indicate that a particular combination of arguments is not a 
typo, but an intended case of _unsigned bytes_, for example:

https://github.com/openjdk/jdk/blob/2bdfa836adbeba3319bee4ee61017907d6d84d58/src/java.base/unix/classes/sun/nio/fs/UnixPath.java#L801-L811

Could we hide that `int basicType` behind overloads that have static safety 
better than `Object array` and are appropriately named? For example:

public static int hashCode(byte[] array, int fromIndex, int length, int 
initialValue);
public static int unsignedHashCode(byte[] array, int fromIndex, int length, 
int initialValue);

Related, I assume this is a typo

jdk.internal.util.ArraysSupport#signedHashCode

and it should've been

jdk.internal.util.ArraysSupport#unsignedHashCode
^^^
?

-

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655477396

Re: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex, length, initialValue)

[Pavel Rappo]

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo  wrote:

> This PR adds an internal method to calculate hash code from the provided 
> integer array, offset and length into that array, and the initial hash code 
> value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's 
> either ArraysSupport.vectorizedHashCode with an offset, length and initial 
> value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or 
> puzzling. Unfortunately, it's the only hash code method that operates on an 
> array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * 
> https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * 
> https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * 
> https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR 
> adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, 
> behaviour which was specified but untested.

Perhaps surprisingly, we don't need int[]; what JDK seems to use is these:

 * byte[]
 * unsigned byte[]
 * Object[]

-

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655481239

Re: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex, length, initialValue)

[Pavel Rappo]

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo  wrote:

> This PR adds an internal method to calculate hash code from the provided 
> integer array, offset and length into that array, and the initial hash code 
> value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's 
> either ArraysSupport.vectorizedHashCode with an offset, length and initial 
> value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or 
> puzzling. Unfortunately, it's the only hash code method that operates on an 
> array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * 
> https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * 
> https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * 
> https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR 
> adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, 
> behaviour which was specified but untested.

Even with better named constants the Object type is missing. Something needs to 
be done about it.

-

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655666546

RFR: 8313312: Add missing classpath exception copyright header

[Amit Kumar]

Adds `classpath exception` in multiple files, affects copyright header only.

-

Commit messages:
 - adds classpath exception

Changes: https://git.openjdk.org/jdk/pull/15070/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk=15070=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313312
  Stats: 60 lines in 20 files changed: 40 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/15070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15070/head:pull/15070

PR: https://git.openjdk.org/jdk/pull/15070

Re: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex, length, initialValue)

[Pavel Rappo]

On Fri, 28 Jul 2023 12:37:13 GMT, Claes Redestad  wrote:

> > Perhaps surprisingly, we don't need int[]; what JDK seems to use is these:
> > 
> > * byte[]
> > * unsigned byte[]
> > * Object[]
> 
> All `vectorizedHashCode` variants are exposed (and testable) via the public 
> `java.util.Arrays.hashCode(byte/char/short/int[])` methods.

There seems to be misunderstanding. Here's the intent of my earlier comment: 
it's only those three variants above that I found to be used in JDK where a 
subrange or, to a lesser extent, a different initial value is desired. This is 
ironic since this PR is titled as "Add ArraysSupport.hashCode(**int**[] a, 
fromIndex, length, initialValue)". I guess it's because I filed the PR before I 
gathered enough stats.

One lighter-weight alternative to providing more mid-layer methods would be to 
rename `basicType` constants to be more self-descriptive. Thoughts?

-

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655640886

Re: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex, length, initialValue)

[Claes Redestad]

On Fri, 28 Jul 2023 10:49:34 GMT, Pavel Rappo  wrote:

> Perhaps surprisingly, we don't need int[]; what JDK seems to use is these:
> 
> * byte[]
> * unsigned byte[]
> * Object[]

All `vectorizedHashCode` variants are exposed (and testable) via the public 
`java.util.Arrays.hashCode(byte/char/short/int[])` methods.

-

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655620421

Re: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v6]

[Andrew Haley]

On Fri, 28 Jul 2023 03:59:26 GMT, sid8606  wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit 
> since the last revision:
> 
>   Preserve and restore register Z_R6
>   
>   Though Z_R6 is argument register it is a saved register
>   so preserve and restore Z_R6 register

src/hotspot/cpu/s390/upcallLinker_s390.cpp line 72:

> 70: // Z_SP saved/restored by prologue/epilogue
> 71: if (reg == Z_SP) continue;
> 72: // though Z_R6 is argument register it is a saved register

Suggestion:
`// although Z_R6 is used for parameter passing, it must be saved and 
restored by a called function.`

-

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1277496026

Re: [jdk21] RFR: 8313260: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on linux-x86

[Christoph Langer]

On Fri, 28 Jul 2023 09:10:20 GMT, Alan Bateman  wrote:

> JDK-8308609

I added a comment on https://bugs.openjdk.org/browse/JDK-8303498, cc 
@offamitkumar

-

PR Comment: https://git.openjdk.org/jdk21/pull/149#issuecomment-1655513822

Re: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex, length, initialValue)

[Claes Redestad]

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo  wrote:

> This PR adds an internal method to calculate hash code from the provided 
> integer array, offset and length into that array, and the initial hash code 
> value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's 
> either ArraysSupport.vectorizedHashCode with an offset, length and initial 
> value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or 
> puzzling. Unfortunately, it's the only hash code method that operates on an 
> array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * 
> https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * 
> https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * 
> https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR 
> adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, 
> behaviour which was specified but untested.

Yes, it should have been `unsignedHashCode`. 

Adding a layer of `ArraysSupport.hashCode` methods with no `basicType` 
parameter exposed, which in turn calls a renamed `vectorizedHashCode` 
(`@IntrinsicCandidate private static int internalHashCode`?) seem like a 
reasonable cleanup on the face of it. Assuming we can retain performance 
characteristics. One complication is that we'd also need to expose a 
`utf16HashCode` that takes a `byte[]` and interprets it as holding `char` 
values.

-

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655612832

Re: RFR: 8311939: Excessive allocation of Matcher.groups array [v4]

[Cristian Vat]

On Fri, 28 Jul 2023 12:15:21 GMT, Cristian Vat  wrote:

>> Reduces excessive allocation of Matcher.groups array when the original 
>> Pattern has no groups or less than 9 groups.
>> 
>> Original clamping to 10 possibly due to documented behavior from javadoc: 
>> "In this class, \1 through \9 are always interpreted as back references, "
>> 
>> Only with Matcher changes RegExTest.backRefTest fails when backreferences to 
>> non-existing groups are present.
>> Added a match failure condition in Pattern that fixes failing tests.
>> 
>> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the 
>> referenced group didn't match, neither can this"
>> 
>> A group that does not exist in the original Pattern can never match so 
>> neither can a backref to that group.
>> If the group existed in the original Pattern then it would have had space 
>> allocated in Matcher.groups for that group index.
>> So a group index outside groups array length must never match.
>
> Cristian Vat has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   changes and test for CIBackRef

Made changes also in `CIBackRef` and copied/changed test into new 
`ciBackRefTest`

Not pretty since changes to one could miss the other, but all patterns are 
different. (for what it's worth tests pass...)

There's also a special case with supplementary character tests since 
`toSupplementaries` given `(?i)` generates invalid pattern, so I had to change 
those like:
``
pattern = Pattern.compile("(?i)" + toSupplementaries("(a*)bc\\1"));
``

Definitely needs a close look by a regex expert.

-

PR Comment: https://git.openjdk.org/jdk/pull/14894#issuecomment-1655581689

Re: RFR: 8312491: Update Classfile API snippets and examples [v5]

[Adam Sotona]

> 8312491: Update Classfile API snippets and examples

Adam Sotona has updated the pull request incrementally with two additional 
commits since the last revision:

 - fixing javadoc
 - fixing javadoc

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/14968/files
  - new: https://git.openjdk.org/jdk/pull/14968/files/8071164a..30d0507a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=14968=04
 - incr: https://webrevs.openjdk.org/?repo=jdk=14968=03-04

  Stats: 1326 lines in 3 files changed: 1316 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/14968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14968/head:pull/14968

PR: https://git.openjdk.org/jdk/pull/14968

Re: RFR: 8311939: Excessive allocation of Matcher.groups array [v2]

[Cristian Vat]

On Fri, 28 Jul 2023 08:25:55 GMT, Aleksey Shipilev  wrote:

>> Cristian Vat has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   reduce allocations also for Matcher.usePattern
>
> src/java.base/share/classes/java/util/regex/Pattern.java line 5190:
> 
>> 5188: }
>> 5189: boolean match(Matcher matcher, int i, CharSequence seq) {
>> 5190: 
> 
> Excess new line.

line removed

-

PR Review Comment: https://git.openjdk.org/jdk/pull/14894#discussion_r1277471042

Re: RFR: 8311939: Excessive allocation of Matcher.groups array [v4]

[Cristian Vat]

> Reduces excessive allocation of Matcher.groups array when the original 
> Pattern has no groups or less than 9 groups.
> 
> Original clamping to 10 possibly due to documented behavior from javadoc: 
> "In this class, \1 through \9 are always interpreted as back references, "
> 
> Only with Matcher changes RegExTest.backRefTest fails when backreferences to 
> non-existing groups are present.
> Added a match failure condition in Pattern that fixes failing tests.
> 
> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the 
> referenced group didn't match, neither can this"
> 
> A group that does not exist in the original Pattern can never match so 
> neither can a backref to that group.
> If the group existed in the original Pattern then it would have had space 
> allocated in Matcher.groups for that group index.
> So a group index outside groups array length must never match.

Cristian Vat has updated the pull request incrementally with one additional 
commit since the last revision:

  changes and test for CIBackRef

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/14894/files
  - new: https://git.openjdk.org/jdk/pull/14894/files/4c6c3ec0..b591b2ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=14894=03
 - incr: https://webrevs.openjdk.org/?repo=jdk=14894=02-03

  Stats: 58 lines in 2 files changed: 58 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14894/head:pull/14894

PR: https://git.openjdk.org/jdk/pull/14894

Re: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex, length, initialValue)

[Claes Redestad]

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo  wrote:

> This PR adds an internal method to calculate hash code from the provided 
> integer array, offset and length into that array, and the initial hash code 
> value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's 
> either ArraysSupport.vectorizedHashCode with an offset, length and initial 
> value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or 
> puzzling. Unfortunately, it's the only hash code method that operates on an 
> array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * 
> https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * 
> https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * 
> https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR 
> adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, 
> behaviour which was specified but untested.

I think we could consider dropping `vectorized` from `vectorizedHashCode`: 
there's nothing in the library-side implementation for this that is explicitly 
setting up for vectorization of each case (unlike the 
`mismatch/vectorizedMismatch` pair). Handling of short arrays is dealt with in 
the intrinsic, and care was taken to make sure that the implementation is as 
fast or faster for small as well as large inputs.

It might make sense to move the tiny-input case switch to `ArraysSupport` 
though, and have it delegate to the IntrinsicCandidate method (the point of 
those is to avoid calling into the intrinsic routine for tiny inputs).

-

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655426453

Re: RFR: 8311939: Excessive allocation of Matcher.groups array [v3]

[Cristian Vat]

On Fri, 28 Jul 2023 09:29:48 GMT, Cristian Vat  wrote:

>> Reduces excessive allocation of Matcher.groups array when the original 
>> Pattern has no groups or less than 9 groups.
>> 
>> Original clamping to 10 possibly due to documented behavior from javadoc: 
>> "In this class, \1 through \9 are always interpreted as back references, "
>> 
>> Only with Matcher changes RegExTest.backRefTest fails when backreferences to 
>> non-existing groups are present.
>> Added a match failure condition in Pattern that fixes failing tests.
>> 
>> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the 
>> referenced group didn't match, neither can this"
>> 
>> A group that does not exist in the original Pattern can never match so 
>> neither can a backref to that group.
>> If the group existed in the original Pattern then it would have had space 
>> allocated in Matcher.groups for that group index.
>> So a group index outside groups array length must never match.
>
> Cristian Vat has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   remove new line

`RegExTest#backRefTest` seems to be pretty extensive but only for `BackRef` not 
`CIBackRef`

I saw one `CIBackRef` related test added in 
https://github.com/openjdk/jdk/pull/7501 but it's very simple/specific.

I triggered test failure locally by duplicating `backRefTest` 1-9 loop with 
`(?i)` in pattern so yes it seems like `CIBackRef` needs same change.

But not sure about the test, duplicating loop seems odd. Maybe entire 
`RegExTest#backRefTest` needs to be duplicated into a `ciBackRefTest` with all 
patterns preprended with `(?i)` ? Wouldn't look too clean.

-

PR Comment: https://git.openjdk.org/jdk/pull/14894#issuecomment-1655371709

Re: RFR: 8311939: Excessive allocation of Matcher.groups array [v3]

[Cristian Vat]

> Reduces excessive allocation of Matcher.groups array when the original 
> Pattern has no groups or less than 9 groups.
> 
> Original clamping to 10 possibly due to documented behavior from javadoc: 
> "In this class, \1 through \9 are always interpreted as back references, "
> 
> Only with Matcher changes RegExTest.backRefTest fails when backreferences to 
> non-existing groups are present.
> Added a match failure condition in Pattern that fixes failing tests.
> 
> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the 
> referenced group didn't match, neither can this"
> 
> A group that does not exist in the original Pattern can never match so 
> neither can a backref to that group.
> If the group existed in the original Pattern then it would have had space 
> allocated in Matcher.groups for that group index.
> So a group index outside groups array length must never match.

Cristian Vat has updated the pull request incrementally with one additional 
commit since the last revision:

  remove new line

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/14894/files
  - new: https://git.openjdk.org/jdk/pull/14894/files/596eb3db..4c6c3ec0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=14894=02
 - incr: https://webrevs.openjdk.org/?repo=jdk=14894=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14894/head:pull/14894

PR: https://git.openjdk.org/jdk/pull/14894

Re: [jdk21] RFR: 8313260: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on linux-x86

[Alan Bateman]

On Thu, 27 Jul 2023 18:21:45 GMT, Sergey Bylokhov  wrote:

> This patch adds the  java/lang/ScopedValue/StressStackOverflow.java to the 
> problem list for linux-x86 where it intermittently fails on a GA, ex: 
> https://github.com/openjdk/jdk21/pull/148
> 
> This is only for JDK 21, test passes on JDK 22.

JDK-8308609 was meant to back ported to jdk21, info jdk12u. If you are 
temporarily excluding the test on platforms that don't have a port of VM 
Continuations when JDK-8308609 is the issue to use. I assume JDK-8303498 can be 
closed.

-

PR Comment: https://git.openjdk.org/jdk21/pull/149#issuecomment-1655341421

RFR: 8313307: java/util/Formatter/Padding.java fails on some Locales

[Aleksey Shipilev]

Fails like this:


$ CONF=macosx-aarch64-server-fastdebug make images test 
TEST=java/util/Formatter/Padding.java

...
STARTED Padding::padding '[216] -001.2, % 010.1f, -1.2'
org.opentest4j.AssertionFailedError: expected: <-001.2> but was: 
<-001,2>


Looks like a locale problem in test, so the simplest fix is to ask for a 
neutral Locale there.

-

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/15066/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk=15066=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313307
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15066/head:pull/15066

PR: https://git.openjdk.org/jdk/pull/15066

Re: RFR: 8311939: Excessive allocation of Matcher.groups array [v2]

[Aleksey Shipilev]

On Sat, 22 Jul 2023 12:13:10 GMT, Cristian Vat  wrote:

>> Reduces excessive allocation of Matcher.groups array when the original 
>> Pattern has no groups or less than 9 groups.
>> 
>> Original clamping to 10 possibly due to documented behavior from javadoc: 
>> "In this class, \1 through \9 are always interpreted as back references, "
>> 
>> Only with Matcher changes RegExTest.backRefTest fails when backreferences to 
>> non-existing groups are present.
>> Added a match failure condition in Pattern that fixes failing tests.
>> 
>> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the 
>> referenced group didn't match, neither can this"
>> 
>> A group that does not exist in the original Pattern can never match so 
>> neither can a backref to that group.
>> If the group existed in the original Pattern then it would have had space 
>> allocated in Matcher.groups for that group index.
>> So a group index outside groups array length must never match.
>
> Cristian Vat has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   reduce allocations also for Matcher.usePattern

Shouldn't the similar change be in `CIBackRef.match` too? The fact current 
tests do not catch it makes me uneasy: the test coverage seems to be rather low 
there. 

We need a regex expert to look at it. @rgiulietti @igraves might help us out 
here?

src/java.base/share/classes/java/util/regex/Pattern.java line 5190:

> 5188: }
> 5189: boolean match(Matcher matcher, int i, CharSequence seq) {
> 5190: 

Excess new line.

-

PR Review: https://git.openjdk.org/jdk/pull/14894#pullrequestreview-1551614576
PR Review Comment: https://git.openjdk.org/jdk/pull/14894#discussion_r1277261871

Re: RFR: 8312491: Update Classfile API snippets and examples [v4]

[Adam Sotona]

> 8312491: Update Classfile API snippets and examples

Adam Sotona has updated the pull request incrementally with one additional 
commit since the last revision:

  fixing javadoc

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/14968/files
  - new: https://git.openjdk.org/jdk/pull/14968/files/3ccee5f7..8071164a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=14968=03
 - incr: https://webrevs.openjdk.org/?repo=jdk=14968=02-03

  Stats: 225 lines in 2 files changed: 185 ins; 29 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/14968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14968/head:pull/14968

PR: https://git.openjdk.org/jdk/pull/14968

Re: RFR: 8311939: Excessive allocation of Matcher.groups array [v2]

[Cristian Vat]

On Sat, 22 Jul 2023 12:13:10 GMT, Cristian Vat  wrote:

>> Reduces excessive allocation of Matcher.groups array when the original 
>> Pattern has no groups or less than 9 groups.
>> 
>> Original clamping to 10 possibly due to documented behavior from javadoc: 
>> "In this class, \1 through \9 are always interpreted as back references, "
>> 
>> Only with Matcher changes RegExTest.backRefTest fails when backreferences to 
>> non-existing groups are present.
>> Added a match failure condition in Pattern that fixes failing tests.
>> 
>> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the 
>> referenced group didn't match, neither can this"
>> 
>> A group that does not exist in the original Pattern can never match so 
>> neither can a backref to that group.
>> If the group existed in the original Pattern then it would have had space 
>> allocated in Matcher.groups for that group index.
>> So a group index outside groups array length must never match.
>
> Cristian Vat has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   reduce allocations also for Matcher.usePattern

ping @shipilev, if you could take a look here

-

PR Comment: https://git.openjdk.org/jdk/pull/14894#issuecomment-1655226415

Re: [jdk21] RFR: 8313260: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on linux-x86

[Christoph Langer]

On Thu, 27 Jul 2023 18:21:45 GMT, Sergey Bylokhov  wrote:

> This patch adds the  java/lang/ScopedValue/StressStackOverflow.java to the 
> problem list for linux-x86 where it intermittently fails on a GA, ex: 
> https://github.com/openjdk/jdk21/pull/148
> 
> This is only for JDK 21, test passes on JDK 22.

This is good. Thanks for doing it. I guess we should backport the real fixes to 
jdk21u.

-

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/149#pullrequestreview-1551465386

Re: [jdk21] RFR: 8313260: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on linux-x86

[Sergey Bylokhov]

On Thu, 27 Jul 2023 18:21:45 GMT, Sergey Bylokhov  wrote:

> This patch adds the  java/lang/ScopedValue/StressStackOverflow.java to the 
> problem list for linux-x86 where it intermittently fails on a GA, ex: 
> https://github.com/openjdk/jdk21/pull/148
> 
> This is only for JDK 21, test passes on JDK 22.

That bug is resolved in JDK 22 and was not backported to JDK21, one of the 
reasons described here:
https://bugs.openjdk.org/browse/JDK-8310822

At the same time, the test was updated in JDK22 by 
https://bugs.openjdk.org/browse/JDK-8311926. I think one of them solves the 
problem.

-

PR Comment: https://git.openjdk.org/jdk21/pull/149#issuecomment-1655112430

Re: [jdk21] RFR: 8313260: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on linux-x86

[Jaikiran Pai]

On Thu, 27 Jul 2023 18:21:45 GMT, Sergey Bylokhov  wrote:

> This patch adds the  java/lang/ScopedValue/StressStackOverflow.java to the 
> problem list for linux-x86 where it intermittently fails on a GA, ex: 
> https://github.com/openjdk/jdk21/pull/148
> 
> This is only for JDK 21, test passes on JDK 22.

Hello Sergey, 8308609 which is being referenced here in the problem list is 
already a resolved bug https://bugs.openjdk.org/browse/JDK-8308609. Did you 
mean to use some other bug id in the problem list? 

> This is only for JDK 21, test passes on JDK 22.

Would you happen to know why it passes on 22 but not on 21? There are several 
JBS issues and discussions around this `StressStackOverflow.java` test case, so 
it's a bit hard to determine if there's something else that needs to be 
backported to 21.

-

PR Comment: https://git.openjdk.org/jdk21/pull/149#issuecomment-1655086189