On Wed, 6 Nov 2024 13:52:32 GMT, Per Minborg wrote:
> This PR proposes to add additional text for the `@param charset` tags in the
> `MemorySegment.(get|set)String` overloads that take a `charset`.
>
> This PR does not need a CSR, as the specs already state that an exception
> will be thrown
On Mon, 21 Oct 2024 14:25:06 GMT, Raffaello Giulietti
wrote:
> This helps in reducing memory consumption, especially for long inputs.
src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1875:
> 1873: } // look for and process decimal floating-point string
> 187
On Wed, 6 Nov 2024 11:24:23 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>> i
On Wed, 6 Nov 2024 14:27:15 GMT, Sean Coffey wrote:
> This looks good to me.
>
> I'd suggest logging a new JBS issue to track removal of the
> Debug.getInstance("pkcs12") use case and substituting it with
> getInstance("keystore") code (esp. since pkcs12 is now the default keystore
> type)
N
On Wed, 6 Nov 2024 11:24:23 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>> i
> Using SharedSecrets, I attempted to expose FileInputStream::path information.
> After implementing the fix, I validated the startup performance tests.
> Observed no consistent pattern of performance drops or gains, can disregard
> the occasional performance drop observed in 1 or 2 runs.
Prasa
On Sun, 20 Oct 2024 06:41:46 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which does a tiny cleanup in the
> macosx specific code in `java_props_macosx.c`?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8342647 the
> `setOSNameAndVersion` function used to dynamicall
On Thu, 7 Nov 2024 00:37:17 GMT, Patricio Chilano Mateo
wrote:
>> Thank you for the comment! I'm okay with your modified suggestion in general
>> if there are no road blocks.
>>
>>> but does the specs say the event has to be posted in the context of the
>>> vthread?
>>
>> As Alan said below
On Wed, 6 Nov 2024 15:57:55 GMT, Serguei Spitsyn wrote:
> The two extension events were designed to be posted when the current thread
> identity is virtual, so this behavior > needs to be considered as a bug. My
> understanding is that it is not easy to fix.
>
If we want to post the mount/unmou
On Thu, 7 Nov 2024 00:38:40 GMT, Patricio Chilano Mateo
wrote:
>>> So, it feels like it should not be a problem. I'm thinking if adding an
>>> assert at the VTMS transition end would help.
>>>
>> The problem here is that for monitorenter the top frame will not be a native
>> method, so the bai
On Thu, 7 Nov 2024 00:37:53 GMT, Patricio Chilano Mateo
wrote:
>> Great, I applied the suggested simplification. I had to update test
>> `VThreadEventTest.java` to check the stack during the mount/unmount events
>> to only count the real cases. This is because now we are getting a variable
>>
On Wed, 6 Nov 2024 16:31:24 GMT, Serguei Spitsyn wrote:
>> Regarding the pop_frame/early_ret/async_exception conditions, not checking
>> for them after we started the transition would be an issue.
>> For pop_frame/early_ret checks, the problem is that if any of them are
>> installed in `JvmtiUn
> 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:
>
> - Change
On Tue, 5 Nov 2024 14:07:12 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch makes `MemorySessionImpl.state` a `Stable` field so that liveness
>> check of non-closeable scopes such as the global scope can be elided.
>>
>> Currently, the `state` field is overloaded with 2 responsibilities, to a
On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Wed, 6 Nov 2024 15:27:16 GMT, Magnus Ihse Bursie wrote:
>> src/java.base/share/native/libjava/NativeLibraries.c line 67:
>>
>>> 65: strcat(jniEntryName, "_");
>>> 66: strcat(jniEntryName, cname);
>>> 67: }
>>
>> I would prefer this be directly inlined at the sole call (in
On Wed, 6 Nov 2024 13:52:32 GMT, Per Minborg wrote:
> This PR proposes to add additional text for the `@param charset` tags in the
> `MemorySegment.(get|set)String` overloads that take a `charset`.
>
> This PR does not need a CSR, as the specs already state that an exception
> will be thrown
On Tue, 5 Nov 2024 19:51:04 GMT, Vicente Romero wrote:
> Javac is not issuing a mandated unchecked cast warning for code like:
>
>
> import java.lang.invoke.VarHandle;
>
> class VarHandleCast {
> VarHandle vh;
> V method(Object obj) {
> return (V)vh.getAndSet(this, obj);
>
> Javac is not issuing a mandated unchecked cast warning for code like:
>
>
> import java.lang.invoke.VarHandle;
>
> class VarHandleCast {
> VarHandle vh;
> V method(Object obj) {
> return (V)vh.getAndSet(this, obj);
> }
> }
>
>
> according to the spec the return type i
On Sat, 26 Oct 2024 05:39:32 GMT, Alan Bateman wrote:
>> test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java line
>> 30:
>>
>>> 28: * by reflection API
>>> 29: * @library /test/lib/
>>> 30: * @requires vm.compMode != "Xcomp"
>>
>> If there is a problem with this te
On Tue, 29 Oct 2024 02:09:24 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 review easier the changes have been sp
On Mon, 28 Oct 2024 00:29:25 GMT, David Holmes wrote:
>> I was wondering what this was too but the _previous_owner_tid is the os
>> thread id, not the Java thread id.
>>
>>
>> $ grep -r JFR_THREAD_ID
>> jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread)
>> (JfrThreadLocal::external_thr
Hi,
The change was merged after 23 had already been branched off, so it is destined
for 24 as can be seen in the tag associated with the commit (attached).
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
From: core-libs-dev on behalf of T
Hi Daniel,
On Windows, the jpackage embeds icons in app launcher executables and
there is no reason to keep these .ico files in the app image. In [1], it
was reasonably requested not to include app launcher icons in the app
image on Windows, and that was fulfilled.
[1] https://bugs.openjdk.o
On Mon, 4 Nov 2024 07:59:22 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62:
>>
>>> 60: NATIVE(2, "Native frame or on stack"),
>>> 61: MONITOR(3, "Monitor held"),
>>> 62: CRITICAL_SECTION(4, "In critical section");
>>
>>
On Wed, 6 Nov 2024 07:31:37 GMT, Alan Bateman wrote:
>> Tim Prinzing has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> suggested changes
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java line 2:
>
>> 1: /*
>> 2: * Copyright (
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 Thu, 24 Oct 2024 22:13:27 GMT, David Holmes wrote:
>> We don't unmount the virtual thread here, we just temporarily change the
>> thread identity. You could think of this method as
>> switchIdentityToCarrierThread if that helps.
>
> Sorry to belabour this but why are we temporarily changing
On Wed, 6 Nov 2024 06:36:58 GMT, Axel Boldt-Christmas
wrote:
> A small note on `_cont_fastpath`, as it is now also used for synchronised
> native method calls (native wrapper) maybe the comment should be updated to
> reflect this.
>
> ```
> // the sp of the oldest known interpreted/call_stub
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 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
On Wed, 23 Oct 2024 05:18:10 GMT, David Holmes wrote:
>> Thread identity switches to the carrier so Thread.currentThread() is the
>> carrier thread and JavaThread._lock_id is the thread identifier of the
>> carrier. setCurrentLockId changes JavaThread._lock_id back to the virtual
>> thread's
On Thu, 24 Oct 2024 21:08:47 GMT, Patricio Chilano Mateo
wrote:
>> I guess I don't understand where this piece code fits in the overall
>> transition of the virtual thread to being parked. I would have expected the
>> LockStack to already have been moved by the time we switch identities to the
On Wed, 23 Oct 2024 20:34:48 GMT, Patricio Chilano Mateo
wrote:
>> If the virtual thread is un-mounting from the carrier, why do we need to set
>> the "lock id" back to the virtual thread's id? Sorry I'm finding this quite
>> confusing.
>>
>> Also `JavaThread::_lock_id` in the VM means "the j
On Mon, 21 Oct 2024 08:01:09 GMT, Andrey Turbanov 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 b
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 Thu, 31 Oct 2024 01:32:19 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 review easier the changes have been sp
On Wed, 23 Oct 2024 20:36:23 GMT, Patricio Chilano Mateo
wrote:
>> Sorry, I should add context on why this is needed. The problem is that
>> inside this temporal transition we could try to acquire some monitor. If the
>> monitor is not inflated we will try to use the LockStack, but the LockSta
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 Mon, 28 Oct 2024 00:38:39 GMT, David Holmes wrote:
>> I thought locking_thread there may not be the current thread for enter_for()
>> in deopt. It's the thread that should hold the lock but not the current
>> thread. But it might be different now.
>
> The thread passed in need not be the c
On Thu, 24 Oct 2024 08:26:12 GMT, Alan Bateman wrote:
>> So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have:
>>
>> RUNNING -> BLOCKING -> BLOCKED
>> BLOCKED -> UNBLOCKING -> RUNNABLE
>>
>> I'm just trying to get a better sense of what we can infer if we see these
>> "transitio
On Wed, 23 Oct 2024 06:11:26 GMT, David Holmes wrote:
>> Sequence number, nouce, anything will work here as it's just to deal with
>> the scenario where the timeout task for a previous wait may run concurrently
>> with a subsequent wait.
>
> Suggestion: `timedWaitCounter` ?
We could rename it
On Tue, 22 Oct 2024 12:31:24 GMT, Alan Bateman wrote:
>> Okay but
>> 1. We have the current virtual thread
>> 2. We have the current carrier for that virtual thread (which is iotself a
>> java.alng.Thread object
>> 3. We have Thread.setCurrentLockId which ... ? which thread does it update?
On Thu, 24 Oct 2024 02:47:14 GMT, David Holmes wrote:
>> Not really, it is the state we set when the virtual thread is mounted and
>> runs again. In this case it will just run to re-contest for the monitor.
>
> So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have:
>
> RUNNING ->
On Tue, 22 Oct 2024 11:52:46 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/lang/VirtualThread.java line 115:
>>
>>> 113: * RUNNING -> WAITING// transitional state during wait
>>> on monitor
>>> 114: * WAITING -> WAITED // waiting on monitor
>>> 115:
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
>
On Fri, 25 Oct 2024 22:29:56 GMT, Coleen Phillimore wrote:
>>> If it's always the current thread, then it should be called 'current' imo.
>>>
>> The inflating thread is always the current one but it's not always equal to
>> `inflating_thread`.
>
> I thought locking_thread there may not be the cu
On Fri, 25 Oct 2024 18:46:52 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/runtime/objectMonitor.cpp line 2028:
>>
>>> 2026: // First time we run after being preempted on Object.wait().
>>> 2027: // Check if we were interrupted or the wait timed-out, and in
>>> 2028: // that cas
On Fri, 25 Oct 2024 21:28:22 GMT, Patricio Chilano Mateo
wrote:
>> If it's always the current thread, then it should be called 'current' imo.
>
> I see that in lightweightSynchronizer.cpp we already use the name
> `locking_thread` (although
> `LightweightSynchronizer::inflate_into_object_heade
On Wed, 6 Nov 2024 00:01:21 GMT, Patricio Chilano Mateo
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/12
On Fri, 25 Oct 2024 21:29:05 GMT, Patricio Chilano Mateo
wrote:
>> I see that in lightweightSynchronizer.cpp we already use the name
>> `locking_thread` (although
>> `LightweightSynchronizer::inflate_into_object_header` still uses
>> `inflating_thread`). So how about using `locking_thread` in
On Thu, 24 Oct 2024 08:08:56 GMT, Stefan Karlsson 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 b
On Fri, 25 Oct 2024 12:00:43 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/runtime/synchronizer.cpp line 1440:
>>
>>> 1438: }
>>> 1439:
>>> 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread*
>>> inflating_thread, oop object, const InflateCause cause) {
>>
>> `inflating_thr
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 Thu, 31 Oct 2024 02:26:42 GMT, David Holmes wrote:
>> src/hotspot/share/runtime/objectMonitor.inline.hpp line 207:
>>
>>> 205: }
>>> 206:
>>> 207: inline bool ObjectMonitor::has_successor() {
>>
>> Why are _succ accesses atomic here when previously they were not?
>
> General convention is t
On Fri, 25 Oct 2024 11:59:03 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/runtime/objectMonitor.hpp line 174:
>>
>>> 172:
>>> 173: int64_t volatile _owner; // Either tid of owner, NO_OWNER,
>>> ANONYMOUS_OWNER or DEFLATER_MARKER.
>>> 174: volatile uint64_t _previous_owner_tid; // t
On Thu, 31 Oct 2024 16:34:41 GMT, Patricio Chilano Mateo
wrote:
>> General convention is that racily accessed variables should be accessed via
>> Atomic::load/store to make it clear(er) they are racy accesses. But I agree
>> it seems odd when direct accesses to `_succ` in the main cpp file are
On Wed, 23 Oct 2024 20:42:44 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/runtime/objectMonitor.hpp line 299:
>>
>>> 297: // Simply set _owner field to new_value; current value must match
>>> old_value.
>>> 298: void set_owner_from_raw(int64_t old_value, int64_t new_value);
On Mon, 28 Oct 2024 13:08:37 GMT, Richard Reingruber 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 Mon, 28 Oct 2024 13:12:22 GMT, Richard Reingruber wrote:
>> src/hotspot/share/runtime/objectMonitor.hpp line 202:
>>
>>> 200:
>>> 201: // Used in LM_LEGACY mode to store BasicLock* in case of inflation
>>> by contending thread.
>>> 202: BasicLock* volatile _stack_locker;
>>
>> IIUC the
On Wed, 23 Oct 2024 09:53:53 GMT, Richard Reingruber 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 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
On Tue, 22 Oct 2024 19:02:50 GMT, Patricio Chilano Mateo
wrote:
>> Just to say that we hope to eventually remove these "temporary transitions".
>> This PR brings in a change that we've had in the loom repo to not need this
>> when calling out to the scheduler. The only significant remaining us
On Wed, 23 Oct 2024 05:33:55 GMT, Axel Boldt-Christmas
wrote:
>> Ok, I'll change copy_lockstack to both load and clear the oops in the same
>> method. Now, when we call do_barriers on recurse_thaw we don't clear the
>> oops, we just load and store the loaded value again. Is it the case that we
On Wed, 6 Nov 2024 09:24:03 GMT, Alan Bateman wrote:
> So at some point I think we need to figure out how to make them go away ...
Yes, the 2 extension events (`VirtualThreadMount` and `VirtualThreadUnmount`)
were added for testing purposes. We wanted to get rid of them at some point but
the
On Wed, 23 Oct 2024 09:53:44 GMT, Alan Bateman wrote:
>> The problem is that within that window we don't have access to the virtual
>> thread's tid. The current thread has already been changed and we haven't yet
>> set the lock id back. Since this will be a rare corner case maybe we can
>> jus
On Tue, 22 Oct 2024 19:04:16 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234:
>>
>>> 2232: retry_fast_path = true;
>>> 2233: } else {
>>> 2234: relativize_chunk_concurrently(chunk);
>>
>> Is the `relativize_chunk_concurrently` solu
On Mon, 21 Oct 2024 15:41:45 GMT, Axel Boldt-Christmas
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, 23 Oct 2024 00:56:34 GMT, Coleen Phillimore 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
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 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,
On Wed, 23 Oct 2024 09:58:44 GMT, Alan Bateman wrote:
>> src/hotspot/share/runtime/javaThread.hpp line 166:
>>
>>> 164: // current _vthread object, except during creation of the primordial
>>> and JNI
>>> 165: // attached thread cases where this field can have a temporary value.
>>> 166:
On Tue, 5 Nov 2024 23:53:04 GMT, Patricio Chilano Mateo
wrote:
>> Yes, I see your idea to get rid of the pending unmount event code. Before
>> commenting on that, note that we still need to check if the freeze failed to
>> undo the transition, which would call for this RAII object that we curr
On Wed, 30 Oct 2024 23:14:53 GMT, Patricio Chilano Mateo
wrote:
>> This might confuse the change for JEP 450 since with CompactObjectHeaders
>> there's no klass_gap, so depending on which change goes first, there will be
>> conditional code here. Good question though, it looks like we only eve
On Fri, 25 Oct 2024 13:12:11 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275:
>>
>>> 1273:
>>> 1274: if (caller.is_interpreted_frame()) {
>>> 1275: _total_align_size += frame::align_wiggle;
>>
>> Please put a comment here about frame
On Thu, 31 Oct 2024 21:11:39 GMT, Fredrik Bredberg
wrote:
>> There was one value that meant to be for the regular freeze from java. But
>> it was not used so I removed it.
>
> Fair enough, but I would prefer if you start at zero. Just so people like me
> don't start scratching their head tryin
On Wed, 30 Oct 2024 20:10:03 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/runtime/continuation.cpp line 88:
>>
>>> 86: if (_target->has_async_exception_condition()) {
>>> 87: _failed = true;
>>> 88: }
>>
>> Q: I wonder why the failed conditions are not checked be
On Thu, 31 Oct 2024 20:05:18 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/runtime/continuation.hpp line 66:
>>
>>> 64:
>>> 65: enum preempt_kind {
>>> 66: freeze_on_monitorenter = 1,
>>
>> Is there a reason why the first enumerator doesn't start at zero?
>
> There was one val
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 simplification below?
>>
>>
>> #if INCLUDE_JVMTI
>> // return tr
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 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 Tue, 29 Oct 2024 02:56:30 GMT, Serguei Spitsyn 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 b
On Mon, 28 Oct 2024 10:37:21 GMT, Yudi Zheng 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 s
On Tue, 5 Nov 2024 07:51:05 GMT, Erik Gahlin 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 s
On Tue, 5 Nov 2024 07:48:40 GMT, Erik Gahlin 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 s
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 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 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 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 Mon, 4 Nov 2024 02:12:40 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
On Mon, 28 Oct 2024 22:02:02 GMT, Patricio Chilano Mateo
wrote:
>> That said such a scenario is not about concurrently pushing the same thread
>> to the list from different threads. So I'm still somewhat confused about the
>> concurrency control here. Specifically I can't see how the cmpxchg o
On Mon, 28 Oct 2024 00:55:34 GMT, David Holmes wrote:
>> H ... I guess we either slow down the monitor code by having the thread
>> search for and remove itself, or we allow for this and handle it correctly
>> ... okay.
>
> That said such a scenario is not about concurrently pushing the sa
On Mon, 28 Oct 2024 00:43:47 GMT, David Holmes wrote:
>>> I'm struggling to understand how a thread can already be on this list?
>>>
>> With the removal of the _Responsible thread, it's less likely but it could
>> still happen. One case is when the virtual thread acquires the monitor after
>> a
On Fri, 25 Oct 2024 18:39:54 GMT, Patricio Chilano Mateo
wrote:
>>> The "waiting list" here is just a list of virtual threads that need
>>> unparking by the Unblocker thread - right?
>>>
>> Yes.
>
>> Some comments here about the operation would be useful.
>>
> Added a comment.
> I'm struggling
On Fri, 25 Oct 2024 18:40:51 GMT, Patricio Chilano Mateo
wrote:
>>> Some comments here about the operation would be useful.
>>>
>> Added a comment.
>
>> I'm struggling to understand how a thread can already be on this list?
>>
> With the removal of the _Responsible thread, it's less likely but i
On Fri, 25 Oct 2024 18:39:23 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/classfile/javaClasses.cpp line 2082:
>>
>>> 2080: }
>>> 2081:
>>> 2082: bool java_lang_VirtualThread::set_onWaitingList(oop vthread,
>>> OopHandle& list_head) {
>>
>> Some comments here about the operation w
On Mon, 28 Oct 2024 07:55:02 GMT, Richard Reingruber 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 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 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 Mon, 28 Oct 2024 23:09:58 GMT, Dean Long wrote:
>> Not sure. We would have to return from wait0 and immediately clear the
>> physical stack from the frames just copied without safepoint polls in the
>> middle. Otherwise if someone walks the thread's stack it will find the
>> frames appearin
1 - 100 of 241 matches
Mail list logo
