On Wed, 22 May 2024 14:28:41 GMT, Yudi Zheng wrote:
>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4693:
>>
>>> 4691: const Register xlen = r1;
>>> 4692: const Register z = r2;
>>> 4693: const Register zlen = r3;
>>
>> LibraryCallKit::inline_squareToLen() is still c
On Mon, 10 Jun 2024 12:12:58 GMT, Shaojin Wen wrote:
> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into
> primitive arrays by combining values into larger stores.
>
> This PR rewrites the code of appendNull and append(boolean) methods so that
> these two methods c
On Tue, 23 Jan 2024 13:04:43 GMT, SendaoYan wrote:
>> 8323640: [TESTBUG]testMemoryFailCount in
>> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail
>> because OOM killed
>
> SendaoYan has updated the pull request incrementally with one additional
> commit since the last rev
On Thu, 9 May 2024 13:51:09 GMT, Coleen Phillimore wrote:
> This change stores InstanceKlass for interface and abstract classes in the
> non-class metaspace, since class metaspace will have limits on number of
> classes that can be represented when Lilliput changes go in. Classes that
> have
On Thu, 22 Aug 2024 05:47:23 GMT, Tobias Hartmann wrote:
>> Greetings,
>>
>> Please help review this change set that implements C2 intrinsics for
>> jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
>>
>> This work is a consequence of
>> [JDK-8338417](https://bugs.o
On Thu, 22 Aug 2024 15:50:32 GMT, Vladimir Kozlov wrote:
>> It is updated to use Action::none to keep the nmethod. The trap code picks
>> up the correct bytecode (invokestatic) from the trap scope. So after
>> unrolling the host method (the inliner), the trap bytecode (i.e., the
>> invokestati
On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley wrote:
> JEP 429 implementation.
src/hotspot/share/prims/jvm.cpp line 1410:
> 1408: loc = 3;
> 1409: } else if (method == resolver.thread_run_method) {
> 1410: loc = 2;
This depends on how javac numbers locals, right? It seems a bi
On Fri, 4 Nov 2022 09:53:39 GMT, Andrew Haley wrote:
>> src/java.base/share/classes/java/lang/Thread.java line 1610:
>>
>>> 1608: ensureMaterializedForStackWalk(bindings);
>>> 1609: task.run();
>>> 1610: Reference.reachabilityFence(bindings);
>>
>> This shoul
On Thu, 24 Nov 2022 14:05:41 GMT, Andrew Haley wrote:
>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Unused variable
src/hotspot/cpu/aarch64/aarch64.ad line 3635:
> 3633: }
> 3634: }
On Thu, 24 Nov 2022 14:05:41 GMT, Andrew Haley wrote:
>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Unused variable
src/hotspot/share/classfile/javaClasses.cpp line 1731:
> 1729: }
> 1730:
>
On Thu, 24 Nov 2022 14:05:41 GMT, Andrew Haley wrote:
>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Unused variable
src/hotspot/share/prims/jvm.cpp line 1385:
> 1383: vframeStream vfst(threa
On Thu, 24 Nov 2022 14:05:41 GMT, Andrew Haley wrote:
>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Unused variable
I made a few minor suggestions, but overall the HotSpot changes look good.
On Tue, 29 Nov 2022 11:49:10 GMT, Andrew Haley wrote:
>> Andrew Haley has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Unused variable
>
> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java
> line 385:
>
On Wed, 22 Feb 2023 05:21:48 GMT, Joe Darcy wrote:
>> I'm also a bit concerned that we are rushing in to "fix" this. IIUC we have
>> three mechanisms for implementing this functionality:
>>
>> 1. The interpreted Java code
>> 2. The compiled non-intrinisc sharedRuntime code
>> 3. The compiler in
trig
>> functions are handled that @jddarcy mentioned.
>
> Good point. We can't guarantee that all OpenJDK ports HW do the same.
>
> If CPU has corresponding instructions we need to generate a stub during VM
> startup with HW instructions and use it in all cases (or directly
On Wed, 8 Mar 2023 05:17:53 GMT, Vladimir Kozlov wrote:
>> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in
>> Interpreter and C1 compiler to produce the same results as C2 intrinsics on
>> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java
>>
On Tue, 12 Mar 2024 10:44:54 GMT, Yudi Zheng wrote:
> Moving array construction within BigInteger.implMultiplyToLen intrinsic
> candidate to its caller simplifies the intrinsic implementation in JIT
> compiler.
src/hotspot/share/opto/library_call.cpp line 5934:
> 5932: // 'y_start' points
On Tue, 19 Mar 2024 19:06:36 GMT, Yudi Zheng wrote:
>> Moving array construction within BigInteger.implMultiplyToLen intrinsic
>> candidate to its caller simplifies the intrinsic implementation in JIT
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional
>
On Tue, 19 Mar 2024 19:06:36 GMT, Yudi Zheng wrote:
>> Moving array construction within BigInteger.implMultiplyToLen intrinsic
>> candidate to its caller simplifies the intrinsic implementation in JIT
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional
>
On Wed, 3 Apr 2024 15:15:24 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall performance
On Wed, 3 Apr 2024 15:15:24 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall performance
On Sat, 6 Apr 2024 00:13:26 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall performance
On Mon, 8 Apr 2024 19:11:19 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall performance
On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng wrote:
>> Moving array construction within BigInteger.implMultiplyToLen intrinsic
>> candidate to its caller simplifies the intrinsic implementation in JIT
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional
>
On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng wrote:
>> Moving array construction within BigInteger.implMultiplyToLen intrinsic
>> candidate to its caller simplifies the intrinsic implementation in JIT
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional
>
On Wed, 17 Apr 2024 19:45:02 GMT, Dean Long wrote:
>> Yudi Zheng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> address comment.
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4702:
>
On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng wrote:
>> Moving array construction within BigInteger.implMultiplyToLen intrinsic
>> candidate to its caller simplifies the intrinsic implementation in JIT
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional
>
On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng wrote:
>> Moving array construction within BigInteger.implMultiplyToLen intrinsic
>> candidate to its caller simplifies the intrinsic implementation in JIT
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional
>
On Tue, 29 Oct 2024 00:04:09 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 Mon, 28 Oct 2024 21:13:33 GMT, Patricio Chilano Mateo
wrote:
>> If preemption was cancelled, we skip over the cleanup. The native frames
>> haven't been unwound yet. So when we call thaw, does it cleanup the native
>> frames first, or does it copy the frames back on top of the existing fr
On Mon, 28 Oct 2024 20:49:45 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382:
>>
>>> 2380: __ bind(after_transition);
>>> 2381:
>>> 2382: if (LockingMode != LM_LEGACY && method->is_object_wait0()) {
>>
>> It bothers me that we have to add a che
On Mon, 28 Oct 2024 18:56:58 GMT, Patricio Chilano Mateo
wrote:
>> The issue with the c2 runtime stub on aarch64 (and riscv) is that
>> cb->frame_size() doesn't match the size of the physical frame, it's short by
>> 2 words. I explained the reason for that in the comment above. So for a
>> re
On Mon, 28 Oct 2024 18:58:29 GMT, Patricio Chilano Mateo
wrote:
> regardless of when you freeze, while doing the freezing the monitor could
> have been released already. So trying to acquire the monitor after freezing
> can always succeed, which means we don't want to unmount but continue
> e
On Mon, 28 Oct 2024 22:52:40 GMT, Coleen Phillimore wrote:
>> When creating the bitmap, processing oops in an interpreter frame is done
>> with `frame::oops_interpreted_do()` which already counts this extra oop for
>> native methods.
>
> What are we counting now with MaskFillerForNativeFrame th
On Sat, 26 Oct 2024 07:04:28 GMT, Richard Reingruber wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796:
>>
>>> 3794: __ movbool(rscratch1, Address(r15_thread,
>>> JavaThread::preemption_cancelled_offset()));
>>> 3795: __ testbool(rscratch1);
>>> 3796: __ jcc(Assembler::notZ
On Tue, 29 Oct 2024 19:04:57 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77:
>>
>>> 75: // Interpreter frames
>>> 76: interpreter_frame_result_handler_offset = 3, // for
>>> native calls only
>>> 77: interpreter_frame_oop_temp_offs
On Tue, 29 Oct 2024 00:04:09 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, 29 Oct 2024 00:04:09 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, 30 Oct 2024 00:44:14 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 22:12:56 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/cpu/x86/interp_masm_x86.cpp line 359:
>>
>>> 357: push_cont_fastpath();
>>> 358:
>>> 359: // Make VM call. In case of preemption set last_pc to the one we
>>> want to resume to.
>>
>> From the comment, it soun
On Wed, 30 Oct 2024 00:44:14 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 18:57:38 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, 29 Oct 2024 18:57:38 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 00:04:09 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, 30 Oct 2024 00:44:14 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 00:04:09 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, 29 Oct 2024 00:04:09 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 Fri, 1 Nov 2024 19:37:14 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 Wed, 30 Oct 2024 22:44:48 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, 30 Oct 2024 22:44:48 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, 30 Oct 2024 22:44:48 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, 30 Oct 2024 22:44:48 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, 30 Oct 2024 22:44:48 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, 29 Oct 2024 19:01:03 GMT, Patricio Chilano Mateo
wrote:
>>> One way to get rid of this would be to have c2 just set last_Java_pc too
>>> along with last_Java_sp, so we don't need to push lr to be able to do
>>> last_Java_sp[-1] to make the frame walkable.
>>
>> If that would solve the
On Wed, 30 Oct 2024 22:44:48 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, 29 Oct 2024 22:15:16 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/code/nmethod.cpp line 1302:
>>
>>> 1300: _compiler_type = type;
>>> 1301: _orig_pc_offset = 0;
>>> 1302: _num_stack_arg_slots = 0;
>>
>> Was the old value wrong, unneeded, or
On Fri, 1 Nov 2024 07:14:35 GMT, Dean Long wrote:
>>> OK, so you're saying it's the stack adjustment that's the problem. It
>>> sounds like there is code that is using rsp instead of last_Java_sp to
>>> compute the frame boundary. Isn't that a
On Sat, 26 Oct 2024 06:51:08 GMT, Richard Reingruber wrote:
>> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555:
>>
>>> 1553: // Make VM call. In case of preemption set last_pc to the one we
>>> want to resume to.
>>> 1554: adr(rscratch1, resume_pc);
>>> 1555: str(rscratch1, Addr
On Sat, 26 Oct 2024 06:56:50 GMT, Richard Reingruber wrote:
>> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567:
>>
>>> 1565:
>>> 1566: // In case of preemption, this is where we will resume once we
>>> finally acquire the monitor.
>>> 1567: bind(resume_pc);
>>
>> If the idea is
On Mon, 28 Oct 2024 17:30:44 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159:
>>
>>> 157:
>>> 158: // The interpreter native wrapper code adds space in the stack equal
>>> to size_of_parameters()
>>> 159: // after the fixed
On Mon, 28 Oct 2024 16:39:14 GMT, Coleen Phillimore wrote:
>> src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119:
>>
>>> 117: return mask.num_oops()
>>> 118: + 1 // for the mirror oop
>>> 119: + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp
On Fri, 25 Oct 2024 21:33:24 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 Mon, 28 Oct 2024 20:58:33 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 Sat, 26 Oct 2024 00:27:25 GMT, Dean Long wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Restore use of atPointA in test StopThreadTest.java
>> - remove interrupt
On Fri, 25 Oct 2024 21:33:24 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 Fri, 25 Oct 2024 21:33:24 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 Fri, 25 Oct 2024 21:33:24 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 Fri, 25 Oct 2024 21:33:24 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, 30 Oct 2024 22:11:38 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/runtime/continuation.hpp line 50:
>>
>>> 48: class JavaThread;
>>> 49:
>>> 50: // should match Continuation.PreemptStatus() in Continuation.java
>>
>> As far as I can tell, these enum values still don't match
On Wed, 30 Oct 2024 22:44:48 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 Thu, 31 Oct 2024 16:27:05 GMT, Patricio Chilano Mateo
wrote:
>> OK, so you're saying it's the stack adjustment that's the problem. It
>> sounds like there is code that is using rsp instead of last_Java_sp to
>> compute the frame boundary. Isn't that a bug that should be fixed? I also
>>
On Wed, 30 Oct 2024 22:44:48 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, 30 Oct 2024 22:44:48 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, 30 Oct 2024 22:44:48 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 Mon, 28 Oct 2024 20:49:45 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382:
>>
>>> 2380: __ bind(after_transition);
>>> 2381:
>>> 2382: if (LockingMode != LM_LEGACY && method->is_object_wait0()) {
>>
>> It bothers me that we have to add a che
On Mon, 28 Oct 2024 21:13:33 GMT, Patricio Chilano Mateo
wrote:
>> If preemption was cancelled, we skip over the cleanup. The native frames
>> haven't been unwound yet. So when we call thaw, does it cleanup the native
>> frames first, or does it copy the frames back on top of the existing fr
On Fri, 25 Oct 2024 21:33:24 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 Fri, 25 Oct 2024 21:33:24 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 Fri, 25 Oct 2024 21:33:24 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 Fri, 25 Oct 2024 21:33:24 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:18:19 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300:
>>
>>> 298: CodeBlob* cb = top.cb();
>>> 299:
>>> 300: if (cb->frame_size() == 2) {
>>
>> Is this a filter to identify c2 runtime stubs? Is there
On Fri, 25 Oct 2024 18:34:16 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 Fri, 25 Oct 2024 21:33:24 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 Fri, 25 Oct 2024 21:33:24 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 Fri, 25 Oct 2024 21:33:24 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
1 - 100 of 127 matches
Mail list logo
