Integrated: 8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java

On Fri, 14 Mar 2025 09:17:06 GMT, Takuya Kiriyama wrote: > The current test program for the logging feature added in JDK-8301627 does > not fully check some important cases. > > Issue Details: > The test does not properly check cases where logging might not happen due to > different logging le

Re: RFR: 8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java [v3]

On Fri, 4 Apr 2025 10:29:43 GMT, Takuya Kiriyama wrote: >> The current test program for the logging feature added in JDK-8301627 does >> not fully check some important cases. >> >> Issue Details: >> The test does not properly check cases where logging might not happen due to >> different loggi

Re: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3]

> ### Background > On AArch64, the minimum vector length supported is 64-bit for basic types, > except for `byte` and `boolean` (32-bit and 16-bit respectively to match > special Vector API features). This limitation prevents intrinsification of > vector type conversions between `short` and wide

Re: RFR: 8361300: Document exceptions for Unsafe offset methods

On Tue, 24 Jun 2025 00:04:54 GMT, Chen Liang wrote: > Unsafe throws IAE for misusing static vs instance fields, and it's revealed > that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. > This is not a good practice, but we can at least document this so we don't > accid

Withdrawn: 8353795: Add Writer.of(StringBuilder)

On Sat, 5 Apr 2025 17:36:29 GMT, Markus KARG wrote: > This Pull Requests proposes an implementation for > [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new > method `public static Writer Writer.of(StringBuilder)`, providing a > non-synchronized Writer implementation op

Re: RFR: 8360122: Fix java.sql\Connection.java indentation [v2]

On Mon, 23 Jun 2025 17:45:02 GMT, Lance Andersen wrote: >> simon has updated the pull request incrementally with one additional commit >> since the last revision: >> >> 8360122: refactor code formatting to enforce 100 chars line length limit >> for improved readability > > I might not have

Re: RFR: 8360122: Fix java.sql\Connection.java indentation [v5]

> 8360122: Refine formatting of Connection.java interface > > - > ### Progress > - [ ] Change must be properly reviewed (1 review required, with at least 1 > [Reviewer](https://openjdk.org/bylaws#reviewer)) > - [x] Change must not contain extraneous whitespace > - [x] Commit message must

Re: RFR: 8360122: Fix java.sql\Connection.java indentation [v4]

On Wed, 2 Jul 2025 15:14:47 GMT, Lance Andersen wrote: >> simon has updated the pull request incrementally with one additional commit >> since the last revision: >> >> 8360122: revert reformatting method signatures > > src/java.sql/share/classes/java/sql/Connection.java line 1175: > >> 1173:

Re: RFR: 8360122: Fix java.sql\Connection.java indentation [v4]

On Wed, 2 Jul 2025 14:37:04 GMT, Lance Andersen wrote: >> simon has updated the pull request incrementally with one additional commit >> since the last revision: >> >> 8360122: revert reformatting method signatures > > src/java.sql/share/classes/java/sql/Connection.java line 303: > >> 301:

Re: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v8]

On Wed, 2 Jul 2025 23:18:38 GMT, Chen Liang wrote: >> src/hotspot/share/classfile/classFileParser.cpp line 5171: >> >>> 5169: InstanceKlass* intf = _transitive_interfaces->at(i); >>> 5170: if (intf->class_initializer() != nullptr) { >>> 5171: if (!intf->has_aot_safe_initializ

Re: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v8]

On Wed, 2 Jul 2025 18:47:58 GMT, Chen Liang wrote: >> I have updated this patch to avoid a redundant `runtimeSetup` annotation - >> we have agreed that the requirement for setup is a side effect of >> initialization, and such methods in AOTCI classes must be automatically >> recognized. This l

Re: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v8]

On Wed, 2 Jul 2025 21:18:14 GMT, Ioi Lam wrote: >> Chen Liang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Documentation > > src/hotspot/share/classfile/classFileParser.cpp line 5171: > >> 5169: InstanceKlass* intf = _transitiv

Re: RFR: 8320759: Creation of random BigIntegers can be made faster [v3]

On Sat, 2 Dec 2023 15:42:18 GMT, fabioromano1 wrote: >> A faster and simpler way to generate random BigIntegers, avoiding eventually >> trimming of leading zeros in magnitude array. > > fabioromano1 has updated the pull request incrementally with one additional > commit since the last revision:

Re: RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v11]

> Replaces the implementation `readAllCharsAsString().lines().toList()` with > reading into a temporary `char` array which is then processed to detect line > terminators and copy non-terminating characters into strings which are added > to the list. Brian Burkhalter has updated the pull request

Re: RFR: 8320759: Creation of random BigIntegers can be made faster [v3]

On Wed, 2 Jul 2025 17:50:28 GMT, Raffaello Giulietti wrote: >> @bplb Maybe an assertion at the end of `randomBits(int, Random)` method, or >> a test class. > > @fabioromano1 Do you perhaps intend to reopen this PR? @rgiulietti Yes, I will reopen this PR in future. - PR Comment: h

Re: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v8]

On Wed, 2 Jul 2025 18:47:58 GMT, Chen Liang wrote: >> I have updated this patch to avoid a redundant `runtimeSetup` annotation - >> we have agreed that the requirement for setup is a side effect of >> initialization, and such methods in AOTCI classes must be automatically >> recognized. This l

Re: RFR: 8361300: Document exceptions for Unsafe offset methods

On Tue, 24 Jun 2025 00:04:54 GMT, Chen Liang wrote: > Unsafe throws IAE for misusing static vs instance fields, and it's revealed > that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. > This is not a good practice, but we can at least document this so we don't > accid

Re: StringCharBuffer and bulk get

> On Jul 2, 2025, at 1:05 PM, Brett Okken wrote: > >> It looks like only CharBuffer.getChars is broken so the rest of the change >> can stay. I filed this issue to track it: >> >> https://bugs.openjdk.org/browse/JDK-8361299 >> >> The fix is straightforward but will break a test and require

Re: RFR: 8361300: Document exceptions for Unsafe offset methods

On Tue, 24 Jun 2025 00:04:54 GMT, Chen Liang wrote: > Unsafe throws IAE for misusing static vs instance fields, and it's revealed > that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. > This is not a good practice, but we can at least document this so we don't > accid

Re: StringCharBuffer and bulk get

> It looks like only CharBuffer.getChars is broken so the rest of the change > can stay. I filed this issue to track it: > > https://bugs.openjdk.org/browse/JDK-8361299 > > The fix is straightforward but will break a test and require a CSR. Looks like the testNG GetChars has cb.getChars(cb.posi

Re: RFR: 8361300: Document exceptions for Unsafe offset methods

On Tue, 24 Jun 2025 18:34:02 GMT, ExE Boss wrote: >> Unsafe throws IAE for misusing static vs instance fields, and it's revealed >> that AtomicXxxFieldUpdaters are using this mechanism to reject static >> fields. This is not a good practice, but we can at least document this so we >> don't acc

Re: RFR: 8361300: Document exceptions for Unsafe offset methods

On Tue, 24 Jun 2025 18:16:29 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1070: >> >>> 1068: * >>> 1069: * @throws NullPointerException if the field is {@code null} >>> 1070: * @throws IllegalArgumentException if the field is static >>

RFR: 8361300: Document exceptions for Unsafe offset methods

Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems. - Commit messages:

Re: StringCharBuffer and bulk get

On Jul 2, 2025, at 11:19 AM, Alan Bateman wrote: On 02/07/2025 16:58, Brett Okken wrote: : This makes it very difficult to pass a CharBuffer (where the position is not 0) to an api taking a CharSequence - because if that api makes a switch to start using getChars (rather than charAt), it will

Re: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v8]

> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we > have agreed that the requirement for setup is a side effect of > initialization, and such methods in AOTCI classes must be automatically > recognized. This latest revision implements that model. > > I intentionall

Re: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v7]

> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we > have agreed that the requirement for setup is a side effect of > initialization, and such methods in AOTCI classes must be automatically > recognized. This latest revision implements that model. > > I intentionall

Re: StringCharBuffer and bulk get

On 02/07/2025 16:58, Brett Okken wrote: : This makes it very difficult to pass a CharBuffer (where the position is not 0) to an api taking a CharSequence - because if that api makes a switch to start using getChars (rather than charAt), it will break. Thanks for bringing this up. It does need a

Re: RFR: 8320759: Creation of random BigIntegers can be made faster [v3]

On Wed, 6 Dec 2023 15:07:59 GMT, fabioromano1 wrote: >> So, item 1 is a non-issue and item 2 is not likely a problem in practice. >> What, if anything, will be done about item 3? > > @bplb Maybe an assertion at the end of `randomBits(int, Random)` method, or a > test class. @fabioromano1 Do yo

RFR: 8358768: [vectorapi] Make VectorOperators.SUADD an Associative

Adding SUADD an associative operation in the Vector API. Saturated addition on fixed-width unsigned integers is provably associative. - Commit messages: - Adding associative support for SUADD and associated tests Changes: https://git.openjdk.org/jdk/pull/26099/files Webrev: https

Withdrawn: 8360774: Use text representation of normalization data files

On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato wrote: > The ICU4J component currently stores binary data files directly in the > repository. This change replaces them with base64-encoded text files and > converts them to binary during the build process This pull request has been closed without b

Re: StringCharBuffer and bulk get

Sorry, I intended nio-...@openjdk.org. On Jul 2, 2025, at 9:03 AM, Brian Burkhalter wrote: I think that this discussion should be redirected to nio-dev: https://mail.openjdk.org/pipermail/nio-dev/ On Jul 2, 2025, at 9:00 AM, Brett Okken wrote: Actually it looks l

Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10]

On Wed, 2 Jul 2025 15:59:47 GMT, Roger Riggs wrote: >> Hi Jaikiran, You are correct in that the current implementation only >> supports uniqueness among time clashes and not monotonicity. Although >> section 5.7 UUID version 7 states that adding monotonic or extra precision >> bits is optional

Re: StringCharBuffer and bulk get

I think that this discussion should be redirected to nio-dev: https://mail.openjdk.org/pipermail/nio-dev/ On Jul 2, 2025, at 9:00 AM, Brett Okken wrote: Actually it looks like the CharBuffer java doc explicitly states that all CharSequence should be relative: This class implements the CharSequ

Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10]

On Wed, 2 Jul 2025 10:08:53 GMT, Kieran Farrell wrote: >> Indeed, the sections of the RFC mentioned by @jaikiran do require timestamps >> to be (strictly) monotonic. The method `monotonicMS()` does not fulfill this >> requirement. There are some methods described in §6.2 to help ensuring >> mo

Re: StringCharBuffer and bulk get

Actually it looks like the CharBuffer java doc explicitly states that all CharSequence should be relative: > This class implements the CharSequence interface so that character buffers > may be used wherever character sequences are accepted, for example in the > regular-expression package java.ut

Re: StringCharBuffer and bulk get

My question here specifically is about treating a CharBuffer as a CharSequence. The specific issue here is that when acting as a CharSequence, all the pre-jdk25 methods are relative indexes. JDK 25 added a new method to CharSequence, but the implementation in CharBuffer uses absolute indexes. This

Re: StringCharBuffer and bulk get

I think Brett is right. The spec of CharBuffer says: The methods defined by {@code CharSequence} operate relative to the current position of the buffer when they are invoked. Yet getChars is an absolute bulk get method. Since JDK25 is still in RDP, we still have a chance to fix this up.

Re: StringCharBuffer and bulk get

Some methods are absolute and some relative: https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/Buffer.html#transferring-data-heading On Jul 2, 2025, at 8:35 AM, Brett Okken wrote: CharBuffer implementation of public default void getChars(int srcBegin, int srcEnd, char[] dst,

Re: RFR: 8360122: Fix java.sql\Connection.java indentation [v4]

On Mon, 23 Jun 2025 23:09:13 GMT, simon wrote: >> 8360122: Refine formatting of Connection.java interface >> >> - >> ### Progress >> - [ ] Change must be properly reviewed (1 review required, with at least 1 >> [Reviewer](https://openjdk.org/bylaws#reviewer)) >> - [x] Change must not co

Re: StringCharBuffer and bulk get

CharBuffer implementation of public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) uses absolute positioning for the indexes (i.e. ignores the current position). https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L1900-

Re: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v5]

On Wed, 2 Jul 2025 07:48:05 GMT, Andrew Dinn wrote: >> src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 68: >> >>> 66: * @param species data type. >>> 67: */ >>> 68: @AOTSafeClassInitializer >> >> This should be placed below the `/*non-public*/` comment. > > Perhaps al

Re: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v6]

> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we > have agreed that the requirement for setup is a side effect of > initialization, and such methods in AOTCI classes must be automatically > recognized. This latest revision implements that model. > > I intentionall

Re: RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v7]

On Fri, 27 Jun 2025 23:00:04 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/Reader.java line 504: >> >>> 502: } >>> 503: if (fragLen >= cb.length/2) { >>> 504: // allocate larger buffer and copy chars to >>> be

Re: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6]

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote: >> BufferedWriter -> OutputStreamWriter -> StreamEncoder >> >> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder >> has a ByteBuffer. There are two layers of cache here, or the BufferedWriter >> layer can be removed. A

Re: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6]

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote: >> BufferedWriter -> OutputStreamWriter -> StreamEncoder >> >> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder >> has a ByteBuffer. There are two layers of cache here, or the BufferedWriter >> layer can be removed. A

Re: RFR: 8354872: Clarify java.lang.Process resource cleanup [v3]

On Wed, 2 Jul 2025 13:02:04 GMT, Jaikiran Pai wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> javadoc cleanup > > src/java.base/share/classes/java/lang/Process.java line 208: > >> 206: * >> 207: * @apiNot

Re: RFR: 8354872: Clarify java.lang.Process resource cleanup [v3]

On Wed, 2 Jul 2025 14:46:20 GMT, Roger Riggs wrote: > But including both links makes the sentence hard to read, so I picked the > more expressive reader method to link to. It didn't realize you had intentionally used the `CharSet` one. If you think the CharSet would provide better guidance to

Re: RFR: 8354872: Clarify java.lang.Process resource cleanup [v4]

On Wed, 2 Jul 2025 14:49:01 GMT, Roger Riggs wrote: >> Improve the documentation of Process use of system resources. >> >> Describe the implementation closing streams when no longer referenced. >> Clarify the interactions between inputStream and inputReader and errorStream >> and errorReader. >

Re: RFR: 8354872: Clarify java.lang.Process resource cleanup [v4]

> Improve the documentation of Process use of system resources. > > Describe the implementation closing streams when no longer referenced. > Clarify the interactions between inputStream and inputReader and errorStream > and errorReader. > Add advice and example using try-with-resources to open an

Re: RFR: 8354872: Clarify java.lang.Process resource cleanup [v3]

On Tue, 1 Jul 2025 22:30:57 GMT, Roger Riggs wrote: >> Improve the documentation of Process use of system resources. >> >> Describe the implementation closing streams when no longer referenced. >> Clarify the interactions between inputStream and inputReader and errorStream >> and errorReader. >

Re: RFR: 8354872: Clarify java.lang.Process resource cleanup [v3]

On Fri, 27 Jun 2025 16:23:59 GMT, Jaikiran Pai wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> javadoc cleanup > > src/java.base/share/classes/java/lang/ProcessBuilder.java line 545: > >> 543: * {@snippet

Re: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6]

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote: >> BufferedWriter -> OutputStreamWriter -> StreamEncoder >> >> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder >> has a ByteBuffer. There are two layers of cache here, or the BufferedWriter >> layer can be removed. A

Re: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v5]

> Refactoring `ImageReader` to make it easy to add preview mode functionality > for Valhalla. > > This PR is a large change to `ImageReader` (effectively a rewrite) but > reduces the surface area of the API significantly, reduces code complexity > and increases performance/memory efficiency. Th

Re: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v4]

On Wed, 2 Jul 2025 12:51:27 GMT, Alan Bateman wrote: >> David Beaumont has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Small feedback related tweaks. > > src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line > 26

Re: RFR: 8354872: Clarify java.lang.Process resource cleanup [v3]

On Tue, 1 Jul 2025 22:30:57 GMT, Roger Riggs wrote: >> Improve the documentation of Process use of system resources. >> >> Describe the implementation closing streams when no longer referenced. >> Clarify the interactions between inputStream and inputReader and errorStream >> and errorReader. >

Re: RFR: 8354872: Clarify java.lang.Process resource cleanup [v3]

On Tue, 1 Jul 2025 22:30:57 GMT, Roger Riggs wrote: >> Improve the documentation of Process use of system resources. >> >> Describe the implementation closing streams when no longer referenced. >> Clarify the interactions between inputStream and inputReader and errorStream >> and errorReader. >

Re: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v4]

On Wed, 2 Jul 2025 08:38:40 GMT, David Beaumont wrote: >> Refactoring `ImageReader` to make it easy to add preview mode functionality >> for Valhalla. >> >> This PR is a large change to `ImageReader` (effectively a rewrite) but >> reduces the surface area of the API significantly, reduces code

Re: RFR: 8354872: Clarify java.lang.Process resource cleanup [v3]

On Tue, 1 Jul 2025 22:30:57 GMT, Roger Riggs wrote: >> Improve the documentation of Process use of system resources. >> >> Describe the implementation closing streams when no longer referenced. >> Clarify the interactions between inputStream and inputReader and errorStream >> and errorReader. >

Re: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v4]

On Wed, 2 Jul 2025 08:38:40 GMT, David Beaumont wrote: >> Refactoring `ImageReader` to make it easy to add preview mode functionality >> for Valhalla. >> >> This PR is a large change to `ImageReader` (effectively a rewrite) but >> reduces the surface area of the API significantly, reduces code

Re: RFR: 8361253: CommandLineOptionTest library should report observed values on failure

On Wed, 2 Jul 2025 11:00:44 GMT, Manuel Hässig wrote: > When a check in `CommandLineOptionTest` fails, the `AssertionError` message > contains the expected value, but not the observed value. To reduce the amount > of digging in the logs we have to do when analyzing a failure, this PR adds > th

Re: RFR: 8361253: CommanLineOptionTest library should report observed values on failure

On Wed, 2 Jul 2025 11:00:44 GMT, Manuel Hässig wrote: > When a check in `CommandLineOptionTest` fails, the `AssertionError` message > contains the expected value, but not the observed value. To reduce the amount > of digging in the logs we have to do when analyzing a failure, this PR adds > th

RFR: 8361253: CommanLineOptionTest library should report observed values on failure

When a check in `CommandLineOptionTest` fails, the `AssertionError` message contains the expected value, but not the observed value. To reduce the amount of digging in the logs we have to do when analyzing a failure, this PR adds the observed value to the error messages. So instead of java.la

Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v12]

> With the recent approval of UUIDv7 > (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static > method UUID.timestampUUID() which constructs and returns a UUID in support of > the new time generated UUID version. > > The specification requires embedding the current times

Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v11]

> With the recent approval of UUIDv7 > (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static > method UUID.timestampUUID() which constructs and returns a UUID in support of > the new time generated UUID version. > > The specification requires embedding the current times

Re: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v4]

On Wed, 2 Jul 2025 08:38:40 GMT, David Beaumont wrote: >> Refactoring `ImageReader` to make it easy to add preview mode functionality >> for Valhalla. >> >> This PR is a large change to `ImageReader` (effectively a rewrite) but >> reduces the surface area of the API significantly, reduces code

Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10]

On Wed, 2 Jul 2025 09:52:54 GMT, Raffaello Giulietti wrote: >> Hello Roger, that's true about the uniqueness semantics. However, from what >> I understand of RFC-9562, on which this new API is based, I think it has >> much stricter expectations about monotonocity (the first 48 bits) too. For

Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10]

On Tue, 1 Jul 2025 15:20:07 GMT, Jaikiran Pai wrote: >> The uniqueness comes not just from the timestamp but also from the random >> data in the other bytes that are generated for each new UUID. > > Hello Roger, that's true about the uniqueness semantics. However, from what I > understand of RF

[jdk25] RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch

Clean backport to JDK 25. This change recently integrated in JDK 26 and is through tiers 1 - 4 so far. - Commit messages: - Backport 13a3927855da61fe27f3b43e5e4755d0c5ac5a16 Changes: https://git.openjdk.org/jdk/pull/26088/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26

Re: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v2]

On Wed, 2 Jul 2025 08:15:34 GMT, Andrew Haley wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Refine comments based on review suggestion > > src/hotspot/cpu/aarch64/aarch64.ad line 2367: > >> 2365: // Theoretic

Re: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2]

On Wed, 2 Jul 2025 01:52:19 GMT, Xiaohong Gong wrote: >> Agree with Paul, these are minor regressions. Let us proceed with this >> patch. > >> Agree with Paul, these are minor regressions. Let us proceed with this patch. > > Thanks so much for your review @sviswa7 ! > @XiaohongGong I quickly

Re: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v2]

On Wed, 2 Jul 2025 02:39:33 GMT, Xiaohong Gong wrote: >> ### Background >> On AArch64, the minimum vector length supported is 64-bit for basic types, >> except for `byte` and `boolean` (32-bit and 16-bit respectively to match >> special Vector API features). This limitation prevents intrinsific

Re: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6]

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote: >> BufferedWriter -> OutputStreamWriter -> StreamEncoder >> >> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder >> has a ByteBuffer. There are two layers of cache here, or the BufferedWriter >> layer can be removed. A

Re: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2]

On Wed, 2 Jul 2025 01:52:19 GMT, Xiaohong Gong wrote: >> Agree with Paul, these are minor regressions. Let us proceed with this >> patch. > >> Agree with Paul, these are minor regressions. Let us proceed with this patch. > > Thanks so much for your review @sviswa7 ! @XiaohongGong I quickly sc

Re: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v4]

> Refactoring `ImageReader` to make it easy to add preview mode functionality > for Valhalla. > > This PR is a large change to `ImageReader` (effectively a rewrite) but > reduces the surface area of the API significantly, reduces code complexity > and increases performance/memory efficiency. Th

Re: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v4]

On Tue, 1 Jul 2025 14:32:41 GMT, ExE Boss wrote: >> David Beaumont has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Small feedback related tweaks. > > src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 207: > >> 205:

Re: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v4]

On Tue, 1 Jul 2025 18:30:56 GMT, Roger Riggs wrote: >> David Beaumont has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Small feedback related tweaks. > > src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 555: > >> 553

Re: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v3]

On Tue, 1 Jul 2025 14:29:51 GMT, Alan Bateman wrote: >> David Beaumont has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Feedback changes. >> >> * Making some simple tests parametrized. >> * Revert change to JImageReadTest (it passe

Re: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v5]

On Tue, 1 Jul 2025 23:20:59 GMT, Chen Liang wrote: >> I have updated this patch to avoid a redundant `runtimeSetup` annotation - >> we have agreed that the requirement for setup is a side effect of >> initialization, and such methods in AOTCI classes must be automatically >> recognized. This l

Re: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v5]

On Wed, 2 Jul 2025 04:38:50 GMT, Ioi Lam wrote: >> Chen Liang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Reviewed the diff on github > > src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 68: > >> 66: * @param

Re: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v9]

On Fri, 27 Jun 2025 13:21:12 GMT, Daniel Fuchs wrote: >> Daniel Fuchs has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 525 commits: >> >> - merge latest changes from master branch >> - http3: run H3StreamLimitReachedTest.java wit