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

On Wed, 22 May 2024 21:42:14 GMT, Kevin Rushforth wrote: > Further, I confirm that if I pass that option to jlink or jpackage when > creating a custom runtime, there is no warning. Great! What about jpackage without a custom runtime, wondering if --java-options can be tested. - P

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

On Tue, 21 May 2024 07:26:17 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 deprecat

Re: RFR: 8242888: Convert dynamic proxy to hidden classes

On Thu, 23 May 2024 03:28:30 GMT, Chen Liang wrote: > Please review this change that convert dynamic proxies implementations to > hidden classes, intended to target JDK 24. > > Summary: > 1. Adds new implementation while preserving the old implementation behind > `-Djdk.reflect.useLegacyProxyI

Re: RFR: 8331879: Clean up non-standard use of /// comments in `java.base`

On Tue, 7 May 2024 22:23:48 GMT, Jonathan Gibbons wrote: > A long vertical series of lines beginning /// is replaced by lines beginning > //|. This one looks unusual when it's just one line, I could imagine deleting the "|" in these cases. - PR Comment: https://git.openjdk.org/jd

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

On 5/22/2024 11:19 AM, Aman Sharma wrote: Hi, [snip] Notice the difference in the order of fields and `helpCommand` method is mapped to a different field name in both classes. This happens because the method array returned by `getMethods` is not sorted in any particular order

RFR: 8242888: Convert dynamic proxy to hidden classes

Please review this change that convert dynamic proxies implementations to hidden classes, intended to target JDK 24. Summary: 1. Adds new implementation while preserving the old implementation behind `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues. 2. ClassLoader.d

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

> 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: 8320448: Accelerate IndexOf using AVX2 [v29]

> 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: 8320575: generic type information lost on mandated parameters of record's compact constructors [v7]

On Thu, 23 May 2024 01:05:07 GMT, Chen Liang wrote: > > As a general comment, please update all the links to "mandated" so that the > > text "implicitly declared" get linked to the MANDATED enum constant. > > Should we update the API specification for `Parameter::isImplicit`, which > checks th

Re: RFR: 8320575: generic type information lost on mandated parameters of record's compact constructors [v7]

On Thu, 23 May 2024 00:58:14 GMT, Joe Darcy wrote: > As a general comment, please update all the links to "mandated" so that the > text "implicitly declared" get linked to the MANDATED enum constant. Should we update the API specification for `Parameter::isImplicit`, which checks the "mandated

Re: RFR: 8332490: JMH org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead OOM [v2]

On Wed, 22 May 2024 07:49:27 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change for addressing >> https://bugs.openjdk.org/browse/JDK-8332490? >> >> The jmh test opens a `InflaterInputStream`, reads the stream contents, but >> then doesn't close the stream. This can

Integrated: 8332490: JMH org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead OOM

On Wed, 22 May 2024 05:16:42 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change for addressing > https://bugs.openjdk.org/browse/JDK-8332490? > > The jmh test opens a `InflaterInputStream`, reads the stream contents, but > then doesn't close the stream. This can lead

Re: RFR: 8320575: generic type information lost on mandated parameters of record's compact constructors [v7]

On Tue, 12 Dec 2023 22:21:29 GMT, Joe Darcy wrote: >> Vicente Romero has updated the pull request incrementally with one >> additional commit since the last revision: >> >> fixing comment > > As the core reflection code will encounter record classes compiled before and > after the javac code

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

On Wed, 22 May 2024 21:23:04 GMT, Sunmisc Unsafe wrote: >> After recheckiing, the best policy is to leave internal queues the same, but >> initialize external queues larger. > > Probably a misplaced post again, but why can't you allocate an array of arrays > where the outer array is 30 > and the

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

On Thu, 16 May 2024 10:29:48 GMT, Sunmisc Unsafe wrote: >> Doug Lea has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Address review comments > > Maybe I don't quite understand, or I don't have proof, But wouldn't it be > better if invoke

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

On Wed, 22 May 2024 15:51:05 GMT, Viktor Klang wrote: >> Doug Lea 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 36 additional commits >> since

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

On Wed, 22 May 2024 15:45:43 GMT, Viktor Klang wrote: >> Doug Lea 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 36 additional commits >> since

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]

On Wed, 22 May 2024 14:47:43 GMT, Yudi Zheng wrote: >> Moving array construction within BigInteger.implMultiplyToLen intrinsic >> candidate to its caller simplifies the intrinsic implementation in JIT >> compiler. > > Yudi Zheng has updated the pull request incrementally with one additional >

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

> 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: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v8]

On Fri, 17 May 2024 13:38:25 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 `Runtime::loa

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

On Tue, 21 May 2024 10:20:27 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: 8322732: ForkJoinPool may underutilize cores in async mode [v3]

On Sun, 12 May 2024 13:05:48 GMT, Doug Lea wrote: >> The goal is to reduce the worst form of contention: when queue arrays are >> laid out adjacently in memory. Increasing sizes has some impact but with >> diminishing returns. Thanks for the comment as a reminder that I haven't >> rechecked th

Re: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a shutdown hook [v8]

On Wed, 22 May 2024 21:06:11 GMT, Pavel Rappo wrote: > Okay, but can we call it a best-effort attempt to restore the echo state? I > guess, it is a judgement call. That would be fair, and exactly what I am aiming for, considering we can do nothing for the `halt()` case. - PR Comm

Re: RFR: 8332490: JMH org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead OOM [v2]

On Wed, 22 May 2024 07:49:27 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change for addressing >> https://bugs.openjdk.org/browse/JDK-8332490? >> >> The jmh test opens a `InflaterInputStream`, reads the stream contents, but >> then doesn't close the stream. This can

Re: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a shutdown hook [v8]

On Wed, 22 May 2024 19:32:07 GMT, Naoto Sato wrote: > > I might be confused, but what if the shutdown hook completes and then some > > application thread enters `readPassword`. If that thread manages to turn > > off echo before all other shutdown hooks complete, it might never execute > > `fin

Re: RFR: 8331879: Clean up non-standard use of /// comments in `java.base`

On Tue, 7 May 2024 22:23:48 GMT, Jonathan Gibbons wrote: > With the advent of JEP 467, `///` comments may be treated as documentation > comments, and may be subject to the recently new `javac` warning about > "dangling doc comments" in unexpected places. > > In keeping with the policy to keep

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]

On Wed, 22 May 2024 14:28:41 GMT, Yudi Zheng wrote: >> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4693: >> >>> 4691: const Register xlen = r1; >>> 4692: const Register z = r2; >>> 4693: const Register zlen = r3; >> >> LibraryCallKit::inline_squareToLen() is still c

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

Hi Aman, Even though the specification says "not in any particular order," the getInterfaces and getMethods actually return an ordered array, in the order these methods/interfaces are declared in their class files. I believe you are decompiling the proxy classes generated by an older version of th

Re: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a shutdown hook [v8]

On Wed, 22 May 2024 18:35:40 GMT, Pavel Rappo wrote: > I might be confused, but what if the shutdown hook completes and then some > application thread enters `readPassword`. If that thread manages to turn off > echo before all other shutdown hooks complete, it might never execute > `finally`,

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

> 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: 8320448: Accelerate IndexOf using AVX2 [v26]

> 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: stack overflow in regex engine

Makes sense, thanks! From: Philip Race Sent: Wednesday, May 22, 2024 2:41 PM To: Yagnatinsky, Mark : IT (NYK) ; core-libs-dev@openjdk.org Subject: Re: stack overflow in regex engine CAUTION: This email originated from outside our organisation - philip.r...@oracle.com

Re: stack overflow in regex engine

On 5/22/24 10:51 AM, mark.yagnatin...@barclays.com wrote: Ah, didn’t realize P4 is default; that makes sense. So I should not even be trying to derive omens from that. So I guess only the assignee would know whether or not the status is closer to “I was going to work on that next week” ve

Re: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a shutdown hook [v8]

On Wed, 22 May 2024 17:20:02 GMT, Naoto Sato wrote: > Hi Pavel, > > > If I read > > [this](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html#shutdown) > > correctly, due to the mechanics of JVM exit, we simply don't know which > > thread finishes first: a thr

Re: RFR: 8331196: vector api: Remove unnecessary index check in Byte/ShortVector.fromArray/fromArray0Template

On Fri, 26 Apr 2024 14:06:02 GMT, Hamlin Li wrote: > Hi, > Can you help to review this simple patch? > Some index check in Byte/ShortVector.fromArray/fromArray0Template seems not > necessary, could be removed. > Thanks The intrinsic implementation will not perform bounds checks. I think what yo

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

Hi, Another thing I wanted to look into in this thread was the order of fields in the Proxy classes generated. They are also based on the a number. The same proxy classes across different executions can have random order of `Method` fields and the methods could be mapped to different field nam

RE: stack overflow in regex engine

Ah, didn't realize P4 is default; that makes sense. So I should not even be trying to derive omens from that. So I guess only the assignee would know whether or not the status is closer to "I was going to work on that next week" versus "I totally forgot about that thing, and am about to forget abou

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

> 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: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a shutdown hook [v8]

On Tue, 21 May 2024 22:51:14 GMT, Naoto Sato wrote: >> Making sure `restoreEcho` correctly reflects the state in the shutdown >> thread, which differs from the application's thread that issues the >> `readPassword()` method. > > Naoto Sato has updated the pull request incrementally with one add

Re: RFR: 8331196: vector api: Remove unnecessary index check in Byte/ShortVector.fromArray/fromArray0Template

On Fri, 26 Apr 2024 14:06:02 GMT, Hamlin Li wrote: > Hi, > Can you help to review this simple patch? > Some index check in Byte/ShortVector.fromArray/fromArray0Template seems not > necessary, could be removed. > Thanks In one side, yes, there is a gap in the tests. In another side, I wonder if

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

> 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: 8332340: Add JavacBench as a test case for CDS [v3]

On Tue, 21 May 2024 21:03:20 GMT, Matias Saavedra Silva wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> @calvinccheung comments > > test/lib/jdk/test/lib/cds/CDSAppTester.java line 147: > >> 145: } >> 146: >> 147

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

> 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) r

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

On Wed, 22 May 2024 16:25:24 GMT, Scott Gibbons wrote: >> 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: >> >> >> Benchmark

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

> 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

Integrated: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic

On Tue, 2 Apr 2024 15:42:05 GMT, Volodymyr Paprotski wrote: > Performance. Before: > > Benchmark(algorithm) (dataSize) (keyLength) > (provider) Mode Cnt ScoreError Units > SignatureBench.ECDSA.signSHA256withECDSA1024 256 >

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

> 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: 8322732: ForkJoinPool may underutilize cores in async mode [v3]

On Wed, 22 May 2024 15:32:42 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 with

Re: RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a shutdown hook [v8]

On Tue, 21 May 2024 22:51:14 GMT, Naoto Sato wrote: >> Making sure `restoreEcho` correctly reflects the state in the shutdown >> thread, which differs from the application's thread that issues the >> `readPassword()` method. > > Naoto Sato has updated the pull request incrementally with one add

Re: stack overflow in regex engine

P4 is the default JBS priority, so sometimes it just means no one figured out the true priority. But in general P4 bugs could be open for years, or even never get fixed. The priority is also partially an assessment of where it falls as a priority for the JDK developers. A user of JDK may have a

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

On Wed, 22 May 2024 15:32:42 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 with

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

On Wed, 22 May 2024 15:32:42 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 with

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

> 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 > with large numbers of cores Doug Lea has updated the pull r

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]

On Wed, 22 May 2024 14:47:43 GMT, Yudi Zheng wrote: >> Moving array construction within BigInteger.implMultiplyToLen intrinsic >> candidate to its caller simplifies the intrinsic implementation in JIT >> compiler. > > Yudi Zheng has updated the pull request incrementally with one additional >

Re: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null

On Tue, 21 May 2024 14:28:38 GMT, Matthias Baesken wrote: > When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing > jtreg tests afterwards I run into this error : > > /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: > null pointer passed as arg

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

On Fri, 17 May 2024 22:37:13 GMT, Sandhya Viswanathan wrote: >> Not sure what you mean here. I *think* you mean that hsLength is not the >> length of the remaining bytes in the haystack, but the actual length. There >> may be an issue if that is correct, right? I'll investigate. > > Yes, th

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

> 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 74 commits: - . - . - Merge branch 'jdk-8331560-cgroup-contr

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

On Mon, 15 Jan 2024 13:30:42 GMT, Andrey Turbanov 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 ind

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

On Wed, 15 May 2024 19:18:27 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 > > test/jdk/java/lang/StringBuffer/IndexOf.java line 54: > >> 52: // for

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

On Tue, 9 Jan 2024 15:14:41 GMT, Emanuel Peter 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 21 commits: >> >> - Merge branch 'openjdk:master' into indexof >> - Addressing review comments. >> - Fix for

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

On Mon, 22 Jan 2024 07:08:31 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 505: >> >>> 503: __ cmpb(Address(rbx, r15, Address::times_1, -0xa), rax); >>> 504: __ jne(L_top_loop_1); >>> 505: __ jmp(L_0x406019); >> >> Instead of having special ha

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

On Mon, 8 Jan 2024 10:32:51 GMT, Jatin Bhateja wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Addressing review comments. > > src/hotspot/share/opto/library_call.cpp line 1273: > >> 1271: Node* result = nullpt

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

On Tue, 16 Jan 2024 13:26:15 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 index

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

On Mon, 6 May 2024 23:19:07 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/stubGenerator_x86_64_string.cpp line 329: > >> 327:

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

On Mon, 26 Feb 2024 14:50:30 GMT, Jatin Bhateja wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Addressed some review coments; replaced hard-coded registers with >> descriptive names. > > src/hotspot/cpu/x86/stub

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]

On Wed, 17 Apr 2024 20:04:44 GMT, Dean Long wrote: >> Yudi Zheng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> address comment. > > src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6662: > >> 6660: push(tmp5); >> 6661: >> 6662: pu

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v6]

> Moving array construction within BigInteger.implMultiplyToLen intrinsic > candidate to its caller simplifies the intrinsic implementation in JIT > compiler. Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision: address comments.

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v3]

On Mon, 20 May 2024 10:41:36 GMT, Bhavana Kilambi wrote: >> @dafedafe @dean-long please take a look and let me know if there are further >> issues, thanks! > > Hi @mur47x111, do you happen to have any performance results with this patch? @Bhavana-Kilambi the performance result for x86 is at ht

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]

On Wed, 17 Apr 2024 19:33:01 GMT, Dean Long wrote: >> Yudi Zheng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> address comment. > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4670: > >> 4668: const Register tmp5 = r15

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

On Tue, 9 Jan 2024 15:06:10 GMT, Emanuel Peter 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 21 commits: >> >> - Merge branch 'openjdk:master' into indexof >> - Addressing review comments. >> - Fix for

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

On Tue, 21 May 2024 17:41:46 GMT, Volodymyr Paprotski wrote: >> Performance. Before: >> >> Benchmark(algorithm) (dataSize) (keyLength) >> (provider) Mode Cnt ScoreError Units >> SignatureBench.ECDSA.signSHA256withECDSA1024 256

Re: RFR: 8305457: Implement java.io.IO [v12]

> Please review this PR which introduces the `java.io.IO` top-level class and > three methods to `java.io.Console` for [Implicitly Declared Classes and > Instance Main Methods (Third Preview)]. > > This PR has been obtained as `git merge --squash` of a now obsolete [draft > PR]. > > [Implicitl

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

Hi Chen, That's clear. Thanks for letting me know. I guess then Project Leyden is working on naming the hidden classes deterministically to achieve their goals. Regards, Aman Sharma PhD Student KTH Royal Institute of Technology School

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

On Tue, 21 May 2024 17:41:46 GMT, Volodymyr Paprotski wrote: >> Performance. Before: >> >> Benchmark(algorithm) (dataSize) (keyLength) >> (provider) Mode Cnt ScoreError Units >> SignatureBench.ECDSA.signSHA256withECDSA1024 256

Re: RFR: 8331051: Add an `@since` checker test for `java.base` module [v7]

> This checker checks the values of the `@since` tag found in the documentation > comment for an element against the release in which the element first > appeared. > > Real since value of an API element is computed as the oldest release in which > the given API element was introduced. That is:

Re: RFR: 8332614: Type-checked ConstantPool.entryByIndex and ClassReader.readEntryOrNull [v2]

> I propose to add type-checked ConstantPool.entryByIndex and > ClassReader.readEntryOrNull taking an extra Class parameter, which throws > ConstantPoolException instead of ClassCastException on type mismatch, which > can happen to malformed ClassFiles. > > Requesting a review from @asotona. Th

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

On Wed, 22 May 2024 12:25:09 GMT, Severin Gehwolf wrote: >> I did some testing and it turns out that this is indeed not checked. I >> believe this is a miss in the Skara reimplementation of jcheck. I've opened >> https://bugs.openjdk.org/browse/SKARA-2265 to track this. >> >> Nevertheless, it

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

> Please review this patch which adds a jlink mode to the JDK which doesn't > need the packaged modules being present. A.k.a run-time image based jlink. > Fundamentally this patch adds an option to use `jlink` even though your JDK > install might not come with the packaged modules (directory `jm

RE: do I need to subscribe to this list in order to post?

Thanks!! From: David Alayachew Sent: Wednesday, May 22, 2024 8:54 AM To: Yagnatinsky, Mark : IT (NYK) Cc: core-libs-dev@openjdk.org Subject: Re: do I need to subscribe to this list in order to post? CAUTION: This email originated from outside our organisation - davidalayac...@gmail.com

Re: do I need to subscribe to this list in order to post?

Nope. We can see your message. You only subscribe if you want to follow along with the general discussions that you are not explicitly invited to. On Tue, May 21, 2024 at 7:14 PM wrote: > > > This message is for information purposes only. It is not a recommendation, > advice, offer or solicitati

Re: RFR: 8305457: Implement java.io.IO [v11]

> Please review this PR which introduces the `java.io.IO` top-level class and > three methods to `java.io.Console` for [Implicitly Declared Classes and > Instance Main Methods (Third Preview)]. > > This PR has been obtained as `git merge --squash` of a now obsolete [draft > PR]. > > [Implicitl

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

On Wed, 22 May 2024 08:07:59 GMT, Magnus Ihse Bursie wrote: >> Actually, this is a bit strange. I thought jcheck would look for missing >> newline at EOF, and that properties files were included in the check >> nowadays. I'll need to check this out. > > I did some testing and it turns out that

Re: GC triggered before VM initialization completed

Hi Lorris, This mailing list is for Java's core libraries' development. Your issue is a support request and is not related to Java's core libraries in any way, thus I recommend you look for tech support or create/find an issue at bugs.java.com. Regards, Chen On Wed, May 22, 2024 at 7:16 AM Lorris

GC triggered before VM initialization completed

Hello, I get an error when I try to run the java or javac commands on any file. The exact message is the following: Error occurred during initialization of VM GC triggered before VM initialization completed. Try increasing NewSize, current value 1331K. I tried to increase the size up to 6G but

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

Hi Aman, We have tried defining Proxy as hidden classes; a previous attempt was on hold because of issues with serialization. Otherwise, Proxies work great as hidden classes. Chen On Mon, May 20, 2024 at 7:56 AM Aman Sharma wrote: > Hi David, > > > > I would not expect any class load > events.

Re: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null

On Wed, 22 May 2024 07:38:07 GMT, Magnus Ihse Bursie wrote: > How come `c->pdir` can be null? Is it if `sp.dirlen` is 0? I added a bit of tracing output and get Attention c->pdir is null; sp.dirlen is 0 So yes sp.dirlen is also 0 . - PR Comment: https://git.openjdk.org/jdk/p

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

On Fri, 17 May 2024 13:38:25 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 `Runtime::loa

Re: RFR: 8330542: Add jaxp-strict.properties in preparation for a stricter default configuration [v12]

On Tue, 21 May 2024 20:28:37 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 any

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

On Wed, 22 May 2024 07:44:08 GMT, Magnus Ihse Bursie wrote: >> ... still missing... > > Actually, this is a bit strange. I thought jcheck would look for missing > newline at EOF, and that properties files were included in the check > nowadays. I'll need to check this out. I did some testing an

Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v22]

On Tue, 21 May 2024 16:59:38 GMT, Brent Christian wrote: > Indeed - can't move forward without a CSR. Also wouldn't mind more reviewer > ✔️s. 😉 I can do that. One other thing to do is to rebase the changes, it looks like this branch is 6 months behind main line. - PR Comment: ht

Re: RFR: 8332490: JMH org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead OOM [v2]

On Wed, 22 May 2024 07:28:04 GMT, Claes Redestad wrote: > LGTM - feel free to add a comment that closing the InflaterInputStream has no > effect on the underlying stream deflated. Hello Claes, I've updated the PR to include a comment. - PR Comment: https://git.openjdk.org/jdk/pull

Re: RFR: 8332490: JMH org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead OOM [v2]

On Wed, 22 May 2024 07:27:14 GMT, Claes Redestad wrote: >> test/micro/org/openjdk/bench/java/util/zip/InflaterInputStreams.java line >> 113: >> >>> 111: try (InflaterInputStream iis = new >>> InflaterInputStream(deflated)) { >>> 112: while (iis.read(inflated, 0, inflated.le

Re: RFR: 8332490: JMH org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead OOM [v2]

> Can I please get a review of this test-only change for addressing > https://bugs.openjdk.org/browse/JDK-8332490? > > The jmh test opens a `InflaterInputStream`, reads the stream contents, but > then doesn't close the stream. This can lead to resource leak which can then > cause OOM as noted i

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

On Wed, 22 May 2024 07:42:39 GMT, Magnus Ihse Bursie wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line >> 165: >> >>> 163: >>> 164: runtime.link.info=Linking based on the current run-time image. >>> 165: runtime.link.jprt.path.extra=(run-time image) >> >> M

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

On Thu, 4 Apr 2024 20:52:59 GMT, Magnus Ihse Bursie wrote: >> Severin Gehwolf has updated the pull request incrementally with three >> additional commits since the last revision: >> >> - Use shorter name for the build tool >> - Review feedback from Erik J. >> - Remove dependency on CDS which

Re: RFR: 8332589: ubsan: unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: null pointer passed as argument 2, which is declared to never be null

On Tue, 21 May 2024 14:28:38 GMT, Matthias Baesken wrote: > When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing > jtreg tests afterwards I run into this error : > > /jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error: > null pointer passed as arg

Re: RFR: 8332490: JMH org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead OOM

On Wed, 22 May 2024 07:20:04 GMT, Alan Bateman wrote: >> Can I please get a review of this test-only change for addressing >> https://bugs.openjdk.org/browse/JDK-8332490? >> >> The jmh test opens a `InflaterInputStream`, reads the stream contents, but >> then doesn't close the stream. This can

Re: RFR: 8332490: JMH org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead OOM

On Wed, 22 May 2024 05:16:42 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change for addressing > https://bugs.openjdk.org/browse/JDK-8332490? > > The jmh test opens a `InflaterInputStream`, reads the stream contents, but > then doesn't close the stream. This can lead

Re: RFR: 8332490: JMH org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead OOM

On Wed, 22 May 2024 05:16:42 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change for addressing > https://bugs.openjdk.org/browse/JDK-8332490? > > The jmh test opens a `InflaterInputStream`, reads the stream contents, but > then doesn't close the stream. This can lead

Withdrawn: 8323760: clarify specification of Map::putIfAbsent return value

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

  1   2   >