Re: CFV: New Core Libraries Group Member: Raffaello Giulietti

2024-02-13 Thread Alan Bateman
Vote: yes

Re: OpenJDK 17: Loitering AbstractQueuedSynchronizer$ConditionNode instances (also on latest master branch)

2024-02-13 Thread Jaikiran Pai
Hello Frank, I see that a JBS issue has been created for this same issue https://bugs.openjdk.org/browse/JDK-8325754. I don't have enough knowledge of this area and haven't reviewed this part of the code in detail to see if there are any obvious issues with what you are proposing as a soluti

Re: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself [v2]

2024-02-13 Thread John Hendrikx
On Tue, 13 Feb 2024 17:11:05 GMT, John Hendrikx wrote: >> Update the documentation for `@return` tag of `putIfAbsent` to match the >> main description. `putIfAbsent` uses the same wording as `put` for its >> `@return` tag, but that is incorrect. `putIfAbsent` never returns the >> **previous**

Re: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself [v2]

2024-02-13 Thread Chen Liang
On Tue, 13 Feb 2024 17:11:05 GMT, John Hendrikx wrote: >> Update the documentation for `@return` tag of `putIfAbsent` to match the >> main description. `putIfAbsent` uses the same wording as `put` for its >> `@return` tag, but that is incorrect. `putIfAbsent` never returns the >> **previous**

Re: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v8]

2024-02-13 Thread Scott Gibbons
> Re-write the IndexOf code without the use of the pcmpestri instruction, only > using AVX2 instructions. This change accelerates String.IndexOf on average > 1.3x for AVX2. The benchmark numbers: > > > BenchmarkScore > Latest

Re: RFR: 8325506: Ensure randomness is only read from provided SecureRandom object [v3]

2024-02-13 Thread Weijun Wang
> Many crypto service classes require a `SecureRandom` object at > initialization. This test goes through each of them and calculates (generate, > encrypt, sign,...) twice with the same `SecureRandom` object and ensures the > output is the same. Weijun Wang has updated the pull request incremen

Re: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary [v2]

2024-02-13 Thread Roger Riggs
On Tue, 13 Feb 2024 21:23:29 GMT, Dan Lutker wrote: >> At the time `sleep` seemed ubiquitous and was native so it ran quickly. >> (Much quicker than running java). >> Running another program would be fine. For example ,selecting an executable >> based on the OS type and giving the expected str

Re: CFV: New Core Libraries Group Member: Raffaello Giulietti

2024-02-13 Thread mandy . chung
Vote: yes Mandy On 2/13/24 12:25 PM, Brian Burkhalter wrote: I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.

Re: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF

2024-02-13 Thread Claes Redestad
On Tue, 6 Feb 2024 23:01:07 GMT, Chen Liang wrote: >> I get warnings and build failures if I leave out those casts (`utflen` is a >> `long`) > > Ah, I meant to use the equivalent local variable int ascii, the return value > of countPositives, to avoid these casts. Missed this comment, but ende

Re: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary [v2]

2024-02-13 Thread Dan Lutker
On Tue, 13 Feb 2024 19:23:50 GMT, Roger Riggs wrote: >>> what's the output for `coreutils --help` for a single executable binary? >> >> >> # coreutils --help >> Usage: coreutils --coreutils-prog=PROGRAM_NAME [PARAMETERS]... >> Execute the PROGRAM_NAME built-in program with the given PARAMETERS

Re: CFV: New Core Libraries Group Member: Raffaello Giulietti

2024-02-13 Thread Jim Laskey
Vote: yes 📱 > On Feb 13, 2024, at 4:25 PM, Brian Burkhalter > wrote: > > I hereby nominate Raffaello Giulietti to Membership in the Core Libraries > Group. > > Raffaello has been working in the Core Library team at Oracle since April, > 2022. He has authored more than 50 contributions to Op

Re: CFV: New Core Libraries Group Member: Raffaello Giulietti

2024-02-13 Thread Iris Clark
Vote: yes Iris

Re: CFV: New Core Libraries Group Member: Raffaello Giulietti

2024-02-13 Thread Joseph D. Darcy
Vote: yes -Joe On 2/13/2024 12:25 PM, Brian Burkhalter wrote: I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group. Raffaello has been working in the Core Library team at Oracle since April, 2022. He has authored more than 50 contributions to OpenJDK in a number of

Re: CFV: New Core Libraries Group Member: Raffaello Giulietti

2024-02-13 Thread Joe Wang
Vote: yes Joe (joehw) On 2/13/24 12:25 PM, Brian Burkhalter wrote: I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.

Re: CFV: New Core Libraries Group Member: Raffaello Giulietti

2024-02-13 Thread Roger Riggs
Vote: Yes On 2/13/24 3:25 PM, Brian Burkhalter wrote: I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.

Re: CFV: New Core Libraries Group Member: Raffaello Giulietti

2024-02-13 Thread Naoto Sato
Vote: yes Naoto On 2/13/24 12:25 PM, Brian Burkhalter wrote: I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group. Raffaello has been working in the Core Library team at Oracle since April, 2022. He has authored more than 50 contributions to OpenJDK in a number of

Re: CFV: New Core Libraries Group Member: Raffaello Giulietti

2024-02-13 Thread Lance Andersen
Vote: yes On Feb 13, 2024, at 3:25 PM, Brian Burkhalter wrote: I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group. Raffaello has been working in the Core Library team at Oracle since April, 2022. He has authored more than 50 contributions to OpenJDK in a number of

CFV: New Core Libraries Group Member: Raffaello Giulietti

2024-02-13 Thread Brian Burkhalter
I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group. Raffaello has been working in the Core Library team at Oracle since April, 2022. He has authored more than 50 contributions to OpenJDK in a number of areas including numerics, formatting, regular expressions, and ra

Re: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary [v2]

2024-02-13 Thread Roger Riggs
On Tue, 13 Feb 2024 18:24:10 GMT, Dan Lutker wrote: >> To be fair, this looks similar to what `isMusl()` does: searching for >> strings in outputs. But I do wonder if `--help` would include "sleep" for >> some innocuous description somewhere, and this code would accidentally >> match. @lutkerd

Re: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary [v2]

2024-02-13 Thread Dan Lutker
On Tue, 13 Feb 2024 18:19:48 GMT, Aleksey Shipilev wrote: > what's the output for `coreutils --help` for a single executable binary? # coreutils --help Usage: coreutils --coreutils-prog=PROGRAM_NAME [PARAMETERS]... Execute the PROGRAM_NAME built-in program with the given PARAMETERS. --h

Re: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary [v2]

2024-02-13 Thread Aleksey Shipilev
On Tue, 13 Feb 2024 18:15:59 GMT, Dan Lutker wrote: >> Just ignore the binary name and only check for argv1 is imho enough. > > I couldn't think if a better way to detect what the host system had and > adding this seemed inline with the busybox check. > > The choice of running `sleep` seems li

Re: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary [v2]

2024-02-13 Thread Dan Lutker
On Tue, 13 Feb 2024 18:08:03 GMT, Bernd wrote: >> test/lib/jdk/test/lib/Platform.java line 145: >> >>> 143: } >>> 144: >>> 145: public static boolean isOSX() { >> >> This seems like a real hack. Is there really no better way to identity how >> sleep is implemented. >> I'd probably fav

Re: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary [v2]

2024-02-13 Thread Bernd
On Tue, 13 Feb 2024 17:54:43 GMT, Roger Riggs wrote: >> Dan Lutker has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove unnecessary var. > > test/lib/jdk/test/lib/Platform.java line 145: > >> 143: } >> 144: >> 145: public sta

Re: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary [v2]

2024-02-13 Thread Dan Lutker
> Ran the test on AmazonLinux 2 which has multiple binaries from coreutils > package and no coreutils executable as well as AmazonLinux 2023 that uses > `--enable-single-binary` Dan Lutker has updated the pull request incrementally with one additional commit since the last revision: Remove u

Re: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary

2024-02-13 Thread Roger Riggs
On Fri, 9 Feb 2024 23:40:00 GMT, Dan Lutker wrote: > Ran the test on AmazonLinux 2 which has multiple binaries from coreutils > package and no coreutils executable as well as AmazonLinux 2023 that uses > `--enable-single-binary` test/lib/jdk/test/lib/Platform.java line 145: > 143: } > 144

Re: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself [v2]

2024-02-13 Thread John Hendrikx
On Tue, 16 Jan 2024 13:27:31 GMT, Chen Liang wrote: >> Yeah, I wasn't sure about that, I can make it more specific, I used >> `considered` here because both unmapped keys and keys mapped to `null` are >> considered to be absent. > > I think `absent or {@code null}` is no less concise yet it is

Re: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself [v2]

2024-02-13 Thread John Hendrikx
> Update the documentation for `@return` tag of `putIfAbsent` to match the main > description. `putIfAbsent` uses the same wording as `put` for its `@return` > tag, but that is incorrect. `putIfAbsent` never returns the **previous** > value, as the whole point of the method is not the replace t

Re: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary

2024-02-13 Thread Dan Lutker
On Tue, 13 Feb 2024 10:11:36 GMT, Aleksey Shipilev wrote: >> Ran the test on AmazonLinux 2 which has multiple binaries from coreutils >> package and no coreutils executable as well as AmazonLinux 2023 that uses >> `--enable-single-binary` > > test/jdk/java/lang/ProcessHandle/InfoTest.java line

Re: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself

2024-02-13 Thread Pavel Rappo
On Tue, 16 Jan 2024 07:40:44 GMT, John Hendrikx wrote: > Update the documentation for `@return` tag of `putIfAbsent` to match the main > description. `putIfAbsent` uses the same wording as `put` for its `@return` > tag, but that is incorrect. `putIfAbsent` never returns the **previous** > val

Re: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files [v15]

2024-02-13 Thread Eirik Bjørsnøs
On Fri, 26 Jan 2024 20:49:57 GMT, Lance Andersen wrote: >> To help make progress here, I have relaxed the validation such that we now >> check: >> >> - That the "streaming mode" bit 3 flag is set >> - That at least one of the LOC's size fields are marked 0x. >> - That the LOC extra fiel

Integrated: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files

2024-02-13 Thread Eirik Bjørsnøs
On Sun, 12 Feb 2023 15:41:55 GMT, Eirik Bjørsnøs wrote: > ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the > number of compressed or uncompressed bytes read from the inflater is larger > than the Zip64 magic value. > > While the ZIP format mandates that the data descrip

Integrated: 8303891: Speed up Zip64SizeTest using a small ZIP64 file

2024-02-13 Thread Eirik Bjørsnøs
On Thu, 9 Mar 2023 12:06:52 GMT, Eirik Bjørsnøs wrote: > Please review this PR which suggests we speed up the `Zip64SizeTest` using a > small-sized ZIP64 ZIP file specifically created to reproduce the issue being > tested. > > The disk space requirement of this test is known to cause problems

[jdk22] Withdrawn: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

2024-02-13 Thread Roger Riggs
On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs wrote: > 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk22/pull/110

Re: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

2024-02-13 Thread Roger Riggs
On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs wrote: > 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 The backport was intended to be for jdk22u - PR Comment: https://git.openjdk.org/jdk22/pull/110#issuecomment-1941927141

Re: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

2024-02-13 Thread Kevin Rushforth
On Tue, 13 Feb 2024 16:09:04 GMT, Alan Bateman wrote: >> 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 > > This is for jdk22u, not jdk22 @AlanBateman You might want to unapprove this PR (go to "Files" and submit a review with "Request Changes") UPDATE: I see you alread

Re: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

2024-02-13 Thread Alan Bateman
On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs wrote: > 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 Marked as reviewed by alanb (Reviewer). This is for jdk22u, not jdk22 This is for jdk22u, not jdk22 - PR Review: https://git.openjdk.org/jdk22/pull/110#pu

Re: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

2024-02-13 Thread Kevin Rushforth
On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs wrote: > 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 @RogerRiggs Since this is deferred out of JDK 22, you need to close this PR and open a new one against jdk22u. - PR Comment: https://git.openjdk.org/jdk22/

Re: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF

2024-02-13 Thread Chen Liang
On Tue, 6 Feb 2024 18:58:01 GMT, Claes Redestad wrote: >> src/java.base/share/classes/java/io/ObjectInputStream.java line 3688: >> >>> 3686: // avoid a redundant scan >>> 3687: String utf = new String(buf, pos, >>> (int)utflen, StandardCharsets.IS

Re: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF

2024-02-13 Thread Chen Liang
On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad wrote: > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via > Data- and ObjectInputStream > > Testing: tier1-3 src/java.base/share/classes/java/io/ObjectInputStream.java line 3688: > 3686: // avoid a

Re: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF

2024-02-13 Thread Claes Redestad
On Tue, 6 Feb 2024 18:40:20 GMT, Chen Liang wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via >> Data- and ObjectInputStream >> >> Testing: tier1-3 > > src/java.base/share/classes/java/io/ObjectInputStream.java line 3688: > >> 3686: // a

Re: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF

2024-02-13 Thread Claes Redestad
On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad wrote: > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via > Data- and ObjectInputStream > > Testing: tier1-3 Benchmark numbers M1 MacBook: NameCnt Base Error Test Error Un

RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF

2024-02-13 Thread Claes Redestad
Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream Testing: tier1-3 - Commit messages: - Merge branch 'master' into io_utf8_fastpath - Reduce cost for small Strings in DataInputStream - Optimize away StringBuilder for strings smal

[jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

2024-02-13 Thread Roger Riggs
8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 - Commit messages: - Backport 13d9e8ff38536287b82c54bb63bd2d20f65615dc Changes: https://git.openjdk.org/jdk22/pull/110/files Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=110&range=00 Issue: https://bugs.

Integrated: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

2024-02-13 Thread Roger Riggs
On Mon, 12 Feb 2024 21:29:02 GMT, Roger Riggs wrote: > Correct the result string coder of a string encoded using a CharsetDecoder > with multi-byte encoded input. > Added tests for UTF16 strings and a regression test. This pull request has now been integrated. Changeset: 13d9e8ff Author:Ro

Re: RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 [v2]

2024-02-13 Thread Claes Redestad
On Tue, 13 Feb 2024 12:47:26 GMT, Roger Riggs wrote: >> Correct the result string coder of a string encoded using a CharsetDecoder >> with multi-byte encoded input. >> Added tests for UTF16 strings and a regression test. > > Roger Riggs has updated the pull request incrementally with one additio

Re: RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 [v2]

2024-02-13 Thread Alan Bateman
On Tue, 13 Feb 2024 12:47:26 GMT, Roger Riggs wrote: >> Correct the result string coder of a string encoded using a CharsetDecoder >> with multi-byte encoded input. >> Added tests for UTF16 strings and a regression test. > > Roger Riggs has updated the pull request incrementally with one additio

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

2024-02-13 Thread Jorn Vernee
> See the JBS issue for an extended problem description. > > This patch changes the specification and implementation of > `MethodHandles::byteArrayViewVarHandle`, > `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and > `ByteBuffer::alignmentOffset` to weaken the guarantees

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

2024-02-13 Thread Jorn Vernee
On Thu, 1 Feb 2024 20:10:29 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`, an

Re: RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 [v2]

2024-02-13 Thread Roger Riggs
> Correct the result string coder of a string encoded using a CharsetDecoder > with multi-byte encoded input. > Added tests for UTF16 strings and a regression test. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Test Files.readString

Re: RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 [v2]

2024-02-13 Thread Roger Riggs
On Tue, 13 Feb 2024 07:21:01 GMT, Alan Bateman wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Test Files.readString with multiple charsets >> Cleanup regression test to match style of other tests > > test/jdk/jav

Re: RFR: 8325679: Optimize ArrayList subList sort

2024-02-13 Thread Attila Szegedi
On Tue, 13 Feb 2024 03:55:37 GMT, Stuart Marks wrote: >> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and >> will thus fall back to slower default method of `List.sort()` instead of >> sorting a range of the array in-place in its backing root `ArrayList`. >> >> This do

Re: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary

2024-02-13 Thread Aleksey Shipilev
On Fri, 9 Feb 2024 23:40:00 GMT, Dan Lutker wrote: > Ran the test on AmazonLinux 2 which has multiple binaries from coreutils > package and no coreutils executable as well as AmazonLinux 2023 that uses > `--enable-single-binary` test/jdk/java/lang/ProcessHandle/InfoTest.java line 321: > 319:

Integrated: 8325558: Add jcheck whitespace checking for properties files

2024-02-13 Thread Magnus Ihse Bursie
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote: > This is an attempt to finally implement the idea brought forward in > JDK-8295729: Properties files is essentially source code. It should have the > same whitespace checks as all other source code, so we don't get spurious > trailin

Re: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent jtreg runs

2024-02-13 Thread Matthias Baesken
On Mon, 12 Feb 2024 10:47:56 GMT, Jaikiran Pai wrote: > What seems to be happening is that the system where this run appears to be > launching too many tests concurrently. Sure, that's why I want to limit the concurrency *for certain tests/ test groups* . Limiting it for the whole tier1 would