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
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
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
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
]: 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
, 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
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
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
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
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
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
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
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`
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`
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
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`
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
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
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
>>
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
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.
-
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
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
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
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()
>>
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
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
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
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
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
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
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
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.
---
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 "
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 - 100 of 936 matches
Mail list logo