Re: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v12]

2024-07-10 Thread Jan Kratochvil
On Thu, 11 Jul 2024 06:50:21 GMT, Jan Kratochvil wrote: >> The testcase requires root permissions. >> >> Designed by Severin Gehwolf, implemented by Jan Kratochvil. > > Jan Kratochvil has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contai

Re: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v11]

2024-07-10 Thread Jan Kratochvil
On Wed, 22 May 2024 15:02:18 GMT, Jan Kratochvil wrote: >> The testcase requires root permissions. >> >> Designed by Severin Gehwolf, implemented by Jan Kratochvil. > > Jan Kratochvil has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contai

Re: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v12]

2024-07-10 Thread Jan Kratochvil
> The testcase requires root permissions. > > Designed by Severin Gehwolf, implemented by Jan Kratochvil. Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 103 commits: - Fix the gtest - fix compilation warning - fix

Re: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v7]

2024-07-10 Thread Stuart Marks
On Tue, 9 Jul 2024 23:17:47 GMT, Liam Miller-Cushon wrote: >> This change overrides mutator methods in the implementation returned by >> `Map.of().entrySet()` to throw `UnsupportedOperationException`. > > Liam Miller-Cushon has updated the pull request incrementally with one > additional commit

Re: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts

2024-07-10 Thread SendaoYan
On Wed, 10 Jul 2024 06:12:56 GMT, SendaoYan wrote: >> Hi all, >> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` >> doesn't receive jvm options from jtreg. >> I think it's necessory to receive jvm options from jtreg. >> The change has been verified, only change the test

Re: [jdk23] RFR: 8333884: MemorySegment::reinterpret removes read-only property

2024-07-10 Thread Athijegannathan Sundararajan
On Wed, 10 Jul 2024 17:01:00 GMT, Jorn Vernee wrote: > Hi all, > > This pull request contains a backport of commit > [6f7f0f1d](https://github.com/openjdk/jdk/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit bein

Re: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts

2024-07-10 Thread Jaikiran Pai
On Wed, 10 Jul 2024 06:12:56 GMT, SendaoYan wrote: >> Hi all, >> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` >> doesn't receive jvm options from jtreg. >> I think it's necessory to receive jvm options from jtreg. >> The change has been verified, only change the test

Re: RFR: 8325525: Create jtreg test case for JDK-8325203 [v4]

2024-07-10 Thread duke
On Tue, 9 Jul 2024 16:12:58 GMT, Vanitha B P wrote: >> Created jtreg test case for >> [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. >> >> The JpackageTest created tests that the child process started from the app >> launched by jpackage launcher is not automatically termina

Re: RFR: 8325525: Create jtreg test case for JDK-8325203 [v4]

2024-07-10 Thread Vanitha B P
On Wed, 10 Jul 2024 15:36:52 GMT, Alexey Semenyuk wrote: >> Vanitha B P has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Addressed the review comment > > Looks good. Thank you for doing all the adjustments to the code! Thanks @alexeyseme

Re: RFR: 8325525: Create jtreg test case for JDK-8325203 [v5]

2024-07-10 Thread Vanitha B P
> Created jtreg test case for > [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. > > The JpackageTest created tests that the child process started from the app > launched by jpackage launcher is not automatically terminated when the the > launcher is terminated. Vanitha B P ha

Re: RFR: 8333446: Add tests for hierarchical container support [v3]

2024-07-10 Thread Jan Kratochvil
On Mon, 1 Jul 2024 14:43:58 GMT, Severin Gehwolf wrote: >> Please review this PR which adds test support for systemd slices so that >> bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be >> verified. The added test, `SystemdMemoryAwarenessTest` currently passes on >> cg

Re: RFR: 8333446: Add tests for hierarchical container support [v3]

2024-07-10 Thread Jan Kratochvil
On Mon, 1 Jul 2024 14:43:58 GMT, Severin Gehwolf wrote: >> Please review this PR which adds test support for systemd slices so that >> bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be >> verified. The added test, `SystemdMemoryAwarenessTest` currently passes on >> cg

[jdk23] Integrated: 8335637: Add explicit non-null return value expectations to Object.toString()

2024-07-10 Thread Joe Darcy
On Wed, 10 Jul 2024 21:35:55 GMT, Joe Darcy wrote: > 8335637: Add explicit non-null return value expectations to Object.toString() This pull request has now been integrated. Changeset: 4aab58be Author:Joe Darcy URL: https://git.openjdk.org/jdk/commit/4aab58be4aa1bbe848084189b467d0c5

Re: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2]

2024-07-10 Thread David Holmes
On Tue, 9 Jul 2024 13:46:46 GMT, Doug Simon wrote: >> This PR addresses intermittent failures in jtreg GC stress tests. The >> failures occur under these conditions: >> 1. Using a libgraal build with assertions enabled as the top tier JIT >> compiler. Such a libgraal build will cause a VM exit

Re: [jdk23] RFR: 8335637: Add explicit non-null return value expectations to Object.toString()

2024-07-10 Thread Jaikiran Pai
On Wed, 10 Jul 2024 21:35:55 GMT, Joe Darcy wrote: > 8335637: Add explicit non-null return value expectations to Object.toString() This is a clean backport of a doc-only change with an approved CSR. Looks good to me for 23. - Marked as reviewed by jpai (Reviewer). PR Review: http

Re: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode}

2024-07-10 Thread Stuart Marks
On Wed, 10 Jul 2024 23:16:07 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/lang/Object.java line 126: >> >>> 124: * >>> 125: * As as a quality of implementation concern, a particular >>> 126: * implementation of this method may or may not support generating >> >> "may

Re: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode}

2024-07-10 Thread Stuart Marks
On Wed, 10 Jul 2024 22:33:54 GMT, Joe Darcy wrote: > First pass at adding some quality of implementation discussions around the > overridable methods of Object. @kevinb9n You should take a look at this. - PR Comment: https://git.openjdk.org/jdk/pull/20128#issuecomment-2221761107

Re: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode}

2024-07-10 Thread Stuart Marks
On Wed, 10 Jul 2024 22:33:54 GMT, Joe Darcy wrote: > First pass at adding some quality of implementation discussions around the > overridable methods of Object. src/java.base/share/classes/java/lang/Object.java line 53: > 51: * {@link VirtualMachineError} is possible during the execution of a

Re: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode}

2024-07-10 Thread Stuart Marks
On Wed, 10 Jul 2024 22:33:54 GMT, Joe Darcy wrote: > First pass at adding some quality of implementation discussions around the > overridable methods of Object. src/java.base/share/classes/java/lang/Object.java line 48: > 46: * to provide reasonable implementations of these methods. In > 47:

Re: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode}

2024-07-10 Thread Joe Darcy
On Wed, 10 Jul 2024 22:33:54 GMT, Joe Darcy wrote: > First pass at adding some quality of implementation discussions around the > overridable methods of Object. src/java.base/share/classes/java/lang/Object.java line 49: > 47: * particular, the implementations should take care to avoid using >

Re: RFR: 8335802: Improve startup speed HexFormat uses boolean instead of enum [v2]

2024-07-10 Thread Chen Liang
On Wed, 10 Jul 2024 22:02:12 GMT, Shaojin Wen wrote: >> The current HexFormat defines an Enum to represent LowerCase and UpperCase >> >> >> class HexFormat { >> private enum Case { >> LOWERCASE, >> UPPERCASE >> } >> } >> >> >> This will cause the JVM to load one more c

Re: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode}

2024-07-10 Thread Joe Darcy
On Wed, 10 Jul 2024 22:54:23 GMT, Chen Liang wrote: >> First pass at adding some quality of implementation discussions around the >> overridable methods of Object. > > src/java.base/share/classes/java/lang/Object.java line 126: > >> 124: * >> 125: * As as a quality of implementation c

Re: RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode}

2024-07-10 Thread Chen Liang
On Wed, 10 Jul 2024 22:33:54 GMT, Joe Darcy wrote: > First pass at adding some quality of implementation discussions around the > overridable methods of Object. src/java.base/share/classes/java/lang/Object.java line 126: > 124: * > 125: * As as a quality of implementation concern, a

RFR: 8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode}

2024-07-10 Thread Joe Darcy
First pass at adding some quality of implementation discussions around the overridable methods of Object. - Commit messages: - Appease jcheck. - JDK-8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode} Changes: https://git.openjdk.org/jdk/pull/

Re: RFR: 8335802: Improve startup speed HexFormat uses boolean instead of enum [v2]

2024-07-10 Thread Shaojin Wen
On Wed, 10 Jul 2024 13:01:21 GMT, Chen Liang wrote: > The internal enum representation is an unnecessary abstraction; a boolean for > uppercase is used for all public endpoints in `isUpperCase` and `toString`, > so using the same boolean internally makes sense. > > Do you think we should call

[jdk23] RFR: 8335935: Chained builders not sending transformed models to next transforms

2024-07-10 Thread Chen Liang
Please review this non-clean backport of the bugfix in #20100 to release 23, where ClassFile API chained builders does not emit certain elements through downstream transforms and returns wrong builder for chaining. This backport includes an additional change that rolls back a rename done in #199

Re: [jdk23] RFR: 8334653: ISO 4217 Amendment 177 Update

2024-07-10 Thread Naoto Sato
On Wed, 10 Jul 2024 22:08:47 GMT, Justin Lu wrote: > Please review this PR, which is a backport of commit > [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > This change incorporates

[jdk23] RFR: 8334653: ISO 4217 Amendment 177 Update

2024-07-10 Thread Justin Lu
Please review this PR, which is a backport of commit [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. This change incorporates the ISO 4217 Amendment 177 Update. - Commit messa

Re: RFR: 8334653: ISO 4217 Amendment 177 Update [v3]

2024-07-10 Thread Steven Loomis
On Fri, 21 Jun 2024 01:58:05 GMT, Naoto Sato wrote: > Out of curiosity, what's the rationale behind the currency name change from > "Zimbabwe Dollar" (ISO 4217 definition) to "Zimbabwean Dollar"? I'm not sure. - PR Review Comment: https://git.openjdk.org/jdk/pull/19813#discussion_

Re: RFR: 8335802: Improve startup speed HexFormat uses boolean instead of enum [v2]

2024-07-10 Thread Shaojin Wen
> The current HexFormat defines an Enum to represent LowerCase and UpperCase > > > class HexFormat { > private enum Case { > LOWERCASE, > UPPERCASE > } > } > > > This will cause the JVM to load one more class when it starts, which can be > seen as follows > > > public

Re: [jdk23] RFR: 8334418: Update IANA Language Subtag Registry to Version 2024-06-14

2024-07-10 Thread Naoto Sato
On Wed, 10 Jul 2024 21:46:36 GMT, Justin Lu wrote: > Please review this PR, which is a backport of commit > [861aefca](https://github.com/openjdk/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > This updates the IANA sub

[jdk23] RFR: 8334418: Update IANA Language Subtag Registry to Version 2024-06-14

2024-07-10 Thread Justin Lu
Please review this PR, which is a backport of commit [861aefca](https://github.com/openjdk/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. This updates the IANA subtag registry to version 2024-06-14. - Commit mess

[jdk23] RFR: 8335637: Add explicit non-null return value expectations to Object.toString()

2024-07-10 Thread Joe Darcy
8335637: Add explicit non-null return value expectations to Object.toString() - Commit messages: - Backport 66db71563c3ebd715a1192a9b399b618d7bdb8d0 Changes: https://git.openjdk.org/jdk/pull/20124/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20124&range=00 Issue: https

Integrated: 8335935: Chained builders not sending transformed models to next transforms

2024-07-10 Thread Chen Liang
On Tue, 9 Jul 2024 17:34:14 GMT, Chen Liang wrote: > Please review the fix for a major transformation bug within the ClassFile > API, where certain kinds of buffered elements produced by one transform is > not sent to the next, and the "chained" (`andThen` transformation chains) > builders ret

Re: RFR: 8335935: Chained builders not sending transformed models to next transforms

2024-07-10 Thread Chen Liang
On Tue, 9 Jul 2024 17:34:14 GMT, Chen Liang wrote: > Please review the fix for a major transformation bug within the ClassFile > API, where certain kinds of buffered elements produced by one transform is > not sent to the next, and the "chained" (`andThen` transformation chains) > builders ret

Re: RFR: 8336021: Doccheck: valign not allowed for HTML5 in java.xml

2024-07-10 Thread Lance Andersen
On Wed, 10 Jul 2024 16:24:01 GMT, Joe Wang wrote: > Remove valign Attribute from the javadoc for org.w3c.dom.Attr. The table > looks good with the default setting. Marked as reviewed by lancea (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/20117#pullrequestreview-217028

[jdk23] Integrated: 8333886: Explicitly specify that asSlice and reinterpret return a memory segment backed by the same region of memory.

2024-07-10 Thread Jorn Vernee
On Wed, 10 Jul 2024 16:08:51 GMT, Jorn Vernee wrote: > Hi all, > > This pull request contains a backport of commit > [c80e2eb3](https://github.com/openjdk/jdk/commit/c80e2eb35c4eb03f17a2a31e979e5c369453e203) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit bein

[jdk23] Integrated: 8333886: Explicitly specify that asSlice and reinterpret return a memory segment backed by the same region of memory.

2024-07-10 Thread Jorn Vernee
Hi all, This pull request contains a backport of commit [c80e2eb3](https://github.com/openjdk/jdk/commit/c80e2eb35c4eb03f17a2a31e979e5c369453e203) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Per Minborg on 12 Jun 2024 and was revi

Re: [jdk23] Integrated: 8333886: Explicitly specify that asSlice and reinterpret return a memory segment backed by the same region of memory.

2024-07-10 Thread Athijegannathan Sundararajan
On Wed, 10 Jul 2024 16:08:51 GMT, Jorn Vernee wrote: > Hi all, > > This pull request contains a backport of commit > [c80e2eb3](https://github.com/openjdk/jdk/commit/c80e2eb35c4eb03f17a2a31e979e5c369453e203) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit bein

Integrated: 8335637: Add explicit non-null return value expectations to Object.toString()

2024-07-10 Thread Joe Darcy
On Sun, 7 Jul 2024 20:20:30 GMT, Joe Darcy wrote: > Make well-behaved implementation expectations of Object.{toString, hashCode} > explicit. This pull request has now been integrated. Changeset: 66db7156 Author:Joe Darcy URL: https://git.openjdk.org/jdk/commit/66db71563c3ebd715a119

Re: RFR: 8335637: Add explicit non-null return value expectations to Object.toString() [v4]

2024-07-10 Thread Stuart Marks
On Wed, 10 Jul 2024 05:02:36 GMT, Joe Darcy wrote: >> Make well-behaved implementation expectations of Object.{toString, hashCode} >> explicit. > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Narrow scope of the change. Mark

Re: RFR: 8332249: Micro-optimize Method.hashCode [v2]

2024-07-10 Thread Sean Gwizdak
On Tue, 11 Jun 2024 08:58:34 GMT, Aleksey Shipilev wrote: >> Sean Gwizdak has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains six additional >> comm

Re: RFR: 8332249: Micro-optimize Method.hashCode [v2]

2024-07-10 Thread Chen Liang
On Mon, 3 Jun 2024 18:00:35 GMT, Sean Gwizdak wrote: >> Improve the speed of Method.hashCode by caching the hashcode on first use. >> I've seen an application where Method.hashCode is a hot path, and this is a >> fairly simple speedup. The memory overhead is low. >> >> This addresses issue >

Re: RFR: 8325525: Create jtreg test case for JDK-8325203 [v4]

2024-07-10 Thread Alexey Semenyuk
On Tue, 9 Jul 2024 16:12:58 GMT, Vanitha B P wrote: >> Created jtreg test case for >> [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue. >> >> The JpackageTest created tests that the child process started from the app >> launched by jpackage launcher is not automatically termina

Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23]

2024-07-10 Thread Raffaello Giulietti
On Tue, 9 Jul 2024 20:06:40 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in >> works [here](https://inria.hal.science/inria-00072854/en/) and >> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The

Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v23]

2024-07-10 Thread fabioromano1
On Wed, 10 Jul 2024 12:13:32 GMT, Raffaello Giulietti wrote: > Yes, thanks, I saw it. If some other clarifications are needed, please let me know. - PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2220362708

Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v21]

2024-07-10 Thread fabioromano1
On Tue, 9 Jul 2024 18:14:03 GMT, Raffaello Giulietti wrote: >> fabioromano1 has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Ensure normalized value in MutableBigInteger initialization with ints > > Everything not obvious that departs fr

Re: [jdk23] RFR: 8333884: MemorySegment::reinterpret removes read-only property

2024-07-10 Thread Chen Liang
On Wed, 10 Jul 2024 17:01:00 GMT, Jorn Vernee wrote: > Hi all, > > This pull request contains a backport of commit > [6f7f0f1d](https://github.com/openjdk/jdk/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit bein

[jdk23] RFR: 8333884: MemorySegment::reinterpret removes read-only property

2024-07-10 Thread Jorn Vernee
Hi all, This pull request contains a backport of commit [6f7f0f1d](https://github.com/openjdk/jdk/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Per Minborg on 6 Jul 2024 and was revie

RFR: 8336021: Doccheck: valign not allowed for HTML5 in java.xml

2024-07-10 Thread Joe Wang
Remove valign Attribute from the javadoc for org.w3c.dom.Attr. The table looks good with the default setting. - Commit messages: - 8336021: Doccheck: valign not allowed for HTML5 in java.xml Changes: https://git.openjdk.org/jdk/pull/20117/files Webrev: https://webrevs.openjdk.org

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v5]

2024-07-10 Thread Axel Boldt-Christmas
> When inflating a monitor the `ObjectMonitor*` is written directly over the > `markWord` and any overwritten data is displaced into a displaced `markWord`. > This is problematic for concurrent GCs which needs extra care or looser > semantics to use this displaced data. In Lilliput this data als

Re: RFR: 8335802: Improve startup speed HexFormat uses boolean instead of enum

2024-07-10 Thread Chen Liang
On Fri, 5 Jul 2024 23:06:17 GMT, Shaojin Wen wrote: > The current HexFormat defines an Enum to represent LowerCase and UpperCase > > > class HexFormat { > private enum Case { > LOWERCASE, > UPPERCASE > } > } > > > This will cause the JVM to load one more class when it

Re: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2]

2024-07-10 Thread Tom Rodriguez
On Tue, 9 Jul 2024 13:46:46 GMT, Doug Simon wrote: >> This PR addresses intermittent failures in jtreg GC stress tests. The >> failures occur under these conditions: >> 1. Using a libgraal build with assertions enabled as the top tier JIT >> compiler. Such a libgraal build will cause a VM exit

Re: RFR: 8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation [v2]

2024-07-10 Thread Doug Simon
On Wed, 10 Jul 2024 06:19:52 GMT, David Holmes wrote: >> Though I see this is inconsistent with `Exceptions::_throw_msg_cause` > > Okay I think I see how the logic works. If we were going to abort we would > never reach `_throw_cause` as the initial `_throw` would have exited. But for > the `!t

Re: RFR: 8335668: NumberFormat integer only parsing should throw exception for edge case [v2]

2024-07-10 Thread Naoto Sato
On Tue, 9 Jul 2024 20:29:48 GMT, Justin Lu wrote: >> Please review this PR which corrects a case in NumberFormat integer only >> parsing. >> >> [JDK-8333755](https://bugs.openjdk.org/browse/JDK-8333755) fixed integer >> only parsing when the value has a suffix, although it caused incorrect >>

Re: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long)

2024-07-10 Thread Jasmine Karthikeyan
On Tue, 9 Jul 2024 12:07:37 GMT, Galder Zamarreño wrote: > This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in > order to help improve vectorization performance. > > Currently vectorization does not kick in for loops containing either of these > calls because of the fo

Re: Read-only view of ByteArrayInputStream content

2024-07-10 Thread Archie Cobbs
On Wed, Jul 10, 2024 at 12:05 PM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > Le 2024-07-10 à 18 h 00, Archie Cobbs a écrit : > > So would you accept a solution to this problem in the java.sql package > instead? For example by adding two new methods: > java.sql.Blob.asByteBuffe

Re: Read-only view of ByteArrayInputStream content

2024-07-10 Thread Martin Desruisseaux
Le 2024-07-10 à 18 h 00, Archie Cobbs a écrit : So would you accept a solution to this problem in the java.sql package instead? For example by adding two new methods: java.sql.Blob.asByteBuffer() java.sql.Clob.asCharBuffer() Yes, it would work for me if JDBC drivers provide their own imple

Re: Read-only view of ByteArrayInputStream content

2024-07-10 Thread Archie Cobbs
On Tue, Jul 9, 2024 at 1:42 PM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > > Basically, the BLOB API seems clearly designed to allow the implementation > to stream the data on demand if it wants to (which is good), but as a side > effect it doesn't provide a way for the caller

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v3]

2024-07-10 Thread Axel Boldt-Christmas
On Tue, 9 Jul 2024 20:44:58 GMT, Coleen Phillimore wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Add JVMCI symbol exports >> - Revert "More graceful JVMCI VM option interaction" >> >>This rever

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v4]

2024-07-10 Thread Axel Boldt-Christmas
> When inflating a monitor the `ObjectMonitor*` is written directly over the > `markWord` and any overwritten data is displaced into a displaced `markWord`. > This is problematic for concurrent GCs which needs extra care or looser > semantics to use this displaced data. In Lilliput this data als

Re: RFR: 8335637: Add explicit non-null return value expectations to Object.toString() [v4]

2024-07-10 Thread Raffaello Giulietti
On Wed, 10 Jul 2024 05:02:36 GMT, Joe Darcy wrote: >> Make well-behaved implementation expectations of Object.{toString, hashCode} >> explicit. > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Narrow scope of the change. It's

Re: RFR: 8335642: Hide Transform implementation for Class-File API [v2]

2024-07-10 Thread Adam Sotona
On Tue, 9 Jul 2024 19:00:45 GMT, Chen Liang wrote: >> Removes ClassFile API transformation implementation details accidentally >> leaked to public API. Users don't have access to classes necessary to >> correctly implement these transform resolutions. In addition, removed >> improper `canWrite

Re: RFR: 8335935: Chained builders not sending transformed models to next transforms

2024-07-10 Thread Adam Sotona
On Tue, 9 Jul 2024 17:34:14 GMT, Chen Liang wrote: > Please review the fix for a major transformation bug within the ClassFile > API, where certain kinds of buffered elements produced by one transform is > not sent to the next, and the "chained" (`andThen` transformation chains) > builders ret