Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v8]

On Thu, 16 May 2024 22:20:39 GMT, Joe Wang wrote: >> Add two sample configuration files: >> >> jaxp-strict.properties: used to set strict configuration, stricter than >> jaxp.properties in previous versions such as JDK 22 >> >>> jaxp-compat.properties: used to regain compatibility from

Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi Aman, You may also run into hidden classes (JEP 371: Hidden Classes) that allow classes to be defined, at runtime, without names. It has been proposed to use them for generated proxies but that hasn't been implemented yet. There are benefits to having nameless classes, because they can't be

Re: RFR: 8331224: ClassCastException in ObjectInputStream hides ClassNotFoundException

On Wed, 1 May 2024 18:43:21 GMT, Roger Riggs wrote: > The issue reported a ClassCastException "cannot assign instance of > java.util.CollSer to field of type java.util.Map" > while deserializing an object referring to an immutable Map that contained a > reference to a class that was not

Re: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic [v9]

On Fri, 10 May 2024 00:19:32 GMT, Volodymyr Paprotski wrote: >> Performance. Before: >> >> Benchmark(algorithm) (dataSize) (keyLength) >> (provider) Mode Cnt ScoreError Units >> SignatureBench.ECDSA.signSHA256withECDSA1024 256

Re: RFR: 8332154: Memory leak in SynchronousQueue

On Thu, 16 May 2024 15:06:45 GMT, Viktor Klang wrote: >> Local testing seems to indicate that this fix (which mirrors what's done in >> the FIFO mode) addresses the problem. >> >> But with that said, I haven't come up with a decent way of adding some form >> of regression test. Suggestions

Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v8]

> Add two sample configuration files: > > jaxp-strict.properties: used to set strict configuration, stricter than > jaxp.properties in previous versions such as JDK 22 > >> jaxp-compat.properties: used to regain compatibility from any more >> restricted configuration than previous versions

Re: RFR: 8331224: ClassCastException in ObjectInputStream hides ClassNotFoundException

On Wed, 1 May 2024 18:43:21 GMT, Roger Riggs wrote: > The issue reported a ClassCastException "cannot assign instance of > java.util.CollSer to field of type java.util.Map" > while deserializing an object referring to an immutable Map that contained a > reference to a class that was not

Re: RFR: 8320448: Accelerate IndexOf using AVX2 [v7]

On Tue, 16 Jan 2024 12:09:11 GMT, Jatin Bhateja wrote: >> Scott Gibbons has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 22 commits: >> >> - Merge branch 'openjdk:master' into indexof >> - Merge branch 'openjdk:master' into

Re: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]

On Mon, 6 May 2024 20:56:36 GMT, Sandhya Viswanathan wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Rearrange; add lambdas for clarity > > src/hotspot/cpu/x86/macroAssembler_x86.cpp line 1174: > >> 1172: //

Re: RFR: 8320448: Accelerate IndexOf using AVX2 [v19]

On Tue, 7 May 2024 17:25:04 GMT, Volodymyr Paprotski wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Rearrange; add lambdas for clarity > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4492: > >> 4490: >>

Re: In support of Instant.minus(Instant)

I remain happy to see until() go into the JDK. Potentially on more classes than the recent PR. *If* Java gets operator overloading, and *if* it is based on a mapping to method names, then *perhaps* there is a case to consider adding minus(). But I don't feel now is the time. Stephen On Thu, 16

Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v7]

On Thu, 16 May 2024 18:53:40 GMT, Joe Wang wrote: >> Add two sample configuration files: >> >> jaxp-strict.properties: used to set strict configuration, stricter than >> jaxp.properties in previous versions such as JDK 22 >> >>> jaxp-compat.properties: used to regain compatibility from

Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a secure by default configuration [v7]

> Add two sample configuration files: > > jaxp-strict.properties: used to set strict configuration, stricter than > jaxp.properties in previous versions such as JDK 22 > > jaxp-compat.properties: used to regain compatibility from any more > restricted configuration than previous versions

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]

On Thu, 16 May 2024 12:23:44 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and

Re: RFR: 8332340: Add JavacBench as a test case for CDS [v2]

On Thu, 16 May 2024 03:31:05 GMT, Chen Liang wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> (1) comments from @liach; (2) added javadoc; (3) Use >> createTestJavaProcessBuilder() instead of >>

Re: RFR: 8332340: Add JavacBench as a test case for CDS [v2]

> JavacBench is a test program that compiles 90 Java source files. It uses a > fair amount of invokedynamic callsites, so it's good for testing CDS support > for indy and lambda expressions. > > This test was first integrated into the > [leyden](https://github.com/openjdk/leyden/tree/premain)

Re: In support of Instant.minus(Instant)

Hi all, Sorry for the delay here. I took a quick look at other popular date/time libraries and there seems to be a fairly strong preference for minus (JS/TS's Temporal library is the only other date/time library that I found which uses until for this concept): - Abseil's Time (C++)

Re: RFR: 8330276: Console methods with explicit Locale [v7]

On Wed, 15 May 2024 17:05:17 GMT, Naoto Sato wrote: >> Proposing new overloaded methods in `java.io.Console` class that explicitly >> take a `Locale` argument. Existing methods rely on the default locale, so >> the users won't be able to format their prompts/outputs in a certain locale >>

Integrated: 8331202: Support for Duration until another Instant

On Mon, 29 Apr 2024 19:40:31 GMT, Naoto Sato wrote: > A new method on Instant to return the duration `until` another Instant is > suggested per the following discussion thread: > > https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html > > A CSR has also been drafted. This

Re: RFR: 8331202: Support for Duration until another Instant [v3]

On Wed, 1 May 2024 17:21:20 GMT, Naoto Sato wrote: >> A new method on Instant to return the duration `until` another Instant is >> suggested per the following discussion thread: >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html >> >> A CSR has also been drafted. >

Re: RFR: 8330465: Stable Values and Collections (Internal) [v16]

Is it possible to make stable values and collections Serializable? I see various applications for this feature in entity classes as a way to preserve immutability of entity fields and at the same time not break current JPA specifications. It is a *very* common task in commercial development.

Re: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi, > have not looked into LambdaMetafactory because I did not encounter it as a > problem so far It is possible that java agents are unable to intercept it. `-verbose:class` logs classes such as "org.apache.pdfbox.cos.COSDocument$$Lambda/0x7a80631a0d08". Regards, Aman Sharma PhD

Re: RFR: 8332154: Memory leak in SynchronousQueue

On Thu, 16 May 2024 14:54:52 GMT, Viktor Klang wrote: > Local testing seems to indicate that this fix (which mirrors what's done in > the FIFO mode) addresses the problem. > > But with that said, I haven't come up with a decent way of adding some form > of regression test. Suggestions are

RFR: 8332154: Memory leak in SynchronousQueue

Local testing seems to indicate that this fix (which mirrors what's done in the FIFO mode) addresses the problem. But with that said, I haven't come up with a decent way of adding some form of regression test. Suggestions are most welcome. /cc @DougLea - Commit messages: - Memory

Re: RFR: 8331865: Consolidate size and alignment checks in LayoutPath [v2]

> When creating a nested memory access var handle, we ensure that the segment > is accessed at the correct alignment for the root layout being accessed. But > we do not ensure that the segment has at least the size of the accessed root > layout. Example: > > > MemoryLayout LAYOUT =

Re: RFR: 8331865: Consolidate size and alignment checks in LayoutPath [v2]

On Thu, 16 May 2024 14:34:41 GMT, Maurizio Cimadamore wrote: >> When creating a nested memory access var handle, we ensure that the segment >> is accessed at the correct alignment for the root layout being accessed. But >> we do not ensure that the segment has at least the size of the

Re: RFR: 8331865: Consolidate size and alignment checks in LayoutPath

On Thu, 16 May 2024 13:55:15 GMT, Maurizio Cimadamore wrote: > > Do we have any performance tests available to see if there are any > > potential impacts? > > I've run all micro benchmarks whose name match `LoopOver*`. No regression was > found. Few benchmarks seems a tad faster, but the

Re: RFR: 8330465: Stable Values and Collections (Internal) [v16]

On Thu, 16 May 2024 12:48:24 GMT, Per Minborg wrote: >> # Stable Values & Collections (Internal) >> >> ## Summary >> This PR proposes to introduce an internal _Stable Values & Collections_ API, >> which provides immutable value holders where elements are initialized _at >> most once_. Stable

Re: RFR: 8331865: Consolidate size and alignment checks in LayoutPath

On Thu, 16 May 2024 11:18:18 GMT, Per Minborg wrote: > Do we have any performance tests available to see if there are any potential > impacts? I've run all micro benchmarks whose name match `LoopOver*`. No regression was found. Few benchmarks seems a tad faster, but the percentages are so

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

On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman wrote: >>> > @mlchung @AlanBateman Any thoughts on this latest version? Is this going >>> > into the direction you had envisioned? Any more blockers? The CSR should >>> > be up-to-date and is open for review as well. If no more blockers I'll go

Re: RFR: 8332086: Remove the usage of ServiceLoader in j.u.r.RandomGeneratorFactory [v5]

On Thu, 16 May 2024 12:35:22 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java >> line 204: >> >>> 202: new RandomGeneratorProperties(rgClass, name, group, >>> 203: i, j, k,

Re: RFR: 8332086: Remove the usage of ServiceLoader in j.u.r.RandomGeneratorFactory [v6]

> All random number generator algorithms are implemented in module `java.base`. > The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer > needed. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Rely on

Re: RFR: 8331670: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal [v2]

On Thu, 16 May 2024 07:14:53 GMT, Alan Bateman wrote: >> This is the implementation changes for JEP 471. >> >> The methods in sun.misc.Unsafe for on-heap and off-heap access are >> deprecated for removal. This means a removal warning at compile time. No >> methods have been removed. A

Re: RFR: 8330465: Stable Values and Collections (Internal) [v16]

> # Stable Values & Collections (Internal) > > ## Summary > This PR proposes to introduce an internal _Stable Values & Collections_ API, > which provides immutable value holders where elements are initialized _at > most once_. Stable Values & Collections offer the performance and safety >

Re: RFR: 8332086: Remove the usage of ServiceLoader in j.u.r.RandomGeneratorFactory [v5]

On Thu, 16 May 2024 10:51:14 GMT, Jaikiran Pai wrote: >> Raffaello Giulietti has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Small documentation changes. > > test/jdk/java/util/Random/RandomTestCoverage.java line 179: > >> 177:

Re: RFR: 8332086: Remove the usage of ServiceLoader in j.u.r.RandomGeneratorFactory [v5]

On Thu, 16 May 2024 10:33:55 GMT, Jaikiran Pai wrote: >> Raffaello Giulietti has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Small documentation changes. > > src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line

Re: RFR: 8330465: Stable Values and Collections (Internal) [v15]

> # Stable Values & Collections (Internal) > > ## Summary > This PR proposes to introduce an internal _Stable Values & Collections_ API, > which provides immutable value holders where elements are initialized _at > most once_. Stable Values & Collections offer the performance and safety >

Re: RFR: 8330465: Stable Values and Collections (Internal) [v14]

> # Stable Values & Collections (Internal) > > ## Summary > This PR proposes to introduce an internal _Stable Values & Collections_ API, > which provides immutable value holders where elements are initialized _at > most once_. Stable Values & Collections offer the performance and safety >

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v7]

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting > the use of JNI in the following ways: > > * `System::load` and `System::loadLibrary` are now restricted methods > * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods > * binding a JNI `native`

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v6]

On Thu, 16 May 2024 11:55:35 GMT, Jaikiran Pai wrote: >> We already do, see >> https://github.com/openjdk/jdk/pull/19213/files/1c45e5d56c429205ab8185481bc1044a86ab3bc6#diff-d05029afe6aed86f860a10901114402f1f6af4fe1e4b46d883141ab1d2a527b8R582 > > This is slightly different from what we do in the

Re: Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Hi, Thanks for your response, Liang! > I think you meant CVE-2021-42392 instead of 2022. Sorry of the error. I indeed meant CVE-2021-42392. > Leyden mainly avoids this unstable generation by performing a training run to > collect classes

Re: RFR: 8330465: Stable Values and Collections (Internal) [v13]

> # Stable Values & Collections (Internal) > > ## Summary > This PR proposes to introduce an internal _Stable Values & Collections_ API, > which provides immutable value holders where elements are initialized _at > most once_. Stable Values & Collections offer the performance and safety >

Re: RFR: 8331876: JFR: Move file read and write events to java.base [v5]

> Hi, > > Could I have a review of a change that moves the jdk.FileRead and > jdk.FileWrite events to java.base to remove the use of the ASM > instrumentation. > > Testing: jdk/jdk/jfr > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since

Re: RFR: 8330465: Stable Values and Collections (Internal) [v5]

On Thu, 16 May 2024 11:14:16 GMT, Chen Liang wrote: >> The idea here is to have the most likely value in the middle... Not sure if >> that motivates the added complexity though. > > Is there any refernce on how/why the middle entry in a tableswitch > instruction is the fastest? It is only in

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v6]

On Thu, 16 May 2024 11:47:13 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/sun/launcher/resources/launcher.properties line >> 72: >> >>> 70: \ by code in modules for which native access is not >>> explicitly enabled.\n\ >>> 71: \ is one of

Re: RFR: 8330465: Stable Values and Collections (Internal) [v5]

On Thu, 16 May 2024 11:13:24 GMT, Chen Liang wrote: >> It seems reasonable to assume `null` values are not constant-folded. For >> straight-out-of-the-box usage, there is no apparent significant difference >> as indicated by a new benchmark I just added: >> >> >> Benchmark

Re: RFR: 8330465: Stable Values and Collections (Internal) [v6]

On Thu, 16 May 2024 07:29:21 GMT, Per Minborg wrote: >> # Stable Values & Collections (Internal) >> >> ## Summary >> This PR proposes to introduce an internal _Stable Values & Collections_ API, >> which provides immutable value holders where elements are initialized _at >> most once_. Stable

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v6]

On Thu, 16 May 2024 11:42:48 GMT, Jaikiran Pai wrote: > Hello Maurizio, in the current mainline, we have code in `LauncherHelper` > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/LauncherHelper.java#L636 > where we enable native access to all unnamed

Re: RFR: 8330465: Stable Values and Collections (Internal) [v12]

> # Stable Values & Collections (Internal) > > ## Summary > This PR proposes to introduce an internal _Stable Values & Collections_ API, > which provides immutable value holders where elements are initialized _at > most once_. Stable Values & Collections offer the performance and safety >

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v6]

On Wed, 15 May 2024 16:08:17 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and

Re: RFR: 8331865: Consolidate size and alignment checks in LayoutPath

On Wed, 15 May 2024 15:43:45 GMT, Maurizio Cimadamore wrote: > When creating a nested memory access var handle, we ensure that the segment > is accessed at the correct alignment for the root layout being accessed. But > we do not ensure that the segment has at least the size of the accessed

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v6]

On Wed, 15 May 2024 16:08:17 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and

Re: RFR: 8330465: Stable Values and Collections (Internal) [v5]

On Thu, 16 May 2024 07:11:20 GMT, Per Minborg wrote: >> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java >> line 139: >> >>> 137: case NON_NULL: { return valueVolatile(); } >>> 138: case ERROR:{ throw StableUtil.error(this); } >>> 139:

Re: RFR: 8330465: Stable Values and Collections (Internal) [v5]

On Thu, 16 May 2024 06:54:26 GMT, Per Minborg wrote: >> Maybe the `state == NULL` check should be moved before `v != null`, as the  >> **JIT** doesn’t constant‑fold `null` [`@Stable`] values: >>

Re: RFR: 8331865: Consolidate size and alignment checks in LayoutPath

On Thu, 16 May 2024 10:54:15 GMT, Maurizio Cimadamore wrote: >> When creating a nested memory access var handle, we ensure that the segment >> is accessed at the correct alignment for the root layout being accessed. But >> we do not ensure that the segment has at least the size of the

Re: RFR: 8331865: Consolidate size and alignment checks in LayoutPath

On Wed, 15 May 2024 15:43:45 GMT, Maurizio Cimadamore wrote: > When creating a nested memory access var handle, we ensure that the segment > is accessed at the correct alignment for the root layout being accessed. But > we do not ensure that the segment has at least the size of the accessed

RFR: 8331865: Consolidate size and alignment checks in LayoutPath

When creating a nested memory access var handle, we ensure that the segment is accessed at the correct alignment for the root layout being accessed. But we do not ensure that the segment has at least the size of the accessed root layout. Example: MemoryLayout LAYOUT = sequenceLayout(2,

Re: RFR: 8330465: Stable Values and Collections (Internal) [v11]

> # Stable Values & Collections (Internal) > > ## Summary > This PR proposes to introduce an internal _Stable Values & Collections_ API, > which provides immutable value holders where elements are initialized _at > most once_. Stable Values & Collections offer the performance and safety >

Re: RFR: 8332086: Remove the usage of ServiceLoader in j.u.r.RandomGeneratorFactory [v5]

On Wed, 15 May 2024 09:51:23 GMT, Raffaello Giulietti wrote: >> All random number generator algorithms are implemented in module >> `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` >> is no longer needed. > > Raffaello Giulietti has updated the pull request

Re: RFR: 8332086: Remove the usage of ServiceLoader in j.u.r.RandomGeneratorFactory [v5]

On Wed, 15 May 2024 09:51:23 GMT, Raffaello Giulietti wrote: >> All random number generator algorithms are implemented in module >> `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` >> is no longer needed. > > Raffaello Giulietti has updated the pull request

Integrated: 8332101: Add an `@since` to `StandardOperation:REMOVE` in `jdk.dynalink`

On Sat, 11 May 2024 15:39:04 GMT, Nizar Benalla wrote: > Code cleanup, please review this simple change. I split my changes into 1 PR > per module to make reviewing simpler. > To help with the review, this was added back in > https://bugs.openjdk.org/browse/JDK-8191905 > TIA This pull request

Re: RFR: 8330465: Stable Values and Collections (Internal) [v10]

On Thu, 16 May 2024 09:01:22 GMT, Per Minborg wrote: >> # Stable Values & Collections (Internal) >> >> ## Summary >> This PR proposes to introduce an internal _Stable Values & Collections_ API, >> which provides immutable value holders where elements are initialized _at >> most once_. Stable

Re: RFR: 8332086: Remove the usage of ServiceLoader in j.u.r.RandomGeneratorFactory [v5]

On Wed, 15 May 2024 09:51:23 GMT, Raffaello Giulietti wrote: >> All random number generator algorithms are implemented in module >> `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` >> is no longer needed. > > Raffaello Giulietti has updated the pull request

Re: RFR: 8322732: ForkJoinPool may underutilize cores in async mode [v2]

On Sun, 12 May 2024 13:12:24 GMT, Doug Lea wrote: >> This set of changes address causes of poor utilization with small numbers of >> cores due to overly aggressive contention avoidance. A number of further >> adjustments were needed to still avoid most contention effects in >> deployments

Re: RFR: 8332101: Add an `@since` to `StandardOperation:REMOVE` in `jdk.dynalink`

On Sat, 11 May 2024 15:39:04 GMT, Nizar Benalla wrote: > Code cleanup, please review this simple change. I split my changes into 1 PR > per module to make reviewing simpler. > To help with the review, this was added back in > https://bugs.openjdk.org/browse/JDK-8191905 > TIA The change looks

Re: [External] : Re: Generalizing binary search

Since you replied to my message rather than to David's, I assume you had seen the [issue] I linked. Masquerading an arbitrary binary search as a binary search on a list -- a random access list, as Louis noted correctly -- can do something for you: class Element implements Comparable {

Re: RFR: 8330465: Stable Values and Collections (Internal) [v10]

> # Stable Values & Collections (Internal) > > ## Summary > This PR proposes to introduce an internal _Stable Values & Collections_ API, > which provides immutable value holders where elements are initialized _at > most once_. Stable Values & Collections offer the performance and safety >

Re: RFR: 8331670: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal [v2]

On Thu, 16 May 2024 07:14:53 GMT, Alan Bateman wrote: >> This is the implementation changes for JEP 471. >> >> The methods in sun.misc.Unsafe for on-heap and off-heap access are >> deprecated for removal. This means a removal warning at compile time. No >> methods have been removed. A

Re: RFR: 8330465: Stable Values and Collections (Internal) [v5]

On Wed, 15 May 2024 16:26:57 GMT, Chen Liang wrote: >> Per Minborg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Switch to monomorphic StableValue and use lazy arrays > >

Re: RFR: 8330465: Stable Values and Collections (Internal) [v4]

On Wed, 15 May 2024 15:49:22 GMT, Chen Liang wrote: >> Maybe there is a better home for this? > > I don't think we should publish this API; this will soon be phased out by > strict final fields (written only before super constructor calls) introduced > by Valhalla, as strict final fields are

Re: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis [v2]

On Wed, 15 May 2024 13:32:38 GMT, Magnus Ihse Bursie wrote: > Hi Julian, sorry for not getting back to you. > > The problem from my PoV is that this is a very large and intrusive patch in > the build of the actual product, for a claimed problem in the tangential > hsdis library. I have not

Re: RFR: 8330465: Stable Values and Collections (Internal) [v5]

On Wed, 15 May 2024 16:29:08 GMT, Chen Liang wrote: >> Per Minborg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Switch to monomorphic StableValue and use lazy arrays > >

Re: RFR: 8330465: Stable Values and Collections (Internal) [v9]

> # Stable Values & Collections (Internal) > > ## Summary > This PR proposes to introduce an internal _Stable Values & Collections_ API, > which provides immutable value holders where elements are initialized _at > most once_. Stable Values & Collections offer the performance and safety >

Re: RFR: 8331670: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal [v2]

On Thu, 16 May 2024 07:14:53 GMT, Alan Bateman wrote: >> This is the implementation changes for JEP 471. >> >> The methods in sun.misc.Unsafe for on-heap and off-heap access are >> deprecated for removal. This means a removal warning at compile time. No >> methods have been removed. A

Re: RFR: 8330465: Stable Values and Collections (Internal) [v5]

On Wed, 15 May 2024 16:31:15 GMT, Chen Liang wrote: >> Per Minborg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Switch to monomorphic StableValue and use lazy arrays > >

Re: RFR: 8330465: Stable Values and Collections (Internal) [v8]

> # Stable Values & Collections (Internal) > > ## Summary > This PR proposes to introduce an internal _Stable Values & Collections_ API, > which provides immutable value holders where elements are initialized _at > most once_. Stable Values & Collections offer the performance and safety >

Re: RFR: 8330465: Stable Values and Collections (Internal) [v5]

On Wed, 15 May 2024 19:07:26 GMT, Chen Liang wrote: >> Yes, according to the `@Stable` annotation’s JavaDoc, this is UB: >> https://github.com/openjdk/jdk/blob/8a4315f833f3700075d65fae6bc566011c837c07/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java#L74-L80 > > Fyi what usually

Re: RFR: 8330465: Stable Values and Collections (Internal) [v7]

> # Stable Values & Collections (Internal) > > ## Summary > This PR proposes to introduce an internal _Stable Values & Collections_ API, > which provides immutable value holders where elements are initialized _at > most once_. Stable Values & Collections offer the performance and safety >

Integrated: 8321622: ClassFile.verify(byte[] bytes) throws unexpected ConstantPoolException, IAE

On Thu, 16 May 2024 06:44:29 GMT, Adam Sotona wrote: > Class-File API `VerifierImpl` contains debugging stack trace print causing > unexpected output and confusion in specific verification cases. > > This patch removes the stack trace print. > > Please review. > > Thanks, > Adam This pull

Re: RFR: 8321622: ClassFile.verify(byte[] bytes) throws unexpected ConstantPoolException, IAE [v2]

On Thu, 16 May 2024 07:28:20 GMT, Adam Sotona wrote: >> Class-File API `VerifierImpl` contains debugging stack trace print causing >> unexpected output and confusion in specific verification cases. >> >> This patch removes the stack trace print. >> >> Please review. >> >> Thanks, >> Adam > >

Re: RFR: 8330465: Stable Values and Collections (Internal) [v6]

> # Stable Values & Collections (Internal) > > ## Summary > This PR proposes to introduce an internal _Stable Values & Collections_ API, > which provides immutable value holders where elements are initialized _at > most once_. Stable Values & Collections offer the performance and safety >

Re: RFR: 8321622: ClassFile.verify(byte[] bytes) throws unexpected ConstantPoolException, IAE [v2]

> Class-File API `VerifierImpl` contains debugging stack trace print causing > unexpected output and confusion in specific verification cases. > > This patch removes the stack trace print. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one

Re: RFR: 8330465: Stable Values and Collections (Internal) [v5]

On Thu, 16 May 2024 07:19:54 GMT, Per Minborg wrote: >> src/java.base/share/classes/jdk/internal/lang/StableValue.java line 384: >> >>> 382: * @param the memoized type >>> 383: */ >>> 384: static Supplier ofSupplier(Supplier original) { >> >> `ofSupplier` sounds like this

Re: RFR: 8330465: Stable Values and Collections (Internal) [v5]

On Wed, 15 May 2024 16:25:04 GMT, Chen Liang wrote: >> Per Minborg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Switch to monomorphic StableValue and use lazy arrays > > src/java.base/share/classes/jdk/internal/lang/StableValue.java

Re: RFR: 8330465: Stable Values and Collections (Internal) [v5]

On Wed, 15 May 2024 16:19:05 GMT, Chen Liang wrote: >> Per Minborg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Switch to monomorphic StableValue and use lazy arrays > >

Re: RFR: 8330465: Stable Values and Collections (Internal) [v5]

On Wed, 15 May 2024 16:11:56 GMT, Chen Liang wrote: >> Per Minborg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Switch to monomorphic StableValue and use lazy arrays > >

Re: RFR: 8331670: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal [v2]

On Wed, 15 May 2024 10:21:14 GMT, Maurizio Cimadamore wrote: > I believe we already disable a bunch of warnings from the command line when > compiling these benchmarks. Perhaps we can just tweak the build script in a > similar way and avoid the changes to the sources? E.g. > > ``` >

Re: RFR: 8331670: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal [v2]

> This is the implementation changes for JEP 471. > > The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated > for removal. This means a removal warning at compile time. No methods have > been removed. A deprecated message is added to each of the methods but > unlikely

Re: RFR: 8321622: ClassFile.verify(byte[] bytes) throws unexpected ConstantPoolException, IAE

On Thu, 16 May 2024 06:44:29 GMT, Adam Sotona wrote: > Class-File API `VerifierImpl` contains debugging stack trace print causing > unexpected output and confusion in specific verification cases. > > This patch removes the stack trace print. > > Please review. > > Thanks, > Adam Hello Adam,

Re: RFR: 8330465: Stable Values and Collections (Internal) [v5]

On Wed, 15 May 2024 18:45:16 GMT, ExE Boss wrote: >> src/java.base/share/classes/jdk/internal/lang/stable/StableValueImpl.java >> line 104: >> >>> 102: // Optimistically try plain semantics first >>> 103: final V v = value; >>> 104: if (v != null) { >> >> If `value ==

RFR: 8321622: ClassFile.verify(byte[] bytes) throws unexpected ConstantPoolException, IAE

Class-File API `VerifierImpl` contains debugging stack trace print causing unexpected output and confusion in specific verification cases. This patch removes the stack trace print. Please review. Thanks, Adam - Commit messages: - 8321622: ClassFile.verify(byte[] bytes) throws