On Mon, 4 Nov 2024 18:18:38 GMT, Patricio Chilano Mateo
wrote:
>> Here's my suggested C2 change:
>>
>> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad
>> b/src/hotspot/cpu/aarch64/aarch64.ad
>> index d9c77a2f529..1e99db191ae 100644
>> --- a/src/hotspot/cpu/aarch64/aarch64.ad
>> +++ b/src/hotsp
On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the changes
Hi all,
The copyright year of some files which has been changed by
[JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692) wasn't update
correctly. This PR update the copyright year of
[JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692). Trivial fix, no
risk.
-
Commit m
On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the changes
On Mon, 4 Nov 2024 09:24:13 GMT, Stefan Karlsson wrote:
>> If I recall correctly this was a bug where one of the stackChunk fields was
>> allocated in that gap, but since we didn't zeroed it out it would start with
>> some invalid value. I guess the reason why we are not hitting this today is
On Mon, 4 Nov 2024 05:52:16 GMT, Alan Bateman wrote:
>> src/hotspot/share/classfile/javaClasses.cpp line 2107:
>>
>>> 2105:
>>> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) {
>>> 2107: return vthread->long_field(_timeout_offset);
>>
>> Not sure what motivated the name change
On Tue, 5 Nov 2024 00:23:37 GMT, Fei Yang wrote:
>>> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I
>>> suggested to change the literal 2 into `frame::sender_sp_offset` in order
>>> to increase the readability, but I forgot that `frame::sender_sp_offset` is
>>> 0 on ri
> This is the implementation of JEP 491: Synchronize Virtual Threads without
> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
> further details.
>
> In order to make the code review easier the changes have been split into the
> following initial 4 commits:
>
> - Change
On Tue, 5 Nov 2024 00:20:56 GMT, Vladimir Ivanov wrote:
> Looks good.
>
> Stylistic comment: while browsing the code a mix of "AOT" & "aot" caught my
> eye. I find the former spelling more descriptive. Any particular reason to
> use "aot" unless all lowercase spelling is preferred in some part
On Tue, 5 Nov 2024 00:18:17 GMT, Fei Yang wrote:
>>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in
>>> all of the lines (267, 271 and 273) should be reverted?
>>>
>> I think the previous lines are okay because we are constructing the fp,
>> whereas in here we want t
On Mon, 4 Nov 2024 23:57:48 GMT, Ioi Lam wrote:
>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://openjdk.org/jeps/483).
>>
>>
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https:
On Mon, 4 Nov 2024 18:23:23 GMT, Patricio Chilano Mateo
wrote:
>> Sorry, I also thought it matched the aarch64 one without checking.
>> @RealFYang should I change it for `hf.sp() + frame::link_offset` or just
>> leave it as it was?
>
>> Also, does this mean that the changes from 2 to frame::se
On Mon, 4 Nov 2024 14:21:09 GMT, Dan Heidinga wrote:
>> I think this is already done:
>>
>> `runtimeSetup()` is called inside `InstanceKlass::call_class_initializer()`.
>> When that returns, we will proceed to
>> `InstanceKlass::set_initialization_state_and_notify()` which will perform
>> the
> This is an implementation of [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://openjdk.org/jeps/483).
>
>
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.co
On Mon, 4 Nov 2024 03:15:25 GMT, Ioi Lam wrote:
>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://openjdk.org/jeps/483).
>>
>>
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https:
On Thu, 31 Oct 2024 20:13:08 GMT, Justin Lu wrote:
> Please review this PR which is a JNI cleanup to replace incorrect usages of
> `jthrowable ExceptionOccurred(JNIEnv *env)` with `jboolean
> ExceptionCheck(JNIEnv *env)` in _jdk.jdwp.agent_.
>
> This is part of the bigger umbrella issue:
> ht
On Thu, 31 Oct 2024 20:13:08 GMT, Justin Lu wrote:
> Please review this PR which is a JNI cleanup to replace incorrect usages of
> `jthrowable ExceptionOccurred(JNIEnv *env)` with `jboolean
> ExceptionCheck(JNIEnv *env)` in _jdk.jdwp.agent_.
>
> This is part of the bigger umbrella issue:
> ht
On Mon, 4 Nov 2024 18:18:23 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the changes
On Thu, 31 Oct 2024 19:54:20 GMT, Justin Lu wrote:
> Please review this PR which is a JNI cleanup to replace incorrect usages of
> `jthrowable ExceptionOccurred(JNIEnv *env)` with `jboolean
> ExceptionCheck(JNIEnv *env)` in _jdk.hotspot.agent_.
>
> This is part of the bigger umbrella issue:
>
On Thu, 31 Oct 2024 20:14:43 GMT, Justin Lu wrote:
>> Please review this PR which is a JNI cleanup to replace incorrect usages of
>> `jthrowable ExceptionOccurred(JNIEnv *env)` with `jboolean
>> ExceptionCheck(JNIEnv *env)` in _jdk.hotspot.agent_.
>>
>> This is part of the bigger umbrella issu
On Tue, 29 Oct 2024 22:58:31 GMT, Dean Long wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix comment in VThreadWaitReenter
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 316:
>
>> 314:
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
On Mon, 4 Nov 2024 20:29:23 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
> This PR merges JEP 404, a generational mode for the Shenandoah garbage
> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would
> like to target JDK24 with this PR.
William Kemper has updated the pull request with a new target base due to a
merge or a rebase. The pull r
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
On Mon, 4 Nov 2024 19:27:59 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
On Mon, 4 Nov 2024 18:22:42 GMT, Patricio Chilano Mateo
wrote:
>> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64,
>> which is different from aarch64 or x86-64. So I think we should revert this
>> change:
>> https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf
On Mon, 4 Nov 2024 18:18:23 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the changes
This test is sensitive to timing, and should not run with -Xcomp (like
NotifReconnectDeadlockTest.java).
With -Xcomp, this test can fail on the the conn.getDefaultDomain() call, but if
we handle that, it can also fail on the first iteration through the loop, at
the call: JMXConnector client = J
On Fri, 25 Oct 2024 04:40:24 GMT, David Holmes wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Rename set/has_owner_anonymous to set/has_anonymous_owner
>> - Fix comments in javaThread.hpp and Thread.
On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang wrote:
>> Changed.
>
> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which
> is different from aarch64 or x86-64. So I think we should revert this change:
> https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f
On Fri, 1 Nov 2024 20:08:51 GMT, Dean Long wrote:
>> It turns out if we try to set last pc to the instruction after the
>> adjustment, then we need an oopmap there, and that would require more C2
>> changes. Then I thought about restoring SP from FP or last_Java_fp, but I
>> don't think we ca
> This is the implementation of JEP 491: Synchronize Virtual Threads without
> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
> further details.
>
> In order to make the code review easier the changes have been split into the
> following initial 4 commits:
>
> - Change
On Sun, 3 Nov 2024 20:19:47 GMT, Jiangli Zhou wrote:
> Please review this trivial fix that adds missing DEF_STATIC_JNI_OnLoad in
> libjimage and libsaproc native libraries. Thanks.
This pull request has now been integrated.
Changeset: 774de278
Author:Jiangli Zhou
URL:
https://git.o
On Mon, 4 Nov 2024 00:28:46 GMT, Jiangli Zhou wrote:
>> Please review this trivial fix that adds missing DEF_STATIC_JNI_OnLoad in
>> libjimage and libsaproc native libraries. Thanks.
>
> Jiangli Zhou has updated the pull request incrementally with one additional
> commit since the last revision
On Mon, 4 Nov 2024 17:31:00 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Mon, 4 Nov 2024 14:52:06 GMT, Robert Toyonaga wrote:
>>>This include is not needed because there are no uses that require the
>>>definition of Thread.
>>
>> Right, seems like the forward declaration used to be provided by
>> `memory/allocation.hpp`. Let's get rid of the include and use a fo
On Mon, 4 Nov 2024 17:16:49 GMT, Vladimir Kozlov wrote:
>>> > With that said, it is sure as heck confusing! Which also apparently
>>> > Microsoft acknowledges by phasing in the term "Windows API". So I agree
>>> > that we should try to rename everything currently called "win32" into
>>> > "win
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
On Fri, 1 Nov 2024 18:11:13 GMT, Vladimir Kozlov wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove superfluous check for 64-bit on Windows in
>> MacroAssembler::call_clobbered_xmm_registers
>> - Remo
On Mon, 4 Nov 2024 17:08:40 GMT, Magnus Ihse Bursie wrote:
>>> With that said, it is sure as heck confusing! Which also apparently
>>> Microsoft acknowledges by phasing in the term "Windows API". So I agree
>>> that we should try to rename everything currently called "win32" into
>>> "windows"
On Mon, 4 Nov 2024 17:01:33 GMT, Vladimir Kozlov wrote:
> > With that said, it is sure as heck confusing! Which also apparently
> > Microsoft acknowledges by phasing in the term "Windows API". So I agree
> > that we should try to rename everything currently called "win32" into
> > "windows". B
On Mon, 4 Nov 2024 09:45:05 GMT, Thomas Stuefe wrote:
> Can we get rid of `JNICALL` too, please?
That we can never do, since it is part of jni.h which are imported in likely
millions of JNI projects. But we can replace it with an empty define. And we
can document it as not needed anymore, and
On Mon, 4 Nov 2024 16:04:12 GMT, Magnus Ihse Bursie wrote:
> With that said, it is sure as heck confusing! Which also apparently Microsoft
> acknowledges by phasing in the term "Windows API". So I agree that we should
> try to rename everything currently called "win32" into "windows". But I'd
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
On Mon, 4 Nov 2024 09:58:49 GMT, Kim Barrett wrote:
>> There is a difference between "working" and not causing a build failure. I
>> suspect none of that code is actually needed these days, but I'm not sure.
>> As deleting the entire section goes beyond deleting 32-bit code, I would
>> expect
On Mon, 4 Nov 2024 09:45:05 GMT, Thomas Stuefe wrote:
>>> Can we get rid of `JNICALL` too, please?
>>>
>>> Or would that change be too big?
>>
>> There's >1000 in java.base, lots more elsewhere, so it would be a lot of
>> files and would hide the core changes. So maybe for a follow-up PR that
On Sat, 2 Nov 2024 07:51:20 GMT, Alexander Zuev wrote:
>> make/modules/jdk.accessibility/Lib.gmk line 57:
>>
>>> 55: TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE)
>>> 56:
>>> 57:
>>> ##
>>
>> Most of the desktop related
On Mon, 4 Nov 2024 07:53:48 GMT, Johan Sjölen wrote:
>> src/hotspot/share/runtime/mutexLocker.hpp line 31:
>>
>>> 29: #include "runtime/flags/flagSetting.hpp"
>>> 30: #include "runtime/mutex.hpp"
>>> 31: #include "runtime/thread.hpp"
>>
>> This include is not needed because there are no uses th
On Mon, 4 Nov 2024 09:02:10 GMT, David Holmes wrote:
>> This is mostly an audit of the callers of `Exceptions::fthrow` to ensure
>> unbounded strings can't appear.
>>
>> There is a code change in DiagnosticCmd parsing to extend the string length
>> limit already used in part of that code.
>>
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
On Mon, 4 Nov 2024 03:08:02 GMT, Ioi Lam wrote:
>> src/hotspot/share/cds/aotClassInitializer.cpp line 348:
>>
>>> 346: }
>>> 347: JavaValue result(T_VOID);
>>> 348: JavaCalls::call_static(&result, ik,
>>
>> Based on the discussions in JDK-8342283, do we need a memory fence after the
On Tue, 29 Oct 2024 14:09:21 GMT, Simon Tooke wrote:
>> Looking good, small nits remain. Could you share an example output (maybe
>> one run with G1, one with ZGC?)
>
>> Looking good, small nits remain. Could you share an example output (maybe
>> one run with G1, one with ZGC?)
>
> @tstuefe, S
On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang wrote:
>> Changed.
>
> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which
> is different from aarch64 or x86-64. So I think we should revert this change:
> https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f
On Mon, 4 Nov 2024 00:28:46 GMT, Jiangli Zhou wrote:
>> Please review this trivial fix that adds missing DEF_STATIC_JNI_OnLoad in
>> libjimage and libsaproc native libraries. Thanks.
>
> Jiangli Zhou has updated the pull request incrementally with one additional
> commit since the last revision
On Mon, 21 Oct 2024 21:16:50 GMT, William Kemper wrote:
>> This PR merges JEP 404, a generational mode for the Shenandoah garbage
>> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We
>> would like to target JDK24 with this PR.
>
> William Kemper has updated the pull reques
On Mon, 4 Nov 2024 09:11:16 GMT, David Holmes wrote:
>> The deletion is apparently working, else we'd be getting build failures. So
>> while there are some potential issues and opportunities for further cleanup
>> in
>> this file, I think they ought to be addressed separately from this PR. See
>
On Mon, 4 Nov 2024 09:28:50 GMT, Alan Bateman wrote:
> > Can we get rid of `JNICALL` too, please?
> > Or would that change be too big?
>
> There's >1000 in java.base, lots more elsewhere, so it would be a lot of
> files and would hide the core changes. So maybe for a follow-up PR that does
> t
On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Mon, 4 Nov 2024 09:21:52 GMT, Thomas Stuefe wrote:
> Can we get rid of `JNICALL` too, please?
>
> Or would that change be too big?
There's >1000 in java.base, lots more elsewhere, so it would be a lot of files
and would hide the core changes. So maybe for a follow-up PR that does the one
t
On Wed, 30 Oct 2024 23:14:53 GMT, Patricio Chilano Mateo
wrote:
>> This might confuse the change for JEP 450 since with CompactObjectHeaders
>> there's no klass_gap, so depending on which change goes first, there will be
>> conditional code here. Good question though, it looks like we only eve
On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Mon, 4 Nov 2024 09:00:59 GMT, Kim Barrett wrote:
>> src/hotspot/share/adlc/adlc.hpp line 43:
>>
>>> 41:
>>> 42: /* Make sure that we have the intptr_t and uintptr_t definitions */
>>> 43: #ifdef _WIN32
>>
>> As this is a synonym for `_WINDOWS` it is not obvious this deletion is
>> correct.
On Mon, 4 Nov 2024 02:34:13 GMT, David Holmes wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove superfluous check for 64-bit on Windows in
>> MacroAssembler::call_clobbered_xmm_registers
>> - Remove
> This is mostly an audit of the callers of `Exceptions::fthrow` to ensure
> unbounded strings can't appear.
>
> There is a code change in DiagnosticCmd parsing to extend the string length
> limit already used in part of that code.
>
> Testing:
> - tier 1-3 (sanity)
>
> Thanks
David Holmes h
On Mon, 4 Nov 2024 07:21:19 GMT, Axel Boldt-Christmas
wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use lazySubmitRunContinuation when blocking
>
> src/java.base/share/classes/jdk/internal/vm/Continuat
74 matches
Mail list logo
