On Wed, 11 Sep 2024 21:02:41 GMT, Matias Saavedra Silva
wrote:
>> This patch cleans up the use of `get_new_method()` so callers don't have to
>> worry about throwing `NoSuchMethodError`. The method is refactored to throw
>> the error and avoid ever returning nullptr. Verified with tier1-5 test
On Thu, 12 Sep 2024 13:00:49 GMT, Coleen Phillimore wrote:
> If we have NSME on the stack and do a GC and the arguments aren't collected
> but not used (but consumed because we clear the expression stack (?)) could
> this cause a problem?
Clearing the expression stack in the callee (NSME) does
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: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 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 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 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 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: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, 18 Sep 2024 19:00:52 GMT, Coleen Phillimore wrote:
> resolved_indy_entries.method is the adapter method which can't be deleted, we
> could add an assert about that.
OK, please do.
If CallInfo::resolved_method() can return an old method, then it could also
return a deleted method, whic
On Wed, 11 Sep 2024 21:02:41 GMT, Matias Saavedra Silva
wrote:
>> This patch cleans up the use of `get_new_method()` so callers don't have to
>> worry about throwing `NoSuchMethodError`. The method is refactored to throw
>> the error and avoid ever returning nullptr. Verified with tier1-5 test
On Wed, 11 Sep 2024 21:02:41 GMT, Matias Saavedra Silva
wrote:
>> This patch cleans up the use of `get_new_method()` so callers don't have to
>> worry about throwing `NoSuchMethodError`. The method is refactored to throw
>> the error and avoid ever returning nullptr. Verified with tier1-5 test
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 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
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 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 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 Thu, 17 Oct 2024 14:28:30 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 hav
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 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 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 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 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 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 Sat, 26 Oct 2024 00:27:25 GMT, Dean Long 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 revie
On Tue, 7 Jan 2025 02:36:36 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 Tue, 7 Jan 2025 02:36:36 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 Tue, 7 Jan 2025 02:36:36 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 Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore wrote:
>> The Class.getModifiers() method is implemented as a native method in
>> java.lang.Class to access a field that we've calculated when creating the
>> mirror. The field is final after that point. The VM doesn't need it
>> anymore, so
On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore wrote:
>> The Class.getModifiers() method is implemented as a native method in
>> java.lang.Class to access a field that we've calculated when creating the
>> mirror. The field is final after that point. The VM doesn't need it
>> anymore, so
On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore wrote:
>> The Class.getModifiers() method is implemented as a native method in
>> java.lang.Class to access a field that we've calculated when creating the
>> mirror. The field is final after that point. The VM doesn't need it
>> anymore, so
On Thu, 12 Dec 2024 10:16:01 GMT, Viktor Klang wrote:
>> @viktorklang-ora `@Stable` is not about how the field was set, but about the
>> JIT observing a non-default value at compile time. If it observes a
>> non-default value, it can treat it as a compile time constant.
>
> @DanHeidinga Great
On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore wrote:
>> The Class.getModifiers() method is implemented as a native method in
>> java.lang.Class to access a field that we've calculated when creating the
>> mirror. The field is final after that point. The VM doesn't need it
>> anymore, so
On Wed, 5 Feb 2025 14:41:39 GMT, Albert Mingkun Yang wrote:
>> Here is an attempt to simplify GCLocker implementation for Serial and
>> Parallel.
>>
>> GCLocker prevents GC when Java threads are in a critical region (i.e.,
>> calling JNI critical APIs). JDK-7129164 introduces an optimization t
On Wed, 5 Feb 2025 19:42:02 GMT, Coleen Phillimore wrote:
>> test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java line 73:
>>
>>> 71: public int getAppArrayModifiers() {
>>> 72: return clazzArray.getClass().getModifiers();
>>> 73: }
>>
>> I'm guessing this is the benchmark
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 Fri, 20 Dec 2024 13:17:17 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
>
101 - 200 of 210 matches
Mail list logo
