Re: RFR: 8332494: java/util/zip/EntryCount64k.java failing with java.lang.RuntimeException: '\\A\\Z' missing from stderr [v2]

2024-05-20 Thread David Holmes
On Mon, 20 May 2024 11:41:48 GMT, Axel Boldt-Christmas wrote: >> test/lib/jdk/test/lib/process/OutputAnalyzer.java line 691: >> >>> 689: * @throws RuntimeException If the pattern was not found >>> 690: */ >>> 691: public OutputAnalyzer >>>

Re: RFR: 8332494: java/util/zip/EntryCount64k.java failing with java.lang.RuntimeException: '\\A\\Z' missing from stderr [v2]

2024-05-20 Thread David Holmes
On Mon, 20 May 2024 07:27:19 GMT, Axel Boldt-Christmas wrote: >> Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring >> deprecated warnings. Testing non-generational ZGC requires the use of a >> deprecated option. > > Axel Boldt-Christmas has updated the pull request

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

2024-05-20 Thread David Holmes
ofile/amansha> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/ <https://algomaster99.github.io/> ---- *From:* David Holmes *Sent:* Monday, May 20, 2024 2:59:17 AM *To:* Aman Sharma; liangchenb...@

Re: RFR: 8332494: java/util/zip/EntryCount64k.java failing with java.lang.RuntimeException: '\\A\\Z' missing from stderr [v2]

2024-05-20 Thread David Holmes
On Mon, 20 May 2024 07:27:19 GMT, Axel Boldt-Christmas wrote: >> Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring >> deprecated warnings. Testing non-generational ZGC requires the use of a >> deprecated option. > > Axel Boldt-Christmas has updated the pull request

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

2024-05-19 Thread David Holmes
On 17/05/2024 9:43 pm, Aman Sharma wrote: Hi Chen, > java.lang.invoke.LambdaForm$MH/0x0200cc000400 I do see this as output when I pass -verbose:class. However, based on my experiments, I have seen that neither an agent passed via 'javaagent' nor an agent passed via 'agentpath' is able

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

2024-05-14 Thread David Holmes
On Mon, 13 May 2024 15:32:27 GMT, Alan Bateman wrote: >> Maurizio Cimadamore has updated the pull request incrementally with three >> additional commits since the last revision: >> >> - Fix another typo >> - Fix typo >> - Add more comments > > src/hotspot/share/runtime/arguments.cpp line

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

2024-05-14 Thread David Holmes
On Tue, 14 May 2024 18:10:28 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: 8330205: Initial troff manpage generation for JDK 24

2024-05-09 Thread David Holmes
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote: > Please review this mechanical change to man pages. This PR should be > integrated after https://github.com/openjdk/jdk/pull/18787. I think we may have to restore this to a standalone start-of-release change done after the other

Re: RFR: 8331518: Tests should not use the "Classpath" exception form of the legal header

2024-05-02 Thread David Holmes
On Thu, 2 May 2024 05:57:50 GMT, Tobias Hartmann wrote: > Removed the Classpath exception from the copyright header of some compiler > tests and benchmarks. > > Thanks, > Tobias LGTM. Thanks. I'd consider this a trivial fix too. - Marked as reviewed by dholmes (Reviewer). PR

Re: RFR: 8330182: Start of release updates for JDK 24 [v2]

2024-04-23 Thread David Holmes
On Wed, 17 Apr 2024 05:43:12 GMT, Joe Darcy wrote: >> Get JDK 24 underway. > > Joe Darcy has updated the pull request incrementally with two additional > commits since the last revision: > > - Correct release date as observed in review feedback. > - Improve javadoc of class file update.

Re: RFR: 8329420: Java 22 (and 23) launcher calls default constructor although main() is static [v3]

2024-04-17 Thread David Holmes
On Wed, 17 Apr 2024 06:34:25 GMT, Jan Lahoda wrote: >> Consider code like: >> >> public class MainClass { >> public MainClass() { >> System.out.println("Constructor called!"); >> } >> public static void main() { >> System.out.println("main called!"); >> } >> } >>

Re: RFR: 8329420: Java 22 (and 23) launcher calls default constructor although main() is static [v2]

2024-04-17 Thread David Holmes
On Tue, 16 Apr 2024 13:26:43 GMT, Jan Lahoda wrote: >> src/java.base/share/native/libjli/java.c line 419: >> >>> 417: invokeInstanceMainWithArgs(JNIEnv *env, jclass mainClass, jobjectArray >>> mainArgs) { >>> 418: jmethodID constructor = (*env)->GetMethodID(env, mainClass, >>> "", "()V");

Re: RFR: 8329420: Java 22 (and 23) launcher calls default constructor although main() is static [v2]

2024-04-16 Thread David Holmes
On Mon, 15 Apr 2024 07:36:05 GMT, Jan Lahoda wrote: >> Consider code like: >> >> public class MainClass { >> public MainClass() { >> System.out.println("Constructor called!"); >> } >> public static void main() { >> System.out.println("main called!"); >> } >> } >>

Re: RFR: 8329596: Add test for virtual threads invoking synchronized native methods

2024-04-04 Thread David Holmes
On Fri, 5 Apr 2024 05:17:44 GMT, Alan Bateman wrote: >> test/jdk/java/lang/Thread/virtual/libSynchronizedNative.c line 29: >> >>> 27: Java_SynchronizedNative_runWithSynchronizedNative(JNIEnv *env, jobject >>> obj, jobject task) { >>> 28: jclass clazz = (*env)->GetObjectClass(env, obj); >>>

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v2]

2024-04-04 Thread David Holmes
On Tue, 2 Apr 2024 02:16:07 GMT, David Holmes wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use non-sse fill (old left in) > > This looks like it is still a Draft/work-in-progress.

Re: RFR: 8329596: Add test for virtual threads invoking synchronized native methods

2024-04-04 Thread David Holmes
On Wed, 3 Apr 2024 10:52:10 GMT, Alan Bateman wrote: > This is a test-only addition to add a test for virtual threads invoking a > synchronized native method and invoking a native method that enter/exits a > monitor with JNI MonitorEnter/MonitorExit. The test has been in the loom repo > for

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v2]

2024-04-01 Thread David Holmes
On Mon, 1 Apr 2024 21:30:19 GMT, Scott Gibbons wrote: >> This code makes an intrinsic stub for `Unsafe::setMemory`. See [this >> PR](https://github.com/openjdk/jdk/pull/16760) for discussion around this >> change. >> >> Overall, making this an intrinsic improves overall performance of >>

Re: RFR: 8320396: Class-File API ClassModel::verify should include checks from hotspot/share/classfile/classFileParser.cpp [v2]

2024-03-21 Thread David Holmes
On Thu, 21 Mar 2024 14:40:37 GMT, Adam Sotona wrote: >> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only >> bytecode-level class verification. >> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with >> additional class checks inspired by >>

Re: RFR: 8320396: Class-File API ClassModel::verify should include checks from hotspot/share/classfile/classFileParser.cpp [v2]

2024-03-21 Thread David Holmes
On Thu, 21 Mar 2024 14:40:37 GMT, Adam Sotona wrote: >> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only >> bytecode-level class verification. >> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with >> additional class checks inspired by >>

Re: RFR: 8320396: Class-File API ClassModel::verify should include checks from hotspot/share/classfile/classFileParser.cpp [v2]

2024-03-21 Thread David Holmes
On Thu, 21 Mar 2024 14:40:37 GMT, Adam Sotona wrote: >> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only >> bytecode-level class verification. >> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with >> additional class checks inspired by >>

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

2024-03-21 Thread David Holmes
On Thu, 21 Mar 2024 23:38:30 GMT, Brent Christian wrote: >> Classes in the `java.lang.ref` package would benefit from an update to bring >> the spec in line with how the VM already behaves. The changes would focus on >> _happens-before_ edges at some key points during reference processing. >>

Re: RFR: 8327176: UnreferencedExecutor.java can fail on libgraal with -Xcomp

2024-03-20 Thread David Holmes
On Sun, 3 Mar 2024 17:01:53 GMT, Doug Simon wrote: > The `java/util/concurrent/Executors/UnreferencedExecutor.java` test can fail > when run on libgraal and `-Xcomp` is specified. The problem is that libgraal > in `-Xcomp` temporarily causes some extra memory pressure (probably due to >

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

2024-03-19 Thread David Holmes
On Tue, 19 Mar 2024 16:38:49 GMT, Y. Srinivas Ramakrishna wrote: >> Sorry, my use of words was sloppy here. I think I did mean loose or somewhat >> informal and therefore slippery. >> >> What I was saying is that using terms such as "any continuing computation" >> doesn't make sense because

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

2024-03-18 Thread David Holmes
On Tue, 19 Mar 2024 00:40:02 GMT, Y. Srinivas Ramakrishna wrote: >> Brent Christian has updated the pull request incrementally with one >> additional commit since the last revision: >> >> further tweaks to reachability > > src/java.base/share/classes/java/lang/ref/package-info.java line

Re: RFR: 8327460: Compile tests with the same visibility rules as product code [v2]

2024-03-13 Thread David Holmes
On Tue, 12 Mar 2024 13:55:11 GMT, Magnus Ihse Bursie wrote: >> test/hotspot/jtreg/runtime/ErrorHandling/libTestDwarfHelper.h line 24: >> >>> 22: */ >>> 23: >>> 24: #include >> >> Seems unneeded. > > So what I did here was change: > > #include "jni.h" > #include > > > into > > #include

Re: RFR: 8327786: Add fluent setAccessible()

2024-03-12 Thread David Holmes
On Thu, 25 Jan 2024 21:35:45 GMT, Sergey wrote: > The feature allows to extract a private field value in a single expression, > like so: > > object.getClass().getDeclaredField().setAccessible().get(object) src/java.base/share/classes/java/lang/reflect/Field.java line 184: > 182: *

Re: RFR: 8327460: Compile tests with the same visibility rules as product code [v2]

2024-03-10 Thread David Holmes
On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie wrote: >> Currently, our symbol visibility handling for tests are sloppy; we only >> handle it properly on Windows. We need to bring it up to the same levels as >> product code. This is a prerequisite for >>

Re: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v4]

2024-03-07 Thread David Holmes
On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken wrote: >> We define the RESTARTABLE macro again and again at a lot of places in the >> JDK native codebase. This could be centralized to avoid repeating it again >> and again ! > > Matthias Baesken has updated the pull request incrementally

Re: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v3]

2024-03-06 Thread David Holmes
On Thu, 7 Mar 2024 03:00:11 GMT, Guoxiong Li wrote: >> Matthias Baesken has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Introduce windows jni_util_md.h > > src/java.base/aix/native/libnio/ch/Pollset.c line 3: > >> 1: /* >> 2: *

Re: RFR: 8327138: Clean up status management in cdsConfig.hpp and CDS.java [v3]

2024-03-06 Thread David Holmes
On Wed, 6 Mar 2024 23:36:09 GMT, Ioi Lam wrote: >> A few clean ups: >> >> 1. Rename functions like "`s_loading_full_module_graph()` to >> `is_using_full_module_graph()`. The meaning of "loading" is not clear: it >> might be interpreted as to cover only the period where the artifact is being

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v4]

2024-03-05 Thread David Holmes
On Tue, 5 Mar 2024 14:19:14 GMT, Erik Joelsson wrote: > Does the release note also looks ok? Yes. > Is there any process to formally review release notes? No. Typically just add a comment to the RN sub-task indicating it is okay. My comment, that I had made some minor changes was meant as an

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v4]

2024-03-04 Thread David Holmes
On Mon, 4 Mar 2024 23:44:14 GMT, Erik Joelsson wrote: >> Executables and dynamic libraries on Linux can encode a search path that the >> dynamic linker will use when looking up library dependencies, generally >> referred to as an "rpath". In the JDK we use this with the $ORIGIN feature >> to

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries [v2]

2024-03-03 Thread David Holmes
On Fri, 1 Mar 2024 13:58:08 GMT, Erik Joelsson wrote: >> Executables and dynamic libraries on Linux can encode a search path that the >> dynamic linker will use when looking up library dependencies, generally >> referred to as an "rpath". In the JDK we use this with the $ORIGIN feature >> to

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries

2024-02-29 Thread David Holmes
On Wed, 28 Feb 2024 19:29:13 GMT, Erik Joelsson wrote: > Executables and dynamic libraries on Linux can encode a search path that the > dynamic linker will use when looking up library dependencies, generally > referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to > set

Re: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries

2024-02-28 Thread David Holmes
On Wed, 28 Feb 2024 19:29:13 GMT, Erik Joelsson wrote: > There is no supported usecase that I can think of for injecting other > versions of such libraries in a JDK distribution. I can imagine it could be used to allow "hot patching" of the installed JDK/JRE. Whether anyone has ever needed to

Re: RFR: JDK-8326389: [test] improve assertEquals failure output [v3]

2024-02-25 Thread David Holmes
On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote: >> Currently assertEquals has in the failure case sometimes confusing output >> like : >> >> java.lang.RuntimeException: VM output should contain exactly one RTM locking >> statistics entry for method >>

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

2024-02-21 Thread David Holmes
On Thu, 22 Feb 2024 01:42:17 GMT, Brent Christian wrote: >> Classes in the `java.lang.ref` package would benefit from an update to bring >> the spec in line with how the VM already behaves. The changes would focus on >> _happens-before_ edges at some key points during reference processing. >>

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

2024-02-20 Thread David Holmes
On Wed, 21 Feb 2024 01:20:24 GMT, Brent Christian wrote: >> Classes in the `java.lang.ref` package would benefit from an update to bring >> the spec in line with how the VM already behaves. The changes would focus on >> _happens-before_ edges at some key points during reference processing. >>

Re: RFR: JDK-8252802: java launcher should set MALLOCOPTIONS and LDR_CNTRL in order to use 64KB pages on AIX

2024-02-19 Thread David Holmes
On Mon, 19 Feb 2024 05:52:22 GMT, Varada M wrote: > DeCapo Benchmark Results (3 runs) : > > Before : > = DaCapo 9.12 h2 PASSED in 281402 msec = > = DaCapo 9.12 h2 PASSED in 269818 msec = > = DaCapo 9.12 h2 PASSED in 279279 msec = > > After: > = DaCapo 9.12 h2

Integrated: 8326126: Update the java manpage with the changes from JDK-8322478

2024-02-19 Thread David Holmes
On Mon, 19 Feb 2024 07:04:07 GMT, David Holmes wrote: > Please reviews these manpage updates in relation to "JEP 458: Launch > Multi-File Source-Code Programs". The manpage sources had previously been > updated internally at Oracle under JDK-8322478, but

Re: RFR: 8326126: Update the java manpage with the changes from JDK-8322478

2024-02-19 Thread David Holmes
On Mon, 19 Feb 2024 07:04:07 GMT, David Holmes wrote: > Please reviews these manpage updates in relation to "JEP 458: Launch > Multi-File Source-Code Programs". The manpage sources had previously been > updated internally at Oracle under JDK-8322478, but

RFR: 8326126: Update the java manpage with the changes from JDK-8322478

2024-02-18 Thread David Holmes
Please reviews these manpage updates in relation to "JEP 458: Launch Multi-File Source-Code Programs". The manpage sources had previously been updated internally at Oracle under JDK-8322478, but the open troff file was not regenerated at the time in mainline (it was for JDK 22). The main gist

Re: RFR: 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin [v3]

2024-02-14 Thread David Holmes
On Mon, 5 Feb 2024 09:06:24 GMT, Richard Reingruber wrote: >> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for >> correct (Dekker scheme) synchronization with concurrent execution of >>

Re: RFR: 8325163: Enable -Wpedantic on clang [v2]

2024-02-05 Thread David Holmes
On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote: >> Inspired by (the later backed-out) >> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to >> enable `-Wpedantic` for clang. This has already found some irregularities in >> the code, like mistakenly using

Re: RFR: 8325163: Enable -Wpedantic on clang

2024-02-05 Thread David Holmes
On Mon, 5 Feb 2024 15:42:40 GMT, Kim Barrett wrote: > I thought we didn't, because we were instead supposed to use INTPTR_FORMAT and the (currently?) equivalent PTR_FORMAT. Those macros aren't legacy, they are to provide consistent output across platforms. "%p" provides implementation defined

[jdk22] Integrated: 8322066: Update troff manpages in JDK 22 before RC

2024-02-05 Thread David Holmes
On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote: > This update drops the "ea" from the version string. > > We also propagate the following fixes from the markdown sources to the troff > manpage file: > > JDK-8322478: Update java manpage for multi-file source

Re: [jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC

2024-02-05 Thread David Holmes
On Mon, 5 Feb 2024 21:58:23 GMT, Joe Darcy wrote: >> This update drops the "ea" from the version string. >> >> We also propagate the following fixes from the markdown sources to the troff >> manpage file: >> >> JDK-8322478: Update java manpage for multi-file source-code launcher >>

Re: RFR: 8325163: Enable -Wpedantic on clang

2024-02-04 Thread David Holmes
On Mon, 5 Feb 2024 03:07:43 GMT, Kim Barrett wrote: > I consider the "format '%p' expects argument of type 'void*" warnings to be > not at all helpful. Fortunately we don't use '%p' in HotSpot, We do use it in hotspot. Not a huge amount as we have the legacy format specifiers for PTR_FORMAT

[jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC

2024-02-04 Thread David Holmes
This update drops the "ea" from the version string. We also propagate the following fixes from the markdown sources to the troff manpage file: JDK-8322478: Update java manpage for multi-file source-code launcher JDK-8302233: HSS/LMS: keytool and jarsigner changes JDK-8318971: Better Error

Re: RFR: 8324681: Replace NULL with nullptr in HotSpot jtreg test native code files [v4]

2024-01-28 Thread David Holmes
On Sat, 27 Jan 2024 18:24:45 GMT, Coleen Phillimore wrote: >> This mechanically replaces NULL with nullptr in hpp/cpp native files in test >> native code. This didn't attempt to change NULL in comments to say null >> because nullptr is generally the right thing for the comment to say. It >>

Re: RFR: JDK-8324598: use mem_unit when working with sysinfo memory and swap related information

2024-01-24 Thread David Holmes
On Wed, 24 Jan 2024 10:07:17 GMT, Matthias Baesken wrote: > According to the sysinfo manpage ( > https://man7.org/linux/man-pages/man2/sysinfo.2.html ) the memory and swap > related entries in the struct sysinfo are given as multiples of mem_unit > bytes. > "In the above structure, sizes of

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-24 Thread David Holmes
On Wed, 24 Jan 2024 19:37:40 GMT, Paul Sandoz wrote: >> It is still weird to talk about expressions at this level. We really check >> if the value is constant, like the method name suggests now. Yes, this >> implicitly tests that the expression that produced that value is fully >>

Re: RFR: 8323832: Load JVMCI with the platform class loader [v2]

2024-01-24 Thread David Holmes
On Wed, 24 Jan 2024 13:47:17 GMT, Doug Simon wrote: > You need to check if class is already loaded by trying findLoadedClass first. Thanks @xxDark . I knew it should work. :) - PR Comment: https://git.openjdk.org/jdk/pull/17520#issuecomment-1908961416

Re: RFR: 8323832: Load JVMCI with the platform class loader [v2]

2024-01-24 Thread David Holmes
On Wed, 24 Jan 2024 08:56:10 GMT, Doug Simon wrote: > As far as I understand, even a non-delegating classloader cannot redefine a > class loaded by the boot loader. I modified the test to show this and get: > > ``` > java.lang.LinkageError: loader LoadAlternativeJVMCI$1 @4a1f4d08 attempted >

Re: RFR: 8323832: Load JVMCI with the platform class loader [v2]

2024-01-24 Thread David Holmes
On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon wrote: >> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform >> class loader instead of the boot class loader. This allows Native Image to >> load a version of JVMCI different than the version on top of which Native >>

Re: RFR: 8323832: Load JVMCI with the platform class loader [v2]

2024-01-24 Thread David Holmes
On Wed, 24 Jan 2024 08:46:08 GMT, Doug Simon wrote: >> test/hotspot/jtreg/compiler/jvmci/LoadAlternativeJVMCI.java line 54: >> >>> 52: >>> 53: ClassLoader pcl = ClassLoader.getPlatformClassLoader(); >>> 54: URLClassLoader ucl = new URLClassLoader(cp, null); >> >> I am missing

Re: RFR: 8324433: Introduce a way to determine if an expression is evaluated as a constant by the Jit compiler [v5]

2024-01-23 Thread David Holmes
On Tue, 23 Jan 2024 22:46:20 GMT, Quan Anh Mai wrote: >> src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 56: >> >>> 54: */ >>> 55: @IntrinsicCandidate >>> 56: public static boolean isCompileConstant(boolean expr) { >> >> Here and in other places: probably not

Re: RFR: 8323832: Load JVMCI with the platform class loader [v2]

2024-01-23 Thread David Holmes
On Tue, 23 Jan 2024 19:16:49 GMT, Doug Simon wrote: >> This PR changes `jdk.internal.vm.ci` such that it is loaded by the platform >> class loader instead of the boot class loader. This allows Native Image to >> load a version of JVMCI different than the version on top of which Native >>

Re: RFR: 8323717: Introduce test keyword for tests that need external dependencies

2024-01-22 Thread David Holmes
On Mon, 15 Jan 2024 10:48:23 GMT, Aleksey Shipilev wrote: > Some jtreg tests require resolvable external dependencies. This resolution is > delegated to JIB, which is not used in vanilla OpenJDK testing. It would be > convenient to add a keyword that marks tests that require these external >

Re: RFR: 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin [v2]

2024-01-18 Thread David Holmes
On Thu, 18 Jan 2024 09:21:24 GMT, Richard Reingruber wrote: >>> It is really safe/correct to move this outside the synchronized block? I >>> know things have changed a bit with loom but we've "always" held a lock >>> when doing the actual interrupt. I'd have to check the VM logic to be sure

Re: Avoiding Side Effects of ForkJoinPool.managedBlock

2024-01-18 Thread David Holmes
On 18/01/2024 7:30 pm, Johannes Spangenberg wrote: Hello, I have a question about dealing with side effects caused by ForkJoinPool. I am not certain if this mailing list is the appropriate platform, but I hope it is. The issue I am facing is that running code within a ForkJoinPool may change

Re: RFR: 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin [v2]

2024-01-18 Thread David Holmes
On Wed, 17 Jan 2024 15:38:22 GMT, Richard Reingruber wrote: >> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for >> correct (Dekker scheme) synchronization with concurrent execution of >>

Re: RFR: 8321938: java/foreign/critical/TestCriticalUpcall.java does not need a core file

2024-01-17 Thread David Holmes
On Thu, 18 Jan 2024 00:58:49 GMT, Daniel D. Daugherty wrote: > A trivial fix to disable core file generation in > java/foreign/critical/TestCriticalUpcall.java. Good and trivial. Copyright year needs updating. Thanks - Marked as reviewed by dholmes (Reviewer). PR Review:

Re: RFR: 8323515: Create test alias "all" for all test roots

2024-01-15 Thread David Holmes
On Mon, 15 Jan 2024 11:05:09 GMT, Aleksey Shipilev wrote: > Since recent work to improve `tier4` performance, we actually test > `tier{1,2,3,4}` often, which includes all the tests in current tree. It would > be more convenient to just have the `all` test group/alias, so that we can do >

Re: RFR: 8323659: LinkedTransferQueue add and put methods call overridable offer [v3]

2024-01-14 Thread David Holmes
On Fri, 12 Jan 2024 15:06:01 GMT, Chris Hegarty wrote: >> Update LinkedTransferQueue add and put methods to not call overridable offer. > > Chris Hegarty has updated the pull request incrementally with one additional > commit since the last revision: > > timed offer With my CSR hat on,

Re: RFR: 8323508: Remove TestGCLockerWithShenandoah.java line from TEST.groups

2024-01-10 Thread David Holmes
On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson wrote: > TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups > file still has a reference to it. This causes problems in our CI pipeline. TEST.groups change is good but the other file shouldn't be there. I will hit

Re: RFR: 8309218: java/util/concurrent/locks/Lock/OOMEInAQS.java still times out with ZGC, Generational ZGC, and SerialGC [v2]

2024-01-09 Thread David Holmes
On Tue, 9 Jan 2024 11:08:39 GMT, Viktor Klang wrote: >> As per conversation in the issue. > > Viktor Klang has updated the pull request incrementally with two additional > commits since the last revision: > > - Updating copyright year for zgc and zgc-gen problem lists > - Removing OOMEInAQS

Re: The default java.library.path on Linux does not include the library paths in the mulitarch-spec

2024-01-04 Thread David Holmes
for developers to develop wrappers for platform libraries. It will be interesting to see what they say. Cheers, David - Glavo On Thu, Jan 4, 2024 at 3:12 PM David Holmes <mailto:david.hol...@oracle.com>> wrote: On 4/01/2024 1:36 pm, Glavo wrote: > Hey David, >

Re: The default java.library.path on Linux does not include the library paths in the mulitarch-spec

2024-01-03 Thread David Holmes
I would want to see implemented in hotspot. Cheers, David - Glavo On Tue, Jan 2, 2024 at 10:08 AM David Holmes <mailto:david.hol...@oracle.com>> wrote: Hi Glavo, On 24/12/2023 4:18 am, Glavo wrote: > Hi, > > There are already many Linux distributi

Re: RFR: 8322920: Some ProcessTools.execute* functions are declared to throw Throwable

2024-01-03 Thread David Holmes
On Wed, 3 Jan 2024 09:51:24 GMT, Stefan Karlsson wrote: > Most functions in ProcessTools are declared to throw Exceptions, or one of > its subclasses. However, there are a small number of functions that are > unnecessarily declared to throw Throwable instead of Exception. I propose > that we

Re: The default java.library.path on Linux does not include the library paths in the mulitarch-spec

2024-01-01 Thread David Holmes
Hi Glavo, On 24/12/2023 4:18 am, Glavo wrote: Hi, There are already many Linux distributions that are following the multiarch-spec[1] and adding the following paths to the default library path list: * /usr/local/lib/ * /lib/ * /usr/lib/ But OpenJDK doesn't add these paths to the

Re: RFR: 8311218: fatal error: stuck in JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v8]

2023-12-19 Thread David Holmes
On Mon, 18 Dec 2023 17:09:59 GMT, Serguei Spitsyn wrote: >> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 >> time frame. >> It is fixing a deadlock issue between `VirtualThread` class critical >> sections with the `interruptLock` (in methods: `unpark()`,

Re: RFR: 8321400: java/foreign/TestStubAllocFailure.java fails with code cache exhaustion

2023-12-14 Thread David Holmes
On Wed, 13 Dec 2023 13:29:43 GMT, Jorn Vernee wrote: >> test/jdk/java/foreign/TestStubAllocFailure.java line 51: >> >>> 49: runInNewProcess(UpcallRunner.class, true, >>> List.of("-XX:ReservedCodeCacheSize=3M"), List.of()) >>> 50: .shouldNotHaveExitValue(0) >>> 51:

Integrated: 8322065: Initial nroff manpage generation for JDK 23

2023-12-14 Thread David Holmes
On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes wrote: > Updated the version to 23-ea and year to 2024. > > This initial generation also picks up the unpublished changes from: > > - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & > jarsigner) &

Re: RFR: 8322065: Initial nroff manpage generation for JDK 23 [v2]

2023-12-14 Thread David Holmes
702) (javadoc) (JDK > 23 backport) > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Revert "8309981: Remove expired flags in JDK 23" This reverts commit 0324a90e936ae01e42ae099e7235156326cc3

Re: RFR: 8322065: Initial nroff manpage generation for JDK 23

2023-12-14 Thread David Holmes
On Thu, 14 Dec 2023 09:01:17 GMT, Alan Bateman wrote: > Initially I wondered if JDK-8309981 should be separated but include keeps > things in sync so I think okay. Thanks for the review @AlanBateman . Yeah I was in two minds there myself. I started fixing

Re: RFR: 8322065: Initial nroff manpage generation for JDK 23

2023-12-14 Thread David Holmes
On Thu, 14 Dec 2023 09:17:05 GMT, Pavel Rappo wrote: > Thanks for doing this, David. I only note that the changes for JDK-8321384 > were published in [JDK-8308715](https://bugs.openjdk.org/browse/JDK-8308715), > which was integrated in the mainline before JDK 22 RDP 1. So they are already >

Re: Introduce constructor for PriorityQueue with existing collection and custom comparator

2023-12-14 Thread David Holmes
The current mailing list, core-libs-dev, is the correct one. Cheers, David On 14/12/2023 9:37 am, Valeh Hajiyev wrote: Hi Pavel, Thanks for the reply. If I understand correctly, I need this change to be discussed in one of the mailing lists there, so that someone would sponsor me to create

RFR: 8322065: Initial nroff manpage generation for JDK 23

2023-12-13 Thread David Holmes
Updated the version to 23-ea and year to 2024. This initial generation also picks up the unpublished changes from: - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner) - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport) -

Re: RFR: 8321400: java/foreign/TestStubAllocFailure.java fails with code cache exhaustion

2023-12-12 Thread David Holmes
On Mon, 11 Dec 2023 13:01:25 GMT, Jorn Vernee wrote: > Improve the test by being more lenient to related code cache exhaustion > errors. The important thing is that we don't terminate with a fatal error, > which the new code now checks for explicitly. The check for that is based on > what is

Re: RFR: 8321206: Make Locale related system properties `StaticProperty` [v2]

2023-12-12 Thread David Holmes
On Wed, 6 Dec 2023 20:55:48 GMT, Naoto Sato wrote: >> Currently, Locale-related system properties, such as `user.language` or >> `user.country`, are initialized when the `Locale` class is loaded. Making >> them static properties is safer than relying on the `Locale` class loading >> timing,

Re: RFR: 8321718: ProcessTools.executeProcess calls waitFor before logging

2023-12-12 Thread David Holmes
On Tue, 12 Dec 2023 08:57:08 GMT, Stefan Karlsson wrote: > Do you agree that it would be OK to remove the test? Sure that's fine. - PR Comment: https://git.openjdk.org/jdk/pull/17052#issuecomment-1851644385

Re: RFR: 8321718: ProcessTools.executeProcess calls waitFor before logging

2023-12-11 Thread David Holmes
On Mon, 11 Dec 2023 11:16:05 GMT, Stefan Karlsson wrote: > There is some logging printed when tests spawns processes. This logging is > triggered from calls to `OutputAnalyzer`, when it delegates calls to > `LazyOutputBuffer`. > > If we write code like this: > > ProcessBuilder pb =

Re: RFR: 8321206: Make Locale related system properties `StaticProperty` [v2]

2023-12-10 Thread David Holmes
On Fri, 8 Dec 2023 21:11:57 GMT, Naoto Sato wrote: >> Naoto Sato 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 four additional >> commits

Re: RFR: 8321270: Virtual Thread.yield consumes parking permit [v2]

2023-12-05 Thread David Holmes
On Tue, 5 Dec 2023 09:51:50 GMT, Alan Bateman wrote: >> When a virtual thread continues after Thread.yield it currently consumes >> thread's parking permit. This is an oversight, the parking permit should >> only be consumed when continuing after park. >> >> The changes are straight-forward.

Re: RFR: 8321270: Virtual Thread.yield consumes parking permit [v2]

2023-12-05 Thread David Holmes
On Tue, 5 Dec 2023 09:51:50 GMT, Alan Bateman wrote: >> When a virtual thread continues after Thread.yield it currently consumes >> thread's parking permit. This is an oversight, the parking permit should >> only be consumed when continuing after park. >> >> The changes are straight-forward.

Re: RFR: 8321206: Make Locale related system properties static properties

2023-12-05 Thread David Holmes
On Tue, 5 Dec 2023 23:04:55 GMT, Naoto Sato wrote: > Currently, Locale-related system properties, such as `user.language` or > `user.country`, are initialized when the `Locale` class is loaded. Making > them static properties is safer than relying on the class initialization > timing, which

Re: RFR: 8321206: Make Locale related system properties static properties

2023-12-05 Thread David Holmes
On Tue, 5 Dec 2023 23:04:55 GMT, Naoto Sato wrote: > Currently, Locale-related system properties, such as `user.language` or > `user.country`, are initialized when the `Locale` class is loaded. Making > them static properties is safer than relying on the class initialization > timing, which

Re: RFR: 8321163: [test] OutputAnalyzer.getExitValue() unnecessarily logs even when process has already completed [v3]

2023-12-05 Thread David Holmes
On Tue, 5 Dec 2023 10:56:44 GMT, Jaikiran Pai wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> remove micro optimization > > Thank you Stefan and Leonid for the reviews. Sorry I missed this party :) Thanks for

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v6]

2023-12-03 Thread David Holmes
On Wed, 29 Nov 2023 13:26:58 GMT, serge-sans-paille wrote: >> I take it he is not an Intel employee, in which case he has to be an OpenJDK >> contributor himself for code for which he holds a copyright to be >> contributed to OpenJDK. @robilad please correct me if I am wrong here. > > hey o/

Re: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer [v2]

2023-12-03 Thread David Holmes
On Thu, 30 Nov 2023 16:23:39 GMT, Stefan Karlsson wrote: >> Tests using ProcessTools.executeProcess gets the following output written to >> stdout: >> [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117 >> [2023-11-24T09:58:23.070781345Z] Waiting for completion for process

Re: RFR: 8320786: Remove ThreadGroup.stop

2023-11-28 Thread David Holmes
On Mon, 27 Nov 2023 16:58:29 GMT, Alan Bateman wrote: > ThreadGroup.stop was deprecated since JDK 1.2, deprecated for removal in Java > 18, and re-specified/degraded to throw UnsupportedOperationException > unconditionally in Java 20. Early in Java 23 seems a fine time to finally > remove

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v4]

2023-11-28 Thread David Holmes
On Tue, 21 Nov 2023 15:14:28 GMT, Dalibor Topic wrote: >> src/java.base/linux/native/libsimdsort/avx2-32bit-qsort.hpp line 3: >> >>> 1: /* >>> 2: * Copyright (c) 2021, 2023, Intel Corporation. All rights reserved. >>> 3: * Copyright (c) 2021 Serge Sans Paille. All rights reserved. >> >> Is

Re: RFR: JDK-8319413: Start of release updates for JDK 23

2023-11-27 Thread David Holmes
On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote: > Time to start making preparations for JDK 23. Hotspot change is trivially fine, but too insignificant to hit the Approve button. Thanks - PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1752152672

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v2]

2023-11-27 Thread David Holmes
On Mon, 27 Nov 2023 23:44:25 GMT, Sandhya Viswanathan wrote: >> Not listed here: https://oca.opensource.oracle.com/?ojr=contributors > > Yes, Vamsi is part of Intel Java team. He also has the author status > (https://openjdk.org/census#sparasa). @sviswa7 I am asking about the copyright holder

Re: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer

2023-11-24 Thread David Holmes
On Fri, 24 Nov 2023 17:13:30 GMT, Jaikiran Pai wrote: >> Tests using ProcessTools.executeProcess gets the following output written to >> stdout: >> [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117 >> [2023-11-24T09:58:23.070781345Z] Waiting for completion for process

Re: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer

2023-11-24 Thread David Holmes
On Fri, 24 Nov 2023 10:34:02 GMT, Stefan Karlsson wrote: > Tests using ProcessTools.executeProcess gets the following output written to > stdout: > [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117 > [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117

Re: RFR: 8320532: Remove Thread/ThreadGroup suspend/resume

2023-11-24 Thread David Holmes
On Thu, 23 Nov 2023 09:18:44 GMT, Alan Bateman wrote: > The deadlock prone Thread/ThreadGroup suspend/resume were deprecated since > JDK 1.2, deprecated for removal in Java 14, and re-specified/degraded to > throw UnsupportedOperationException unconditionally in Java 19/20. Early in > Java

Integrated: 8318776: Require supports_cx8 to always be true

2023-11-23 Thread David Holmes
On Mon, 13 Nov 2023 04:38:35 GMT, David Holmes wrote: > As discussed in JBS all platforms (some tweaks to Zero are in progress) > actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip > out the locked-based alternatives to using it and just add a

Re: RFR: 8318776: Require supports_cx8 to always be true [v7]

2023-11-23 Thread David Holmes
On Thu, 23 Nov 2023 12:09:27 GMT, David Holmes wrote: >> As discussed in JBS all platforms (some tweaks to Zero are in progress) >> actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip >> out the locked-based alternatives to using it and ju

  1   2   3   4   5   6   >