On Wed, 30 Aug 2023 13:56:42 GMT, Alan Bateman wrote:
> In the virtual thread implementation, thread identity switches to the carrier
> before freezing and switches back to the virtual thread after thawing. This
> was a forced move due to issues getting JVMTI to work with virtual threads.
> JV
On Thu, 31 Aug 2023 10:37:26 GMT, Markus Grönlund wrote:
>> In the virtual thread implementation, thread identity switches to the
>> carrier before freezing and switches back to the virtual thread after
>> thawing. This was a forced move due to issues getting JVMTI to work with
>> virtual thre
On Mon, 18 Sep 2023 23:00:09 GMT, Mandy Chung wrote:
> `JVM_MoreStackWalk` has a bug that always assumes that the Java frame
> stream is currently at the frame decoded in the last patch and so always
> advances to the next frame before filling in the new batch of stack frame.
> However `JVM_MoreS
On Thu, 21 Sep 2023 18:20:36 GMT, Mandy Chung wrote:
>> `JVM_MoreStackWalk` has a bug that always assumes that the Java frame
>> stream is currently at the frame decoded in the last patch and so always
>> advances to the next frame before filling in the new batch of stack frame.
>> However `JVM_M
On Fri, 24 Nov 2023 18:30:17 GMT, Erik Österlund wrote:
>> The current logic for closing memory in panama today is susceptible to live
>> lock if we have a closing thread that wants to close the memory in a loop
>> that keeps failing, and a bunch of accessing threads that want to perform
>> ac
On Tue, 2 Jan 2024 08:55:37 GMT, Alan Bateman wrote:
> Missed by JDK-8312498, VirtualThread::tryGetStackTrace doesn't handle the
> TIMED_PINNED state so it's possible for Thread::getStackTrace to throw
> InternalError when invoked on a virtual thread that quickly transitions from
> unmounted t
On Thu, 4 Jan 2024 11:51:47 GMT, Alan Bateman wrote:
> This test was recently added by JDK-8322818. On some test systems, the test
> passes a bit after the timeout so the test is marked as failed. The changes
> here dial down the iterations from 100k to 25k to reduce the execution time
> for r
On Thu, 11 Jan 2024 13:09:39 GMT, Serguei Spitsyn wrote:
>> The notification method `VirtualThread.notifyJvmtiDisableSuspend` should be
>> static.
>> The method disables/enables suspend of the current virtual thread, a no-op
>> if the current thread is a platform thread. It is confusing for thi
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 have been split into the
following initial 4 commits:
- Changes to allow unmou
On Fri, 18 Oct 2024 00:09:59 GMT, David Holmes 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 have been
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Fri, 18 Oct 2024 04:21:57 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/runtime/javaThread.hpp line 165:
>>
>>> 163: // ID used as owner for inflated monitors. Same as the
>>> j.l.Thread.tid of the
>>> 164: // current _vthread object, e
On Mon, 21 Oct 2024 08:01:09 GMT, Andrey Turbanov wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Adjust spacing in test JfrEvents.java
>> - Adjust comment in Java
On Mon, 21 Oct 2024 06:38:28 GMT, Axel Boldt-Christmas
wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with six
>> additional commits since the last revision:
>>
>> - Fix comments in objectMonitor.hpp
>> - Move frame::saved_thread_a
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Mon, 21 Oct 2024 07:57:31 GMT, Axel Boldt-Christmas
wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with six
>> additional commits since the last revision:
>>
>> - Fix comments in objectMonitor.hpp
>> - Move frame::saved_thread_a
On Tue, 22 Oct 2024 13:51:26 GMT, Axel Boldt-Christmas
wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with six
>> additional commits since the last revision:
>>
>> - Fix comments in objectMonitor.hpp
>> - Move frame::saved_thread_a
On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/cpu/x86/assembler_x86.cpp line 2866:
>>
>>> 2864: emit_int32(0);
>>> 2865: }
>>> 2866: }
>>
>> Is it possible to make this more general and explicit instead
On Tue, 22 Oct 2024 11:51:47 GMT, Alan Bateman wrote:
>> src/hotspot/share/runtime/javaThread.cpp line 1545:
>>
>>> 1543: if (is_vthread_mounted()) {
>>> 1544: // _lock_id is the thread ID of the mounted virtual thread
>>> 1545: st->print_cr(" Carrying virtual thread #" INT64_F
On Tue, 22 Oct 2024 06:27:26 GMT, David Holmes wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with six
>> additional commits since the last revision:
>>
>> - Fix comments in objectMonitor.hpp
>> - Move frame::saved_thread_address
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Tue, 22 Oct 2024 06:31:47 GMT, David Holmes wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with six
>> additional commits since the last revision:
>>
>> - Fix comments in objectMonitor.hpp
>> - Move frame::saved_thread_address
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Mon, 28 Oct 2024 23:59:55 GMT, Patricio Chilano Mateo
wrote:
>> So it sounds like the adjustment at line 119 is a bug fix, but what I don't
>> understand is why we weren't seeing problems before. Something in this PR
>> exposed the need for this change.
>
&
On Mon, 28 Oct 2024 23:21:14 GMT, Dean Long wrote:
>> What are we counting now with MaskFillerForNativeFrame that we weren't
>> counting before this change? in MaskFillerForNative::set_one.
>
> So it sounds like the adjustment at line 119 is a bug fix, but what I don't
> understand is why we w
On Mon, 28 Oct 2024 00:35:11 GMT, David Holmes wrote:
>> This vthread was unmounted on the call to `Object.wait`. Now it is mounted
>> and "running" again, and we need to check which case it is in: notified,
>> interrupted or timed-out. "First time" means it is the first time it's
>> running a
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Thu, 24 Oct 2024 05:10:56 GMT, David Holmes wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Fix comment in objectMonitor.hpp and javaThread.hpp
>> - Skip printing
On Thu, 24 Oct 2024 02:55:18 GMT, David Holmes wrote:
>>> Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id
>>> to use for locking" - correct?
>>>
>> Yes.
>
> I guess I don't understand where this piece code fits in the overall
> transition of the virtual thread to being
On Thu, 24 Oct 2024 06:18:10 GMT, David Holmes wrote:
>> So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the
>> BasicLock* in there as before since it can clash with some other thread's
>> tid. We store it in the new field _stack_locker instead.
>
> Right I understand w
On Tue, 29 Oct 2024 10:06:01 GMT, Fredrik Bredberg
wrote:
>> Right. We want to take the slow path to find the compiled native wrapper
>> frame and fail to freeze. Otherwise the fast path won't find it since we
>> don't walk the stack.
>
> It would be nice if Coleen's question and your answer c
On Tue, 29 Oct 2024 01:59:35 GMT, Dean Long wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix comment in VThreadWaitReenter
>
> src/hotspot/cpu/aarch64/templateInterpr
On Tue, 29 Oct 2024 20:39:44 GMT, Dean Long wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve comment in SharedRuntime::generate_native_wrapper
>
> src/hotspot/s
On Mon, 28 Oct 2024 21:07:47 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
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Tue, 29 Oct 2024 21:32:44 GMT, Dean Long wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix comment in VThreadWaitReenter
>
> src/hotspot/share/oops/method.cpp line 870
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Mon, 28 Oct 2024 23:46:09 GMT, Dean Long 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
> > executi
On Mon, 28 Oct 2024 23:38:43 GMT, Dean Long wrote:
>>> Could the problem be solved with a resume adapter instead, like the
>>> interpreter uses?
>>>
>> It will just move the task of adjusting the size of the frame somewhere else.
>
>> One way to get rid of this would be to have c2 just set last_
On Tue, 29 Oct 2024 08:29:55 GMT, David Holmes wrote:
>> It's conceivable that in the future we might have more native methods we
>> want to preempt. Instead of enumerating them all, we could set a flag on
>> the method.
>>
>> I was assuming that David was suggesting we have the Java caller d
On Tue, 29 Oct 2024 01:42:09 GMT, Dean Long wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix comment in VThreadWaitReenter
>
> src/hotspot/cpu/aarch64/frame
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Mon, 28 Oct 2024 08:34:14 GMT, Alan Bateman wrote:
> This is an update to the Virtual thread implementation that we'd like to
> integrate in advance of JEP 491.
>
> The update removes the use of "temporary transitions", basically cases where
> the thread identity switches to the carrier th
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Fri, 1 Nov 2024 20:08:51 GMT, Dean Long wrote:
>> It turns out if we try to set last pc to the instruction after the
>> adjustment, then we need an oopmap there, and that would require more C2
>> changes. Then I thought about restoring SP from FP or last_Java_fp, but I
>> don't think we ca
On Tue, 29 Oct 2024 22:58:31 GMT, Dean Long wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix comment in VThreadWaitReenter
>
> src/hotspot/share/runtime/continuationFree
On Mon, 4 Nov 2024 18:22:42 GMT, Patricio Chilano Mateo
wrote:
>> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64,
>> which is different from aarch64 or x86-64. So I think we should revert this
>> change:
>> https://github.com/openjd
On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang wrote:
>> Changed.
>
> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which
> is different from aarch64 or x86-64. So I think we should revert this change:
> https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f
On Fri, 25 Oct 2024 04:40:24 GMT, David Holmes wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Rename set/has_owner_anonymous to set/has_anonymous_owner
>> - Fix
On Tue, 5 Nov 2024 01:47:29 GMT, Patricio Chilano Mateo
wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with five
>> additional commits since the last revision:
>>
>> - Add oopDesc::has_klass_gap() check
>> - Rename waitTim
On Tue, 5 Nov 2024 07:51:05 GMT, Erik Gahlin wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with five
>> additional commits since the last revision:
>>
>> - Add oopDesc::has_klass_gap() check
>> - Rename waitTimeout/set_wait
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Tue, 5 Nov 2024 06:30:55 GMT, Fei Yang wrote:
>> Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code.
>> @RealFYang I made the equivalent change for riscv, could you verify it's
>> okay?
>
> @pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup!
On Tue, 5 Nov 2024 08:19:34 GMT, Alan Bateman wrote:
>> src/hotspot/share/jfr/metadata/metadata.xml line 160:
>>
>>> 158:
>>> 159:
>>> 160:
>>
>> Previously, the event was in the "Java Application" category. I think that
>> was a better fit because it meant it was visualized in the sa
On Tue, 5 Nov 2024 00:23:37 GMT, Fei Yang wrote:
>>> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I
>>> suggested to change the literal 2 into `frame::sender_sp_offset` in order
>>> to increase the readability, but I forgot that `frame::sender_sp_offset` is
>>> 0 on ri
On Mon, 4 Nov 2024 05:52:16 GMT, Alan Bateman wrote:
>> src/hotspot/share/classfile/javaClasses.cpp line 2107:
>>
>>> 2105:
>>> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) {
>>> 2107: return vthread->long_field(_timeout_offset);
>>
>> Not sure what motivated the name change
On Mon, 4 Nov 2024 09:24:13 GMT, Stefan Karlsson wrote:
>> If I recall correctly this was a bug where one of the stackChunk fields was
>> allocated in that gap, but since we didn't zeroed it out it would start with
>> some invalid value. I guess the reason why we are not hitting this today is
On Tue, 5 Nov 2024 01:40:15 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 m
On Mon, 4 Nov 2024 18:18:23 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to m
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Mon, 4 Nov 2024 20:55:07 GMT, Serguei Spitsyn wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Update comment block in objectMonitor.cpp
>> - Fix issue with unmount
On Tue, 5 Nov 2024 23:50:29 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/runtime/continuation.cpp line 134:
>>
>>> 132: return true;
>>> 133: }
>>> 134: #endif // INCLUDE_JVMTI
>>
>> Could you, please, consider the simplificati
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Tue, 5 Nov 2024 11:35:29 GMT, Serguei Spitsyn wrote:
> Is this posted after the VirtualThreadMount extension event posted?
>
It's posted before. We post the mount event at the end of thaw only if we are
able to acquire the monitor:
https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005
On Tue, 5 Nov 2024 23:58:39 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/runtime/objectMonitor.cpp line 1643:
>>
>>> 1641: // actual callee (see nmethod::preserve_callee_argument_oops()).
>>> 1642: ThreadOnMonitorWaitedEvent tmwe(current
On Tue, 5 Nov 2024 14:35:11 GMT, Axel Boldt-Christmas
wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with five
>> additional commits since the last revision:
>>
>> - Add oopDesc::has_klass_gap() check
>> - Rename waitTim
On Tue, 29 Oct 2024 02:56:30 GMT, Serguei Spitsyn wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix comment in VThreadWaitReenter
>
> src/hotspot/share/prims/jvmtiEnv
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Wed, 30 Oct 2024 09:44:42 GMT, Serguei Spitsyn wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Add klass_name check for is_object_wait0
>> - Fix comment in continua
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
> General no
On Fri, 1 Nov 2024 15:21:50 GMT, Axel Boldt-Christmas
wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - add comment to ThreadService::find_deadlocks_at_safepoint
>> - Remo
On Thu, 31 Oct 2024 20:28:06 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line
>> 57:
>>
>>> 55: static {
>>> 56: try {
>>> 57:
>>> MethodHandles.lookup().ensureInitialized(AnchorCertificates.class);
>>
>> Why is th
On Mon, 28 Oct 2024 09:19:48 GMT, Alan Bateman wrote:
>> Thanks for the explanation but that needs to be documented somewhere.
>
> The comment in afterYield has been expanded in the loom repo, we may be able
> to bring that update in.
Brought the comment from the loom repo.
-
PR R
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Tue, 29 Oct 2024 20:57:48 GMT, Dean Long wrote:
>> No, it just happens to be stored at the sender_sp marker. We were already
>> making room for two words but only using one.
>
> `sender_sp_offset` is listed under "All frames", but I guess that's wrong and
> should be changed. Can we fix the
On Wed, 30 Oct 2024 19:06:58 GMT, Coleen Phillimore wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Add klass_name check for is_object_wait0
>> - Fix comment in continua
On Wed, 30 Oct 2024 00:52:32 GMT, Dean Long wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Add klass_name check for is_object_wait0
>> - Fix comment in continuati
On Tue, 29 Oct 2024 23:05:20 GMT, Dean Long wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix comment in VThreadWaitReenter
>
> src/hotspot/share/runtime/continuationFree
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Wed, 30 Oct 2024 01:52:30 GMT, Dean Long wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - SmallRegisterMap::instance() fix + comment typo
>> - Add comment in call_
On Mon, 21 Oct 2024 09:55:53 GMT, Axel Boldt-Christmas
wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Rename oopCont + fix in JvmtiUnmountBeginMark
>
On Wed, 30 Oct 2024 19:02:05 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411:
>>
>>> 1409: // zero out fields (but not the stack)
>>> 1410: const size_t hs = oopDesc::header_size();
>>> 1411: oopDesc::set_klass_gap(mem, 0);
>>
>> Why,
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Fri, 1 Nov 2024 01:53:01 GMT, David Holmes wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - add comment to ThreadService::find_deadlocks_at_safepoint
>> - Remove as
On Mon, 21 Oct 2024 12:32:00 GMT, Axel Boldt-Christmas
wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Rename timedWaitNonce to timedWaitSeqNo
>> - Fix comment in Thr
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Tue, 22 Oct 2024 07:03:48 GMT, David Holmes wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with six
>> additional commits since the last revision:
>>
>> - Fix comments in objectMonitor.hpp
>> - Move frame::saved_thread_address
On Wed, 23 Oct 2024 11:32:54 GMT, Alan Bateman wrote:
>> Suggestion: `timedWaitCounter` ?
>
> We could rename it to timedWaitSeqNo if needed.
Ok, renamed to timedWaitSeqNo.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813240667
On Sat, 26 Oct 2024 00:30: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 Mon, 28 Oct 2024 11:59:57 GMT, Coleen Phillimore wrote:
>> The thread passed in need not be the current thread, and IIUC is the thread
>> that should become the owner of the newly inflated monitor (either current
>> thread or a suspended thread). The actual inflation is always done by the
>
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Sat, 26 Oct 2024 02:15:29 GMT, Dean Long wrote:
> > On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual
> > thread will call freeze to copy all Java frames to the heap. We will add
> > the virtual thread to the ObjectMonitor's queue and return back to Java.
> > Instead o
JavaThread*. This allows
> us to tie the owner of the monitor to a `java.lang.Thread` instance, rather
> than to a JavaThread which is only created per platform thread. The tid is
> already a 64 bit field so we can ignore issues of the counter wrapping around.
>
>
On Mon, 28 Oct 2024 17:31:45 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 188:
>>
>>> 186: // Avoid using a leave instruction when this frame may
>>> 187: // have been frozen, since the current value of rfp
>&g
On Fri, 25 Oct 2024 22:22:01 GMT, Coleen Phillimore wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Simplify set last_sp in prepare_freeze_interpreted_top_frame
>> - a
On Fri, 25 Oct 2024 21:57:01 GMT, Coleen Phillimore 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 interr
On Sat, 26 Oct 2024 00:17:33 GMT, Dean Long wrote:
>It sounds like freeze/thaw isn't preserving FP, even though it is a
>callee-saved register according to the ABI. If the stubs tried to modify FP
>(or any other callee-saved register) and use that value after the native call,
>wouldn't that be
On Mon, 28 Oct 2024 18:56:25 GMT, Patricio Chilano Mateo
wrote:
>> Could the problem be solved with a resume adapter instead, like the
>> interpreter uses?
>
> The issue with the c2 runtime stub on aarch64 (and riscv) is that
> cb->frame_size() doesn't match t
1 - 100 of 243 matches
Mail list logo
