Re: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v2]

2025-07-10 Thread David Holmes
On Thu, 10 Jul 2025 03:12:27 GMT, Serguei Spitsyn wrote: >> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as >> a temporary backward compatibility flag under JDK-8192936 and was >> immediately marked as Deprecate. The fix is to obsolete this option in JDK >> 26 and

Re: RFR: 8342868: Errors related to unused code on Windows after 8339120 in core libs [v2]

2025-07-07 Thread David Holmes
On Tue, 8 Jul 2025 01:28:04 GMT, Julian Waters wrote: >> Julian Waters has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove the got local > > Sorry for waiting so long. It's become clear that I won't be able to get awt > and accessibi

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

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

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

2025-06-30 Thread David Holmes
On Mon, 30 Jun 2025 22:11:57 GMT, Chen Liang wrote: >> I have updated this patch to avoid a redundant `runtimeSetup` annotation - >> we have agreed that the requirement for setup is a side effect of >> initialization, and such methods in AOTCI classes must be automatically >> recognized. This

Re: Object.wait returns normally if interrupted

2025-06-27 Thread David Holmes
]: https://docs.oracle.com/javase/specs/jls/se24/html/jls-17.html#jls-17.2.4 On Fri, Jun 27, 2025 at 1:11 PM Pavel Rappo wrote: So, Object.wait() guarantees to throw InterruptedException if the interrupt status is set upon entrance, yes? Could this be added to javadoc? On Fri, Jun 27, 2025 at 1

Re: Object.wait returns normally if interrupted

2025-06-27 Thread David Holmes
, then an InterruptedException is thrown. David - On Fri, Jun 27, 2025 at 12:59 PM David Holmes wrote: On 27/06/2025 5:58 pm, Pavel Rappo wrote: David, As you correctly identified, the edge case that I mentioned is this: concurrent interrupt and notify [^1]. It has nothing to do with

Re: Object.wait returns normally if interrupted

2025-06-27 Thread David Holmes
n Fri, Jun 27, 2025 at 3:47 AM David Holmes wrote: Hi Pavel, On 27/06/2025 8:23 am, Pavel Rappo wrote: Here's an interesting behaviour. A thread that has been blocked in Object.wait is interrupted. But instead of throwing an InterruptedException, Object.wait returns normally with the thread&#x

Re: Object.wait returns normally if interrupted

2025-06-26 Thread David Holmes
Hi Pavel, On 27/06/2025 8:23 am, Pavel Rappo wrote: Here's an interesting behaviour. A thread that has been blocked in Object.wait is interrupted. But instead of throwing an InterruptedException, Object.wait returns normally with the thread's interrupt status set. Do you mean it returns normal

Re: RFR: 8359437: Make users and test suite not able to set LockingMode flag [v2]

2025-06-25 Thread David Holmes
On Tue, 24 Jun 2025 09:14:42 GMT, Anton Artemov wrote: >> This PR contains changes for the 1st phase of the `LockingMode` flag >> obsoletion. >> >> The work is done by @fbredber, I have taken it over and am finishing it >> while he's on vacation. >> >> In the 1st phase one keeps the `Lockin

Re: RFR: 8359437: Make users and test suite not able to set LockingMode flag [v5]

2025-06-24 Thread David Holmes
On Tue, 24 Jun 2025 13:25:20 GMT, Anton Artemov wrote: >> This PR contains changes for the 1st phase of the `LockingMode` flag >> obsoletion. >> >> The work is done by @fbredber, I have taken it over and am finishing it >> while he's on vacation. >> >> In the 1st phase one keeps the `Lockin

Re: RFR: 8359437: Make users and test suite not able to set LockingMode flag [v4]

2025-06-24 Thread David Holmes
On Tue, 24 Jun 2025 11:16:21 GMT, Anton Artemov wrote: >> This PR contains changes for the 1st phase of the `LockingMode` flag >> obsoletion. >> >> The work is done by @fbredber, I have taken it over and am finishing it >> while he's on vacation. >> >> In the 1st phase one keeps the `Lockin

Re: RFR: 8359437: Make users and test suite not able to set LockingMode flag [v3]

2025-06-24 Thread David Holmes
On Tue, 24 Jun 2025 09:59:50 GMT, Anton Artemov wrote: >> This PR contains changes for the 1st phase of the `LockingMode` flag >> obsoletion. >> >> The work is done by @fbredber, I have taken it over and am finishing it >> while he's on vacation. >> >> In the 1st phase one keeps the `Lockin

Re: RFR: 8359437: Make users and test suite not able to set LockingMode flag

2025-06-24 Thread David Holmes
On Tue, 17 Jun 2025 08:39:49 GMT, Anton Artemov wrote: > This PR contains changes for the 1st phase of the `LockingMode` flag > obsoletion. > > The work is done by @fbredber, I have taken it over and am finishing it while > he's on vacation. > > In the 1st phase one keeps the `LockingMode`

Re: RFR: 8359437: Make users and test suite not able to set LockingMode flag

2025-06-23 Thread David Holmes
On Tue, 17 Jun 2025 08:39:49 GMT, Anton Artemov wrote: > This PR contains changes for the 1st phase of the `LockingMode` flag > obsoletion. > > The work is done by @fbredber, I have taken it over and am finishing it while > he's on vacation. > > In the 1st phase one keeps the `LockingMode`

Re: RFR: 8359437: Make users and test suite not able to set LockingMode flag

2025-06-23 Thread David Holmes
On Mon, 23 Jun 2025 10:39:59 GMT, Anton Artemov wrote: >> test/hotspot/jtreg/runtime/Monitor/StressWrapper_TestRecursiveLocking_36M.java >> line 36: >> >>> 34: * -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI >>> 35: * -Xint >>> 36: * -XX:LockingMode=0 >> >> I was wondering why

Re: RFR: 8359437: Make users and test suite not able to set LockingMode flag

2025-06-23 Thread David Holmes
On Tue, 17 Jun 2025 08:39:49 GMT, Anton Artemov wrote: > This PR contains changes for the 1st phase of the `LockingMode` flag > obsoletion. > > The work is done by @fbredber, I have taken it over and am finishing it while > he's on vacation. > > In the 1st phase one keeps the `LockingMode`

Re: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens [v2]

2025-06-17 Thread David Holmes
On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini wrote: >> The implemented solution modifies the `OutputBuffer` implementation instead >> of the `OutputAnalyzer` implementation. >> This is because the **OutputBuffer implementation which handles processes** >> (LazyOutputBuffer) starts a thread

Re: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens [v2]

2025-06-08 Thread David Holmes
On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini wrote: >> The implemented solution modifies the `OutputBuffer` implementation instead >> of the `OutputAnalyzer` implementation. >> This is because the **OutputBuffer implementation which handles processes** >> (LazyOutputBuffer) starts a thread

Re: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens [v2]

2025-06-08 Thread David Holmes
On Thu, 5 Jun 2025 14:58:40 GMT, Matthew Donovan wrote: >> Alice Pellegrini 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 three additional >>

Re: RFR: 8356438: Update OutputAnalyzer to optionally print process output as it happens [v2]

2025-06-05 Thread David Holmes
On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini wrote: >> The implemented solution modifies the `OutputBuffer` implementation instead >> of the `OutputAnalyzer` implementation. >> This is because the **OutputBuffer implementation which handles processes** >> (LazyOutputBuffer) starts a thread

Re: RFR: 8358633 : Test ThreadPoolExecutorTest::testTimedInvokeAnyNullTimeUnit is broken by JDK-8347491

2025-06-05 Thread David Holmes
On Thu, 5 Jun 2025 07:47:17 GMT, Viktor Klang wrote: > It's too fragile to depend on generated NPE messages Sorry Viktor but I strongly disagree. It is far too easy to have a test "pass" because it catches the wrong instance of a thrown exception and hide an underlying problem. -

Re: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v6]

2025-06-01 Thread David Holmes
On Mon, 2 Jun 2025 03:49:42 GMT, Mohamed Issa wrote: > When you say "most of the non-x86 platforms", are you referring to the ones > with processor types listed below? Yes - 3 of the 5 non-x86 platforms. > It looks like aarch64 and riscv don't take that route and would fall back to > the defa

Re: RFR: 8353686: Optimize Math.cbrt for x86 64 bit platforms [v6]

2025-06-01 Thread David Holmes
On Fri, 30 May 2025 19:34:16 GMT, Mohamed Issa wrote: >> The goal of this PR is to implement an x86_64 intrinsic for >> java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are >> included to check the performance of specific input value ranges to help >> prevent regression

Re: [External] : Re: mapConcurrent() with InterruptedException

2025-05-28 Thread David Holmes
On 29/05/2025 3:45 am, Jige Yu wrote: 17.2.4 is specifically about the Object wait()/notify() API, yeah? I've always had this confusion in my mind that I couldn't find an authoritative source for: what was the point of checked InterruptedException? Interruption and IE provide a limited capab

Re: RFR: 8352533: Report useful IOExceptions when jspawnhelper fails [v4]

2025-05-13 Thread David Holmes
On Tue, 13 May 2025 12:51:56 GMT, Thomas Stuefe wrote: >> You are right and I am confused. I always assumed that the primary function >> of jspawnhelper was to make vfork safe. Historically, that was the typical >> reason for an intermediate exec() to a helper - basically, you first exec() >>

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-09 Thread David Holmes
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to > run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests > and test the

Re: Runtime.exec and SIGPIPE + SIG_IGN

2025-05-09 Thread David Holmes
Hi Thomas, On 29/04/2025 7:04 pm, Thomas Stüfe wrote: Hi, I would like to gauge opinions on whether the following scenario is a bug to fix or whether to accept it as standard behavior. --- A customer has the following problem: - The JVM invokes a third-party JNI library that sets the signa

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

2025-05-08 Thread David Holmes
On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to > run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests > and test the

Re: RFR: 8355938: Addressed rare lost unpark bug 8074773 by pre-loading LockSupport.class

2025-05-08 Thread David Holmes
On Wed, 30 Apr 2025 11:25:34 GMT, Alan Bateman wrote: > Hopefully David will remember more of this when he gets back. Sadly I have to page in all the details again like everyone else. The underlying issue is nested-parking as Alan notes. From re-reading 8074773, pre-loading in any class loaded

Re: RFR: 8355746: Start of release updates for JDK 26 [v2]

2025-05-08 Thread David Holmes
On Thu, 8 May 2025 13:18:07 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains seven commits: > > - Update release date > - Update --release 25 symbol information f

Re: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2]

2025-05-08 Thread David Holmes
On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. We need to make sure the two threads are >> blocked on the expected locks before invoking findMonitorDeadlockedThreads. >> In the failing cases, one of the threads is seen as blocked while wait

Re: RFR: 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock [v2]

2025-05-08 Thread David Holmes
On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo wrote: >> Please review this small test fix. We need to make sure the two threads are >> blocked on the expected locks before invoking findMonitorDeadlockedThreads. >> In the failing cases, one of the threads is seen as blocked while wait

Re: RFR: 8351322: Parameterize link option for pthreads [v2]

2025-04-04 Thread David Holmes
On Thu, 20 Mar 2025 12:38:37 GMT, Magnus Ihse Bursie wrote: > Is there any gain then in changing away from -lpthread? That is clearly > defined, link with libpthread, with no side effects. "If it ain't broke..." True - what we have works and using `-pthread` might subtly change things. ---

Re: RFR: 8353684: [BACKOUT] j.u.l.Handler classes create deadlock risk via synchronized publish() method

2025-04-03 Thread David Holmes
On Thu, 3 Apr 2025 21:03:08 GMT, Stuart Marks wrote: > Back out commit for > [JDK-8349206](https://bugs.openjdk.org/browse/JDK-8349206) because of build > failure. > > This reverts commit ebcb9a8b128cc6411610566c8368db63d25a5127. LGTM Thanks Stuart! - Marked as reviewed by dholm

Re: RFR: 8352935: Launcher should not add $JDK/../lib to LD_LIBRARY_PATH

2025-04-03 Thread David Holmes
On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern wrote: > In the JDK launcher, there is a codepath which would set/modify the > LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can > also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which > contains a li

Re: RFR: 8353458: Don't pass -Wno-format-nonliteral to CFLAGS

2025-04-01 Thread David Holmes
On Tue, 1 Apr 2025 13:22:47 GMT, Magnus Ihse Bursie wrote: > there was already a pragma but due to incorrect restrictions it did not apply > to clang. How does the `__GNUC__` check affect clang?? Isn't that just for gcc? - PR Comment: https://git.openjdk.org/jdk/pull/24357#issueco

Re: RFR: 8304674: AttachCurrentThread 's argument is JavaVMAttachArgs

2025-03-30 Thread David Holmes
Hi, This change was already proposed (by myself): https://bugs.openjdk.org/browse/JDK-8289253 but it cannot be done as it will break source compatibility. We will just have to live with this historical oddity. Cheers, David On 31/03/2025 12:46 pm, tison wrote: On Mon, 31 Mar 2025 02:08:02 G

Re: RFR: 8352184: Jtreg tests using CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils fail on static JDK [v4]

2025-03-26 Thread David Holmes
On Wed, 26 Mar 2025 19:28:24 GMT, Jiangli Zhou wrote: >> Please review following changes, thanks. >> >> - Add `static` to the vm_info for static JDK. The `-version` output now >> contains `static` on static JDK, e.g.: >> >> >> $ static-jdk/bin/java -version >> openjdk version "25-internal" 20

Re: RFR: 8352184: Jtreg tests using CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils fail on static JDK [v3]

2025-03-25 Thread David Holmes
On Tue, 25 Mar 2025 15:25:56 GMT, Jiangli Zhou wrote: >> Please review following changes, thanks. >> >> - Add `static` to the vm_info for static JDK. The `-version` output now >> contains `static` on static JDK, e.g.: >> >> >> $ static-jdk/bin/java -version >> openjdk version "25-internal" 20

Re: RFR: 8352184: Jtreg tests using CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils fail on static JDK [v2]

2025-03-24 Thread David Holmes
On Mon, 24 Mar 2025 20:22:55 GMT, Jiangli Zhou wrote: >> Please review following changes, thanks. >> >> - Add `static` to the vm_info for static JDK. The `-version` output now >> contains `static` on static JDK, e.g.: >> >> >> $ static-jdk/bin/java -version >> openjdk version "25-internal" 20

Re: RFR: 8352276: Skip jtreg tests using native executable with libjvm.so/libjli.so dependencies on static JDK

2025-03-24 Thread David Holmes
On Tue, 18 Mar 2025 18:57:04 GMT, Jiangli Zhou wrote: > Please review this PR that adds `@requires !jdk.static` to tests, thanks. > > - runtime/StackGap/TestStackGap.java > - runtime/StackGuardPages/TestStackGuardPages.java > - runtime/TLS/TestTLS.java > - runtime/jni/daemonDestroy/TestDaemonDes

Re: RFR: 8352184: Jtreg tests using CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils fail on static JDK

2025-03-24 Thread David Holmes
On Sat, 22 Mar 2025 03:46:38 GMT, Jiangli Zhou wrote: > Please review following changes, thanks. > > - Add `static` to the vm_info for static JDK. The `-version` output now > contains `static` on static JDK, e.g.: > > > $ static-jdk/bin/java -version > openjdk version "25-internal" 2025-09-16

Re: RFR: 8352489: Relax jspawnhelper version checks to informative

2025-03-20 Thread David Holmes
On Thu, 20 Mar 2025 09:52:02 GMT, Aleksey Shipilev wrote: > See the bug for rationale. > > This goal for this improvement is to be easily backportable, so we can catch > up with update releases. As such, it does a few borderline-trivial changes, > and _does not_ change the jspawnhelper protoc

Re: RFR: 8352276: Skip jtreg tests using native executable with libjvm.so/libjli.so dependencies on static JDK

2025-03-18 Thread David Holmes
On Tue, 18 Mar 2025 18:57:04 GMT, Jiangli Zhou wrote: > Please review this PR that adds `@requires !jdk.static` to tests, thanks. > > - runtime/StackGap/TestStackGap.java > - runtime/StackGuardPages/TestStackGuardPages.java > - runtime/TLS/TestTLS.java > - runtime/jni/daemonDestroy/TestDaemonDes

Re: RFR: 8351322: Parameterize link option for pthreads [v2]

2025-03-16 Thread David Holmes
On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes wrote: >>> What is the intended way of using this? Do you run make with >>> LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the >>> specific way of linking to pthread? >> >> This is in prep

Re: RFR: 8352044: Add --with-import-jvms to configure

2025-03-14 Thread David Holmes
On Fri, 14 Mar 2025 17:58:50 GMT, Magnus Ihse Bursie wrote: >> This change copies `libjvm.so` _and_ sibling `.jsa` files, right? >> >> If so, then one thing is missing: regenerating CDS archives that have >> opinions on `modules` filesizes/dates for fingerprinting their CDS archives. >> My fra

Re: RFR: 8351322: Parameterize link option for pthreads

2025-03-09 Thread David Holmes
On Thu, 6 Mar 2025 10:39:27 GMT, snake66 wrote: > Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's > possible to parameterize this for platforms that use different flags for > enabling posix threads. > > This work is a continuation of the work done by Greg Lewis in

Re: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v17]

2025-03-06 Thread David Holmes
On Sun, 2 Mar 2025 21:17:04 GMT, Sergey Chernyshev wrote: >> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as >> well. > >> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as >> well. > > Thanks for your review @jerboaa ! I cheched the > te

Re: RFR: 8351322: Parameterize link option for pthreads

2025-03-06 Thread David Holmes
On Thu, 6 Mar 2025 15:47:58 GMT, Magnus Ihse Bursie wrote: >> What is the intended way of using this? Do you run make with >> `LIBPTHREAD=-pthread` or do you apply a patch on `libraries.m4` for the >> specific way of linking to pthread? > >> What is the intended way of using this? Do you run ma

Re: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR [v2]

2025-03-02 Thread David Holmes
On Thu, 27 Feb 2025 10:19:51 GMT, Matthias Baesken wrote: >> While testing a bit with a minimal JVM, it has been noticed that some >> java/lang jtreg tests use jfr but do not declare it with a "requires >> vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR . > > Matthias Baesken

Re: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR [v2]

2025-02-28 Thread David Holmes
On Fri, 28 Feb 2025 07:22:24 GMT, Alan Bateman wrote: > In this case it's a JDK-specific module Okay but is there a transitive dependency from the public module that has to be present to the internal module? That said ... we are building a minimal VM we are not building Compact Profiles. I do

Re: RFR: 8350786: Some java/lang jtreg tests miss requires vm.hasJFR [v2]

2025-02-27 Thread David Holmes
On Thu, 27 Feb 2025 10:19:51 GMT, Matthias Baesken wrote: >> While testing a bit with a minimal JVM, it has been noticed that some >> java/lang jtreg tests use jfr but do not declare it with a "requires >> vm.hasJFR" ; that leads to test errors in a JVM setup with no JFR . > > Matthias Baesken

Re: RFR: 8349860: Make Class.isArray(), Class.isInterface() and Class.isPrimitive() non-native [v3]

2025-02-19 Thread David Holmes
On Wed, 19 Feb 2025 20:30:34 GMT, Coleen Phillimore wrote: >> Class.isInterface() can check modifier flags, Class.isArray() can check >> whether component mirror is non-null and Class.isPrimitive() needs a new >> final transient boolean in java.lang.Class that the JVM code initializes. >> Teste

Re: RFR: 8349860: Make Class.isArray(), Class.isInterface() and Class.isPrimitive() non-native

2025-02-18 Thread David Holmes
On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore wrote: > Class.isInterface() can check modifier flags, Class.isArray() can check > whether component mirror is non-null and Class.isPrimitive() needs a new > final transient boolean in java.lang.Class that the JVM code initializes. > Tested wi

Re: RFR: 8349145: Make Class.getProtectionDomain() non-native [v7]

2025-02-11 Thread David Holmes
ssibleObject/TrySetAccessibleTest.java > >Co-authored-by: David Holmes > <62092539+dholmes-...@users.noreply.github.com> > - Update > test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java > >Co-authored-by: David Holmes > <62092539

Re: RFR: 8349689: Several virtual thread tests missing /native keyword [v5]

2025-02-11 Thread David Holmes
On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan wrote: >> H all, >> >> This PR add `/native` keyword in the test header for virtual thread tests. >> The `/native` keyword will make run the related tests by jtreg standalone >> more friendly. >> >> I runed all the tests without -nativepath argument

Re: RFR: 8349284: Make libExplicitAttach work on static JDK [v4]

2025-02-10 Thread David Holmes
On Mon, 10 Feb 2025 04:00:44 GMT, Jiangli Zhou wrote: >> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It >> removes libjvm.so as a recorded dependency for libExplicitAttach.so by not >> explicitly link libExplicitAttach.so with libjvm.so at build time. To do >> that, it

Re: RFR: 8349145: Make Class.getProtectionDomain() non-native [v4]

2025-02-10 Thread David Holmes
On Thu, 6 Feb 2025 12:12:59 GMT, Coleen Phillimore wrote: >> I am still missing what can actually set a PD here, sorry. ?? > > Because the field is final, it has to be initialized in the constructor in > Java code. My initial patch for modifiers chose to initialize to zero but > that's not qui

Re: RFR: 8349145: Make Class.getProtectionDomain() non-native [v4]

2025-02-05 Thread David Holmes
On Wed, 5 Feb 2025 17:41:22 GMT, Coleen Phillimore wrote: >> src/java.base/share/classes/java/lang/Class.java line 239: >> >>> 237: * generated. >>> 238: */ >>> 239: private Class(ClassLoader loader, Class arrayComponentType, >>> ProtectionDomain pd) { >> >> If this constructor i

Re: RFR: 8349462: Gatherers.mapConcurrent could support async interrupts

2025-02-05 Thread David Holmes
On Wed, 5 Feb 2025 16:14:41 GMT, Viktor Klang wrote: > This change is likely going to need some extra verbiage in the spec for > mapConcurrent, and thus a CSR. > This behavior aligns mapConcurrent with how parallel streams work in > conjunction with interruptions of the caller thread. src/java

Integrated: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

2025-02-05 Thread David Holmes
On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes wrote: > This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. > > JDK-8348190: Framework for tracing makefile inclusion and parsing > > The above issue caused problems in the Oracle closed builds and so needs to > be bac

Re: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

2025-02-05 Thread David Holmes
On Thu, 6 Feb 2025 02:48:21 GMT, Mikael Vidstedt wrote: >> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. >> >> JDK-8348190: Framework for tracing makefile inclusion and parsing >> >> The above issue caused problems in the Oracle closed builds and so needs to >> be backed out un

Re: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

2025-02-05 Thread David Holmes
On Thu, 6 Feb 2025 02:01:47 GMT, Joe Darcy wrote: >> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. >> >> JDK-8348190: Framework for tracing makefile inclusion and parsing >> >> The above issue caused problems in the Oracle closed builds and so needs to >> be backed out until th

RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

2025-02-05 Thread David Holmes
This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. JDK-8348190: Framework for tracing makefile inclusion and parsing The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed. Thanks. - Commit messages: - Revert "

Re: RFR: 8349145: Make Class.getProtectionDomain() non-native [v4]

2025-02-04 Thread David Holmes
On Mon, 3 Feb 2025 16:11:06 GMT, Coleen Phillimore wrote: >> This change removes the native call and injected field for ProtectionDomain >> in the java.lang.Class instance, and moves the field to be declared in Java. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incr

Re: RFR: 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler [v3]

2025-02-02 Thread David Holmes
On Fri, 31 Jan 2025 22:18:32 GMT, Tom Rodriguez wrote: >> Deoptimization with escape analysis can fail when trying to rematerialize >> objects as described in JDK-8227309. In this test this can happen in Xcomp >> mode in the framework of the test resulting in a test failure. Making the >> nu

Re: RFR: 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler [v2]

2025-01-21 Thread David Holmes
On Thu, 16 Jan 2025 18:37:36 GMT, Tom Rodriguez wrote: >> Deoptimization with escape analysis can fail when trying to rematerialize >> objects as described in JDK-8227309. In this test this can happen in Xcomp >> mode in the framework of the test resulting in a test failure. Making the >> nu

Re: RFR: 8338428: Add logging of final VM flags while setting properties [v6]

2025-01-21 Thread David Holmes
On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik wrote: >> Some VM flags might depend on the environment and it makes sense to log >> final flags so it is possible to get their value when investigating failures. >> >> I added them to VMProps, so it is always dump final flags before running >> t

Re: RFR: 8338428: Add logging if final VM flags while setting properties [v6]

2025-01-19 Thread David Holmes
On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik wrote: >> Some VM flags might depend on the environment and it makes sense to log >> final flags so it is possible to get their value when investigating failures. >> >> I added them to VMProps, so it is always dump final flags before running >> t

Re: RFR: 8347840: Fix testlibrary compilation warnings [v3]

2025-01-16 Thread David Holmes
On Thu, 16 Jan 2025 17:53:48 GMT, Leonid Mesnik wrote: >> test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java line 46: >> >>> 44: public int getInt(long pos) throws IOException; >>> 45: public long getLong(long pos) throws IOException; >>> 46: public void close() throws IOExceptio

Re: RFR: 8347840: Fix testlibrary compilation warnings [v3]

2025-01-16 Thread David Holmes
On Thu, 16 Jan 2025 18:18:15 GMT, Leonid Mesnik wrote: >> There few compiler warning disabled in the testlibary build. >> They should be fixed or localized and removed from build to prevent new >> possible issues. >> >> The main goal is to avoid new such issues in the testlibrary. >> Tested wi

Re: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v3]

2025-01-16 Thread David Holmes
On Wed, 15 Jan 2025 21:26:49 GMT, Brian Burkhalter wrote: >> Fix the means of determining whether an exception is to be expected in the >> Windows test. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit since the last revision: > > 8347740: Change W

Re: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v3]

2025-01-16 Thread David Holmes
On Wed, 15 Jan 2025 21:26:49 GMT, Brian Burkhalter wrote: >> Fix the means of determining whether an exception is to be expected in the >> Windows test. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit since the last revision: > > 8347740: Change W

Re: RFR: 8347840: Fix testlibrary compilation warnings

2025-01-15 Thread David Holmes
On Wed, 15 Jan 2025 23:48:33 GMT, Leonid Mesnik wrote: > There few compiler warning disabled in the testlibary build. > They should be fixed or localized and removed from build to prevent new > possible issues. > > The main goal is to avoid new such issues in the testlibrary. > Tested with tie

Re: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v2]

2025-01-14 Thread David Holmes
On Tue, 14 Jan 2025 22:15:07 GMT, Brian Burkhalter wrote: >> Fix the means of determining whether an exception is to be expected in the >> Windows test. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit since the last revision: > > 8347740: Minor cl

Re: RFR: 8347761: Test tools/jimage/JImageExtractTest.java fails after JDK-8303884

2025-01-14 Thread David Holmes
On Wed, 15 Jan 2025 05:14:51 GMT, Henry Jen wrote: > jimage use the same code to parse command line options, the resource bundle > for jimage also need update. LGTM. Thanks - Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23123#pullrequestre

Re: RFR: 8347762: ClassFile attribute specification refers to non-SE modules [v2]

2025-01-14 Thread David Holmes
On Wed, 15 Jan 2025 04:57:03 GMT, Chen Liang wrote: >> The new API specification for class file attributes link to non-SE modules >> of jdk.compiler and jdk.jlink, which caused docs build failure for SE docs. >> This patch removes those links and replace them with plain module name >> referenc

Re: RFR: 8347762: ClassFile attribute specification refers to non-SE modules

2025-01-14 Thread David Holmes
On Wed, 15 Jan 2025 04:27:14 GMT, Chen Liang wrote: > The new API specification for class file attributes link to non-SE modules of > jdk.compiler and jdk.jlink, which caused docs build failure for SE docs. This > patch removes those links and replace them with plain module name references. Ch

Re: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v7]

2025-01-14 Thread David Holmes
On Mon, 13 Jan 2025 11:07:11 GMT, Per Minborg wrote: >> Going forward, converting older JDK code to use the relatively new FFM API >> requires system calls that can provide `errno` and the likes to explicitly >> allocate a MemorySegment to capture potential error states. This can lead to >> ne

Re: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v7]

2025-01-13 Thread David Holmes
On Mon, 13 Jan 2025 11:07:11 GMT, Per Minborg wrote: >> Going forward, converting older JDK code to use the relatively new FFM API >> requires system calls that can provide `errno` and the likes to explicitly >> allocate a MemorySegment to capture potential error states. This can lead to >> ne

Re: RFR: 8347376: tools/jlink/runtimeImage/JavaSEReproducibleTest.java and PackagedModulesVsRuntimeImageLinkTest.java failed after JDK-8321413

2025-01-13 Thread David Holmes
On Mon, 13 Jan 2025 21:58:43 GMT, Henry Jen wrote: > Sort services provided by a module to ensure reproduce same result. Seems reasonable. Thanks for fixing. - Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23088#pullrequestreview-2548790485

Re: RFR: 8346986: Remove ASM from java.base [v8]

2025-01-13 Thread David Holmes
On Mon, 13 Jan 2025 08:14:08 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test >> libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam

Re: RFR: 8347124: Clean tests with --enable-linkable-runtime [v3]

2025-01-12 Thread David Holmes
On Thu, 9 Jan 2025 10:18:35 GMT, Severin Gehwolf wrote: >> Please review this trivial test-only patch in support of running tests on >> JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run >> `jlink` in-process of the test JVM which includes module patches (as in - >> use

Re: RFR: 8346986: Remove ASM from java.base [v6]

2025-01-12 Thread David Holmes
On Fri, 10 Jan 2025 16:12:54 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test >> libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam

Re: RFR: 8347302: Update ProcessTools.java to support virtual test factory for Xbootclasspath/a:

2025-01-08 Thread David Holmes
On Thu, 9 Jan 2025 00:12:29 GMT, Leonid Mesnik wrote: > Test > runtime/cds/appcds/jigsaw/modulepath/OptimizeModuleHandlingTest.java > uses > -Xbootclasspath/a: classpath > (2 arguments) > > Such usage of options -Xbootclasspath/a: should be correctly processed by > virtual thread factory suppor

Re: RFR: 8347302: Update ProcessTools.java to support virtual test factory for Xbootclasspath/a:

2025-01-08 Thread David Holmes
On Thu, 9 Jan 2025 00:12:29 GMT, Leonid Mesnik wrote: > Test > runtime/cds/appcds/jigsaw/modulepath/OptimizeModuleHandlingTest.java > uses > -Xbootclasspath/a: classpath > (2 arguments) > > Such usage of options -Xbootclasspath/a: should be correctly processed by > virtual thread factory suppor

Re: RFR: 8347302: Update ProcessTools.java to support virtual test factory for Xbootclasspath/a:

2025-01-08 Thread David Holmes
On Thu, 9 Jan 2025 00:12:29 GMT, Leonid Mesnik wrote: > Test > runtime/cds/appcds/jigsaw/modulepath/OptimizeModuleHandlingTest.java > uses > -Xbootclasspath/a: classpath > (2 arguments) > > Such usage of options -Xbootclasspath/a: should be correctly processed by > virtual thread factory suppor

Re: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2]

2025-01-08 Thread David Holmes
On Wed, 8 Jan 2025 14:56:55 GMT, Severin Gehwolf wrote: >> Please review this trivial test-only patch in support of running tests on >> JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run >> `jlink` in-process of the test JVM which includes module patches (as in - >> use

Re: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history [v3]

2025-01-08 Thread David Holmes
On Wed, 8 Jan 2025 15:23:23 GMT, Chen Liang wrote: > Joe and David, can you look at this updated versioning that uses the core > libraries since scheme? Yep that looks fine. Thanks. - PR Comment: https://git.openjdk.org/jdk/pull/22934#issuecomment-2579111421

Re: RFR: 8345782: Refining the cases that libjsig deprecation warning is issued [v2]

2025-01-08 Thread David Holmes
On Wed, 8 Jan 2025 11:03:06 GMT, Joakim Nordström wrote: >> Could I get a review of this fix to refine the warnings printed by `libjsig` >> when using the deprecated `signal()`/`sigset()` functions? >> >> Currently the libjsig library supports chaining `signal()` and `sigset()`. >> With these

Re: RFR: 8345782: Refining the cases that libjsig deprecation warning is issued [v2]

2025-01-08 Thread David Holmes
On Wed, 8 Jan 2025 11:00:14 GMT, Joakim Nordström wrote: >> The test is skipped for SIGUSR2 on Linux and MacOS, and Windows skips all >> signal testing. So I guess that leaves aix, which seems to use >> signals_poxis.cpp... so perhaps the SIGUSR2 test should be skipped for aix >> too? >> But

Re: RFR: 8346986: Remove ASM from java.base

2025-01-08 Thread David Holmes
On Wed, 8 Jan 2025 06:52:10 GMT, Adam Sotona wrote: > BTW: purpose of this PR is to seamlessly remove ASM from java.base and it is > slightly turning into a massive synchronous refactoring of several hundreds > of hotspot tests. Moving the ASM library requires modifying every single test that

Re: RFR: 8346986: Remove ASM from java.base

2025-01-07 Thread David Holmes
On Tue, 7 Jan 2025 20:19:53 GMT, Alan Bateman wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test >> libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Movin

Re: RFR: 8346986: Remove ASM from java.base

2025-01-07 Thread David Holmes
On Tue, 7 Jan 2025 12:49:40 GMT, Adam Sotona wrote: > There are no more consumers of ASM library except for hotspot tests. > This patch moves ASM library from java.base module to the hotspot test > libraries location and fixes the tests. > > Please review. > > Thanks, > Adam Test libraries be

Re: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history [v2]

2025-01-06 Thread David Holmes
On Mon, 6 Jan 2025 21:20:58 GMT, Chen Liang wrote: >> `javax.lang.model.SourceVersion` has a series of comments describing the new >> language features present in each source version. Similar comments for the >> `ClassFileFormatVersion` would be helpful, so readers no longer need to >> search

Re: RFR: 8346773: Fix unmatched brackets in some misc files [v3]

2025-01-05 Thread David Holmes
On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing wrote: >> This patch fixes unmatched brackets in some files, mostly in comments, docs >> and man pages. > > Qizheng Xing has updated the pull request incrementally with one additional > commit since the last revision: > > Revert fix in the CTW M

Re: RFR: 8345782: Refining the cases that libjsig deprecation warning is issued

2025-01-05 Thread David Holmes
On Wed, 18 Dec 2024 09:12:55 GMT, Joakim Nordström wrote: > Could I get a review of this fix to refine the warnings printed by `libjsig` > when using the deprecated `signal()`/`sigset()` functions? > > Currently the libjsig library supports chaining `signal()` and `sigset()`. > With these fun

Re: RFR: 8346132: fallbacklinker.c failed compilation due to unused variable

2024-12-18 Thread David Holmes
On Tue, 17 Dec 2024 21:43:09 GMT, Calvin Cheung wrote: > A simple fix for removing an unused variable in fallbacklinker.cpp. This is > needed for building zero jvm variant on macosx-x64. > > Testing: > > - [x] tier1 > - [x] zero jvm variant build on macosx-x64 Okay on addressing the error han

Re: RFR: 8346132: fallbacklinker.cpp failed compilation due to unused variable

2024-12-17 Thread David Holmes
On Tue, 17 Dec 2024 21:43:09 GMT, Calvin Cheung wrote: > A simple fix for removing an unused variable in fallbacklinker.cpp. This is > needed for building zero jvm variant on macosx-x64. > > Testing: > > - [x] tier1 > - [x] zero jvm variant build on macosx-x64 Changes requested by dholmes (Re

Re: RFR: 8346120: VirtualThreadPinned event recorded for Object.wait may have wrong duration or may record second event [v4]

2024-12-16 Thread David Holmes
On Mon, 16 Dec 2024 12:17:17 GMT, Alan Bateman wrote: >> A jdk.VirtualPinnedEvent JFR event is recorded by Object::wait when a >> virtual thread waits in Object.wait while pinned. The posting of the event >> in ObjectMonitor::wait is done after waiting but it can block again in >> enter/Reente

  1   2   3   4   5   6   7   8   9   10   >