On Mon, 12 May 2025 23:19:58 GMT, Serguei Spitsyn wrote:
> The tests `SuspendResume1`, `SuspendResume2` and `SuspendResumeAll` are
> intermittently failed with a timeout (deadlock). The tests run with
> `-Djdk.virtualThreadScheduler.maxPoolSize=1` so there is only one carrier.
> The short slee
On Wed, 30 Apr 2025 12:00:45 GMT, Robbin Ehn wrote:
>> Hi, for you to consider.
>>
>> These tests constantly fails in qemu-user.
>> Either the require host to be same arch explicit or implicit (sysroot).
>> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not
>> implemented'" for SA
On Wed, 30 Apr 2025 11:57:32 GMT, Robbin Ehn wrote:
> I don't see any alternatives - if this approach is not liked, any suggestions?
The changes seems fine to me. It's just a pity that this would only work for
riscv for now.
I guess we don't have a better choice given current status of qemu-use
On Mon, 31 Mar 2025 10:45:54 GMT, Robbin Ehn wrote:
>> Hi, for you to consider.
>>
>> These tests constantly fails in qemu-user.
>> Either the require host to be same arch explicit or implicit (sysroot).
>> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not
>> implemented'" for SA
On Wed, 9 Apr 2025 06:31:55 GMT, Robbin Ehn wrote:
> > > It's not some intermittently failure. The majority of them can't work as
> > > they use pstack, open core files, use PerfData, etc.. and expected it to
> > > be rv64. But core files, pstack are in host arch as we are running
> > > qemu-u
On Fri, 28 Mar 2025 06:53:15 GMT, Robbin Ehn wrote:
> It's not some intermittently failure. The majority of them can't work as they
> use pstack, open core files, use PerfData, etc.. and expected it to be rv64.
> But core files, pstack are in host arch as we are running qemu-user. I can
> remo
On Tue, 25 Mar 2025 14:19:55 GMT, Robbin Ehn wrote:
> Hi, for you to consider.
>
> These tests constantly fails in qemu-user.
> Either the require host to be same arch or they are very very slow in
> emulation.
> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'"
> f
On Wed, 15 Jan 2025 08:23:57 GMT, SendaoYan wrote:
> Hi all,
> We observed the test serviceability/sa/TestJhsdbJstackMixed.java intermittent
> fails on linux-riscv64. Should we problemlist this test before the root cause
> has been fixed.
But I never see this failure on SBCs like BPI-F3, Unmat
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 th
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 Thu, 31 Oct 2024 20:02:31 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273:
>>
>>> 271: ? frame_sp + fsize - frame::sender_sp_offset
>>> 272: // we need to re-read fp because it may be an oop and we might
>>> have f
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 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 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 th
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 Thu, 31 Oct 2024 20:02:31 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273:
>>
>>> 271: ? frame_sp + fsize - frame::sender_sp_offset
>>> 272: // we need to re-read fp because it may be an oop and we might
>>> have f
On Sat, 31 Aug 2024 12:25:49 GMT, Yasumasa Suenaga wrote:
>> src/hotspot/cpu/x86/upcallLinker_x86_64.cpp line 397:
>>
>>> 395: * and also should include both saved FP and
>>> return address
>>> 396: */
>>> 397: (frame_
On Sat, 31 Aug 2024 04:21:17 GMT, Yasumasa Suenaga wrote:
>> I attempted to check stack trace in the core generated by [SEGV example in
>> upcall](https://github.com/YaSuenag/garakuta/blob/841452d9176dab1ddbb552009c180530eb81190b/NativeSEGV/ffm/upcall/src/main/java/com/yasuenag/garakuta/nativese
On Fri, 23 Aug 2024 18:42:28 GMT, Hamlin Li wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix bit counts in GCForwarding
>
> src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp line 170:
>
>> 168: mv(tmp1, (int3
On Fri, 29 Mar 2024 19:35:45 GMT, Vladimir Kozlov wrote:
> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE
> [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365)
> which was used for AOT [JEP 295](https://openjdk.org/jeps/295)
> implem
On Wed, 27 Sep 2023 09:07:23 GMT, Fredrik Bredberg
wrote:
>> Relativize initial_sp in interpreter frames.
>>
>> By changing the "initial_sp" (AKA "monitor_block_top" or "monitors" on
>> PowerPC) member in interpreter frames from being an absolute address into an
>> offset that is relative to
On Tue, 26 Sep 2023 12:01:34 GMT, Fredrik Bredberg
wrote:
> The "Updated after review" version contains the following changes.
>
> 1. The extra space in `interp_masm_riscv.cpp` was removed.
I see `shadd` added in other files are not covered? They have similar issues.
Looks good otherwise. Tha
On Wed, 20 Sep 2023 08:52:09 GMT, Fei Yang wrote:
> Hi, I have arranged tier1-3 test on linux-riscv64 platform. Thanks for adding
> handling for riscv.
Tier1-3 test is clean. The riscv part looks good except for the nit.
-
PR Comment: https://git.openjdk.org/jdk/pull
On Tue, 19 Sep 2023 09:00:01 GMT, Fredrik Bredberg
wrote:
> Relativize initial_sp in interpreter frames.
>
> By changing the "initial_sp" (AKA "monitor_block_top" or "monitors" on
> PowerPC) member in interpreter frames from being an absolute address into an
> offset that is relative to the f
On Wed, 13 Sep 2023 11:53:39 GMT, Feilong Jiang wrote:
> Hi, please consider.
> Inspired by [JDK-8313800](https://bugs.openjdk.org/browse/JDK-8313800).
> RISC-V also treats x8/fp as a callee-saved scratch register for some time,
> and it is freely used by C2-generated code. Therefore, any code
On Fri, 8 Sep 2023 12:34:39 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 that
>> uses g
On Thu, 10 Aug 2023 14:01:25 GMT, Feilong Jiang wrote:
> Hi, inspired by [JDK-8247351](https://bugs.openjdk.org/browse/JDK-8247351),
> this patch fixes a VMReg encoding issue in `RISCV64Frame.java`. As the VMReg
> has two slots in a 64-bit VM, the encoding of `fp` should be `8 << 1` instead
>
On Mon, 8 May 2023 12:47:51 GMT, Stefan Karlsson wrote:
> That's unfortunate. Could you try this patch, which probes the address range
> to see if it can reserve the memory somewhere else within `[ZAddressHeapBase,
> ZAddressHeapBase+ZAddressOffsetMax)`:
> https://github.com/stefank/jdk/tree/z
On Fri, 5 May 2023 06:50:55 GMT, Stefan Karlsson wrote:
>> We emailed to erik to discuss this issue two months ago, and maybe he missed
>> it.
>> ZForwardingTest does not guarantee a successful invoke of os::commit_memory
>> for ZAddressHeapBase, and we saw some conflicts between ZAddressHeapBa
On Thu, 4 May 2023 11:44:14 GMT, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review the implementation of Generational ZGC, which can be turned on
>> by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational
>> ZGC is a major rewrite of the non-generational ZGC version tha
On Mon, 17 Apr 2023 20:10:38 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Wed, 5 Apr 2023 16:17:44 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Wed, 5 Apr 2023 16:17:44 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Sun, 2 Apr 2023 21:41:47 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Mon, 27 Mar 2023 14:43:04 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 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 Tue, 14 Mar 2023 18:46:47 GMT, Roman Kennke wrote:
>> I've reviewed the changes in v23 and v24. Trying another
>> Mach5 Tier1 job set.
>
>> I've reviewed the changes in v23 and v24. Trying another Mach5 Tier1 job set.
>
> I just now pushed a simple change that changes the log message
> 'infl
On Mon, 13 Mar 2023 18:43:41 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Thu, 19 Jan 2023 09:13:42 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 Fri, 28 Oct 2022 20:17:37 GMT, Roman Kennke wrote:
> This change adds a fast-locking scheme as an alternative to the current
> stack-locking implementation. It retains the advantages of stack-locking
> (namely fast locking in uncontended code-paths), while avoiding the overload
> of the mar
On Wed, 11 Jan 2023 09:22:03 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 Sat, 12 Nov 2022 08:08:15 GMT, Fei Yang wrote:
>> The current loom code makes some assumptions about GC that will not work
>> with generational ZGC. We should make this code more GC agnostic, and
>> provide a better interface for talking to the GC.
>>
>> In pa
On Fri, 11 Nov 2022 16:16:18 GMT, Erik Österlund wrote:
> The current loom code makes some assumptions about GC that will not work with
> generational ZGC. We should make this code more GC agnostic, and provide a
> better interface for talking to the GC.
>
> In particular,
> 1) All GCs have a
On Fri, 11 Nov 2022 19:41:56 GMT, Erik Österlund wrote:
> Nice to have PR 1. It's gonna take a long time until we see 11.
Nice PR number :-)
May I ask if you could also add handling for riscv while you are at it? We have
ported loom to this platform recently [1].
[1] https://git.openjd
On Fri, 14 Oct 2022 15:39:41 GMT, Roman Kennke wrote:
>>> > > > > > Here is the basic support for RISC-V:
>>> > > > > > https://cr.openjdk.java.net/~shade/8291555/riscv-patch-1.patch
>>> > > > > > -- I adapted this from AArch64 changes, and tested it very
>>> > > > > > lightly. @RealFYang, can
On Fri, 14 Oct 2022 14:39:01 GMT, Roman Kennke wrote:
> > > > > > Here is the basic support for RISC-V:
> > > > > > https://cr.openjdk.java.net/~shade/8291555/riscv-patch-1.patch
> > > > > > -- I adapted this from AArch64 changes, and tested it very lightly.
> > > > > > @RealFYang, can I leave
On Fri, 14 Oct 2022 14:26:20 GMT, Roman Kennke wrote:
> > > > Here is the basic support for RISC-V:
> > > > https://cr.openjdk.java.net/~shade/8291555/riscv-patch-1.patch
> > > > -- I adapted this from AArch64 changes, and tested it very lightly.
> > > > @RealFYang, can I leave the testing and
On Fri, 14 Oct 2022 01:19:27 GMT, Fei Yang wrote:
> > Here is the basic support for RISC-V:
> > https://cr.openjdk.java.net/~shade/8291555/riscv-patch-1.patch
> > -- I adapted this from AArch64 changes, and tested it very lightly.
> > @RealFYang, can I leave the testin
On Wed, 12 Oct 2022 11:26:16 GMT, Aleksey Shipilev wrote:
> Here is the basic support for RISC-V:
> https://cr.openjdk.java.net/~shade/8291555/riscv-patch-1.patch
>
> -- I adapted this from AArch64 changes, and tested it very lightly.
> @RealFYang, can I leave the testing and follow up fixes t
49 matches
Mail list logo
