On Mon, 24 Feb 2025 19:30:41 GMT, Coleen Phillimore wrote:
>> Class.isInterface() can check modifier flags, Class.isArray() can check
>> whether component mirror is non-null and Class.isPrimitive() needs a new
>> final transient boolean in java.lang.Class that the JVM code initializes.
>> Teste
On Fri, 21 Feb 2025 14:01:20 GMT, Chen Liang wrote:
>> I don't use the field directly because the field is a short and getModifiers
>> makes it into Modifier.
>
> Indeed, even though this checks for the specific bit so widening has no
> effect, it is better to be cautious here.
> I don't use t
On Wed, 19 Feb 2025 14:19:58 GMT, Coleen Phillimore wrote:
> ... but not in the return since the caller likely will fetch the klass
> pointer next.
I notice that too. Callers are using is_primitive() to short-circuit calls to
as_Klass(), which means they seem to be aware of this implementatio
On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore wrote:
> Class.isInterface() can check modifier flags, Class.isArray() can check
> whether component mirror is non-null and Class.isPrimitive() needs a new
> final transient boolean in java.lang.Class that the JVM code initializes.
> Tested wi
On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore wrote:
> Class.isInterface() can check modifier flags, Class.isArray() can check
> whether component mirror is non-null and Class.isPrimitive() needs a new
> final transient boolean in java.lang.Class that the JVM code initializes.
> Tested wi
On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore wrote:
> Class.isInterface() can check modifier flags, Class.isArray() can check
> whether component mirror is non-null and Class.isPrimitive() needs a new
> final transient boolean in java.lang.Class that the JVM code initializes.
> Tested wi
On Wed, 12 Feb 2025 12:05:22 GMT, Coleen Phillimore wrote:
>> src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 59:
>>
>>> 57: Reflection.class, ALL_MEMBERS,
>>> 58: AccessibleObject.class, ALL_MEMBERS,
>>> 59: Class.class, Set.of("classLoa
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 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 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 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 Fri, 15 Nov 2024 01:05:10 GMT, ExE Boss wrote:
>> Doesn't this break any apps that use these offsets? Aren't these fields
>> part of the public API of Unsafe, so changing them requires a CSR?
>
> @dean-long
>> Doesn't this break any apps that use
On Fri, 15 Nov 2024 01:04:58 GMT, Shaojin Wen wrote:
>> The type of the Unsafe base offset constant is int, which may cause overflow
>> when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027)
>> fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are
>> st
On Thu, 14 Nov 2024 05:32:34 GMT, Shaojin Wen wrote:
> The type of the Unsafe base offset constant is int, which may cause overflow
> when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027)
> fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are
> still
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 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 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 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 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 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 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 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, 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
1 - 100 of 127 matches
Mail list logo
