On Wed, 25 Dec 2024 07:46:00 GMT, Amit Kumar wrote:
> This is breaking s390x build. Would you please added below patch :)
Maybe `testbit_16` isn't the rbest name. Perhaps `testbit_ushort` is better?
-
PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2562014053
On Thu, 19 Dec 2024 12:52:34 GMT, Coleen Phillimore wrote:
>> Please review this change that makes AccessFlags and modifier_flags u2 types
>> and removes the last remnants of Hotspot adding internal access flags. This
>> change moves AccessFlags and modifier_flags in Klass to alignment gaps
>
On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes)
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
>> previ
On Tue, 22 Oct 2024 15:48:43 GMT, Andrew Haley wrote:
>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60:
>>
>>> 58:
>>> 59: assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use
>>> fast_lock_lightweight");
&
On Tue, 22 Oct 2024 15:37:23 GMT, Andrew Haley 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
On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo
wrote:
> * We copy the oops stored in the LockStack of the carrier to the
> stackChunk when freezing (and clear the LockStack). We copy the oops back to
> the LockStack of the next carrier when thawing for the first time (and clear
On Tue, 22 Oct 2024 15:48:43 GMT, Andrew Haley wrote:
>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60:
>>
>>> 58:
>>> 59: assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use
>>> fast_lock_lightweight");
&
On Tue, 22 Oct 2024 02:14: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 change
On Tue, 22 Oct 2024 15:37:23 GMT, Andrew Haley wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with six
>> additional commits since the last revision:
>>
>> - Fix comments in objectMonitor.hpp
>> - Move frame::saved_thread_address
On Tue, 22 Oct 2024 02:14: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 change
On Tue, 22 Oct 2024 02:14: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 change
On Wed, 21 Aug 2024 13:18:03 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All
>> changes in this PR are protected by this flag. The purpose of t
On Tue, 20 Aug 2024 10:07:26 GMT, Roman Kennke wrote:
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All
> changes in this PR are protected by this flag. The purpose of the fl
On Tue, 20 Aug 2024 10:07:26 GMT, Roman Kennke wrote:
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All
> changes in this PR are protected by this flag. The purpose of the fl
On Fri, 12 Jul 2024 09:40:45 GMT, Roman Kennke wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update arguments.cpp
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343:
>
>> 341: const R
On Fri, 19 Apr 2024 07:44:17 GMT, Richard Reingruber wrote:
>> An alternative for preemptively switching the W^X thread mode on macOS with
>> an AArch64 CPU. This implementation triggers the switch in response to the
>> SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this
>>
On Sat, 13 Apr 2024 18:16:21 GMT, Thomas Stuefe wrote:
> I have one question, and I'm sorry if it has been answered before. How
> expensive is changing the mode? Is it just a status variable in user-space
> pthread lib? Or does it need a system call?
>
> In other words, how fine granular can w
On Fri, 12 Apr 2024 14:50:46 GMT, Vladimir Kempik wrote:
> Hello Sergey. W^X mode was initially forced by Apple to prevent writing to
> executable memory, as a security feature. This change just eliminates this
> security feature at all, doesn't it ? Basically: "want to write to Executable
> m
On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber wrote:
>> This pr changes `JfrJvmtiAgent::retransform_classes()` and
>> `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>>
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>> TEST_VM_OPTS=
On Tue, 19 Mar 2024 15:17:50 GMT, Thomas Stuefe wrote:
> > Not necessarily. It may well remove some transitions from paths that don't
> > need it, but if you move the state change too low down the call chain you
> > could end up transitioning much more often in code that does need it e.g.
> >
On Tue, 19 Mar 2024 04:37:41 GMT, David Holmes wrote:
> That said we have had a lot of people looking at the overall WX state
> management logic in the past week or so due to
> https://bugs.openjdk.org/browse/JDK-8327860. The workaround there requires us
> to be in EXEC mode
That's very odd.
On Tue, 30 Jan 2024 12:01:56 GMT, Ioi Lam wrote:
> The only "perfect" solution is putting the HotSpot code in a namespace. This
> is going to be a huge undertaking. I don't think we have enough interest in
> the OpenJDK community to make such a change now.
I don't think that putting all of the
On Tue, 30 Jan 2024 04:20:21 GMT, Jiangli Zhou wrote:
> > > Maybe we could live with symbol redefinition using #define (conditionally
> > > for static linking in OpenJDK, as Coleen suggested earlier) for now,
> > > until the tooling can support symbol localizing better. Then localizing
> > > s
On Wed, 24 Jan 2024 22:30:38 GMT, Jiangli Zhou wrote:
> Maybe we could live with symbol redefinition using #define (conditionally for
> static linking in OpenJDK, as Coleen suggested earlier) for now, until the
> tooling can support symbol localizing better. Then localizing symbols using
> too
On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou wrote:
> Please review this PR with a simple solution for resolving duplicate `Thread`
> symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there
> was an alternative suggestion to redefine the symbol at build time, such as
> us
On Fri, 19 Jan 2024 20:21:21 GMT, Jiangli Zhou wrote:
> > You could support one build by adding something like -DSUPPORTS_STATIC_LINK
> > for both .so and .a builds for Google, then use that to protect the
> > renaming.
>
> Thanks, @coleenp. I think that could work for all different cases. I'l
On Fri, 19 Jan 2024 02:09:15 GMT, Jiangli Zhou wrote:
> > > It seems that we may be converging on using hotspot namespace?
> >
> >
> > Based on previous discussions I had been expecting to see a JEP on this
> > after last US summer. I was surprised to see this PR pop up in this form.
>
> Ah,
On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou wrote:
> Please review this PR with a simple solution for resolving duplicate `Thread`
> symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there
> was an alternative suggestion to redefine the symbol at build time, such as
> us
On Tue, 3 Oct 2023 17:53:27 GMT, Daniel D. Daugherty wrote:
> Trivial fixes to ProblemList noisy tests in the JDK22 CI;
>
> [JDK-8317446](https://bugs.openjdk.org/browse/JDK-8317446) ProblemList
> gc/arguments/TestNewSizeFlags.java on macosx-aarch64 in Xcomp
> [JDK-8317448](https://bugs.openjdk
On Thu, 7 Sep 2023 16:58:38 GMT, Andrew Haley wrote:
> This PR fixes a specific problem caused by using r29/rfp to unwind Java code.
> For some time we have treated r29 as a callee-saved scratch register, and it
> is freely used by C2-generated code. Therefore, any code in SA
ome to grief.
>
> I believe this is the root cause of 8313800, but it's very hard to prove that
> because because it's something of an intermittent fault.
Andrew Haley has updated the pull request incrementally with three additional
commits since the last revision:
- Revert
On Tue, 12 Sep 2023 05:58:28 GMT, Fei Yang wrote:
> Neither can I reproduce this issue on linux-riscv64 platform with jdk/jdk
> tip. But it has the same settings for the x8/fp register and context, I guess
> it also bears the same problem.
Yes, I'm sure it does.
-
PR Comment: htt
ome to grief.
>
> I believe this is the root cause of 8313800, but it's very hard to prove that
> because because it's something of an intermittent fault.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Duplicated
On Thu, 7 Sep 2023 21:31:24 GMT, Chris Plummer wrote:
>> This PR fixes a specific problem caused by using r29/rfp to unwind Java
>> code. For some time we have treated r29 as a callee-saved scratch register,
>> and it is freely used by C2-generated code. Therefore, any code in SA that
>> uses
… frame when invoking LambdaForms is involved
-
Commit messages:
- 8313800: AArch64: SA stack walking code having trouble finding sender frame
when invoking LambdaForms is involved
Changes: https://git.openjdk.org/jdk/pull/15624/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&
On Mon, 7 Aug 2023 20:17:21 GMT, Chris Plummer wrote:
> Make sure when walking the stack that the "sender" frame is not at a lower or
> the same address as the current frame, which can result in an infinite loop.
>
> Tested with tier1 and stress testing sun/tools/jhsdb and
> hotspot/jtreg/serv
On Wed, 7 Jun 2023 21:03:47 GMT, Kelvin Nilsen wrote:
> We would like to thank everyone who has taken time to review and provide
> feedback on our pull request. Given the risks identified during the review
> process and the lack of time available to perform the thorough review that
> such a la
On Tue, 6 Jun 2023 19:48:05 GMT, Paul Hohensee wrote:
> We'd like to propose to push now, and tackle/fix the single-gen issue you
> identified during RDP1, as well as any other significant single-gen
> regressions that may come up. We have four Shen experts on board, Roman,
> Aleksey, Kelvin,
On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>> `-XX:+UnlockExp
On Fri, 2 Jun 2023 02:49:25 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>> `-XX:+UnlockExp
On Fri, 26 May 2023 20:46:29 GMT, Kelvin Nilsen wrote:
> OpenJDK Colleagues:
>
> Please review this proposed integration of Generational mode for Shenandoah
> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>
> Generational mode of Shenandoah is enabled by adding
> `-XX:+UnlockExperimen
On Tue, 30 May 2023 00:57:40 GMT, David Holmes wrote:
> Can we now poison NULL so it can't get reintroduced? Or would that
> potentially break standard headers?
I'm sure it would. Maybe some changes to Skara?
-
PR Comment: https://git.openjdk.org/jdk/pull/14198#issuecomment-157170
On Fri, 24 Mar 2023 15:13:40 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>>
On Thu, 23 Mar 2023 15:37:27 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>>
On Thu, 23 Mar 2023 15:37:27 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>>
On Wed, 22 Mar 2023 17:42:35 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>>
On Tue, 21 Mar 2023 17:40:46 GMT, Richard Reingruber wrote:
>> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2337:
>>
>>> 2335: // Load-acquire the adapter method
>>> 2336: __ lea(method, Address(cache,
>>> in_bytes(ResolvedIndyEntry::method_offset(;
>>> 2337: __ ldar(method,
On Mon, 20 Mar 2023 14:29:35 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>>
On Tue, 17 Jan 2023 08:35:45 GMT, Fredrik Bredberg wrote:
>> Implementation of relativized locals in interpreter frames for x86. x64,
>> arm, aarch64, ppc64le and riscv.
>> Not relativized locals on zero and s390 but done some changes to cope with
>> the changed generic code.
>> Tested tier1-ti
On Tue, 17 Jan 2023 08:35:45 GMT, Fredrik Bredberg wrote:
>> Implementation of relativized locals in interpreter frames for x86. x64,
>> arm, aarch64, ppc64le and riscv.
>> Not relativized locals on zero and s390 but done some changes to cope with
>> the changed generic code.
>> Tested tier1-ti
On Mon, 14 Nov 2022 08:28:04 GMT, Thomas Stuefe wrote:
> unfortunately, your patch will make backporting more difficult. We cannot
> downport it to older releases compiled with older compilers. But since it
> touches a lot of files it will sit smack in the middle of patch sequences,
> requirin
51 matches
Mail list logo
