On Thu, 29 May 2025 18:21:11 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Fri, 30 May 2025 13:58:53 GMT, Kevin Walls wrote:
> Just to be clear, the ifdef JVMTI means Thread.dump_to_file not work in a
> build configuration using - --enable-jvm-feature-jvmti=no ? Currently,
> Thread.dump_to_file works in such configs. I don't think this is a problem..
> just though
On Thu, 29 May 2025 18:21:11 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Thu, 29 May 2025 17:57:09 GMT, Kevin Walls wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update src/hotspot/share/services/threadService.cpp
>>
>> Co-authored-by: David Holmes
>> <62092539+dholmes-...@use
> This is first (hotspot) part of the update for
> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
> include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.
On Thu, 29 May 2025 07:57:57 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with five additional
>> commits since the last revision:
>>
>> - removed retry_handshake logic
>> - removed AbstractOwnableSynchronizer.exclusiveOwnerThread support
>> - cleanup
On Thu, 29 May 2025 18:21:11 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Thu, 29 May 2025 08:53:44 GMT, Alan Bateman wrote:
>> Let's check the logic before and now:
>> - before:
>>`walk_cont = _java_thread != nullptr && !is_virtual &&
>> _thread->vthread_continuation() != nullptr`
>> - now:
>>`walk_cont = _java_thread != nullptr && _thread->vthread_conti
> This is first (hotspot) part of the update for
> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
> include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.
On Thu, 29 May 2025 07:58:41 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Thu, 29 May 2025 08:26:07 GMT, Serguei Spitsyn wrote:
>> Something isn't right here. Are you sure walk_cont is correctly for the
>> mounted virtual thread case? There are several tests failing now.
>
> Let's check the logic before and now:
> - before:
>`walk_cont = _java_thread != nullpt
On Thu, 29 May 2025 08:12:35 GMT, Alan Bateman wrote:
>> The logic is the same as before.
>> The problem is the variable name. it's `bool vthread_carrier` argument of
>> vframeStream ctor. Will change the name
>
> Something isn't right here. Are you sure walk_cont is correctly for the
> mounted
On Thu, 29 May 2025 07:58:41 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Thu, 29 May 2025 08:01:00 GMT, Alex Menkov wrote:
>> src/hotspot/share/services/threadService.cpp line 1296:
>>
>>> 1294: }
>>> 1295:
>>> 1296: bool walk_cont = (_java_thread != nullptr) &&
>>> (_java_thread->vthread_continuation() != nullptr);
>>
>> Can you double check this? It l
On Thu, 29 May 2025 05:52:53 GMT, David Holmes wrote:
>>> Why this change?
>> To be more clear about the change:
>> We need JvmtiVTMSTransitionDisabler for virtual threads only, for platform
>> threads handshake is enough. And currently for platform threads
>> JvmtiVTMSTransitionDisabler disabl
On Thu, 29 May 2025 03:26:49 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Wed, 28 May 2025 07:35:55 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move to ThreadService
>
> src/hotspot/share/services/threadService.cpp line 1160:
>
>> 1158:
>> 1159: Type _typ
On Thu, 29 May 2025 07:19:45 GMT, Alan Bateman wrote:
>> Alex Menkov has updated the pull request incrementally with five additional
>> commits since the last revision:
>>
>> - removed retry_handshake logic
>> - removed AbstractOwnableSynchronizer.exclusiveOwnerThread support
>> - cleanup
>>
> This is first (hotspot) part of the update for
> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
> include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.
On Thu, 29 May 2025 03:26:49 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Thu, 29 May 2025 03:26:49 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Wed, 28 May 2025 18:16:20 GMT, Alex Menkov wrote:
>> It's used by VMThreadSnapshot::get_thread_snapshot. The transition disabling
>> support is currently in the jvmti code. I think this is the first usage in a
>> handshake op that isn't supporting a JVMTI function. Maybe in the future
>> th
On Wed, 28 May 2025 07:09:06 GMT, David Holmes wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move to ThreadService
>
> src/hotspot/share/services/threadService.cpp line 1189:
>
>> 1187: _thread_status(), _nam
On Wed, 28 May 2025 18:31:21 GMT, Alex Menkov wrote:
>> src/hotspot/share/services/threadService.cpp line 1203:
>>
>>> 1201: }
>>> 1202:
>>> 1203: bool read_reset_retry() {
>>
>> What does the `read` mean in the name?
>
> read and then reset the `retry` value (return old value)
removed "r
On Wed, 28 May 2025 03:51:36 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move to ThreadService
>
> src/hotspot/share/services/threadService.cpp line 1180:
>
>> 1178: GrowableArray* _locks
On Wed, 28 May 2025 19:36:39 GMT, Alex Menkov wrote:
>> src/hotspot/share/prims/jvm.cpp line 2968:
>>
>>> 2966: oop snapshot = VMThreadSnapshot::get_thread_snapshot(jthread,
>>> THREAD);
>>> 2967: return JNIHandles::make_local(THREAD, snapshot);
>>> 2968: #elif
>>
>> Q: should it be `#else
On Wed, 28 May 2025 13:35:44 GMT, Alan Bateman wrote:
>> src/hotspot/share/classfile/javaClasses.cpp line 1875:
>>
>>> 1873:
>>> 1874: oop java_lang_Thread::park_blocker(oop java_thread) {
>>> 1875: return java_thread->obj_field_acquire(_park_blocker_offset);
>>
>> Where is the releasing sto
On Wed, 28 May 2025 03:47:04 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move to ThreadService
>
> src/hotspot/share/services/threadService.cpp line 1172:
>
>> 1170: Handle _java_thread;
> This is first (hotspot) part of the update for
> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
> include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.
> This is first (hotspot) part of the update for
> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
> include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.
On Wed, 28 May 2025 07:10:57 GMT, David Holmes wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move to ThreadService
>
> src/hotspot/share/services/threadService.cpp line 1206:
>
>> 1204: bool ret = _retry_hand
On Wed, 28 May 2025 10:33:36 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move to ThreadService
>
> src/hotspot/share/prims/jvm.cpp line 2968:
>
>> 2966: oop snapshot = VMThreadSnapshot::g
On Wed, 28 May 2025 07:07:27 GMT, David Holmes wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move to ThreadService
>
> src/hotspot/share/services/threadService.cpp line 1170:
>
>> 1168: };
>> 1169:
>> 1170:
On Wed, 28 May 2025 12:58:49 GMT, Alan Bateman wrote:
>> src/hotspot/share/prims/jvmtiThreadState.hpp line 80:
>>
>>> 78: // Virtual Thread Mount State Transition (VTMS transition) mechanism
>>> 79: //
>>> 80: class JvmtiVTMSTransitionDisabler : public AnyObj {
>>
>> Why this change?
>
> It's u
On Wed, 28 May 2025 06:59:48 GMT, David Holmes wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move to ThreadService
>
> src/hotspot/share/classfile/javaClasses.cpp line 1875:
>
>> 1873:
>> 1874: oop java_lang_Thr
On Wed, 28 May 2025 07:01:53 GMT, David Holmes wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move to ThreadService
>
> src/hotspot/share/prims/jvmtiThreadState.hpp line 80:
>
>> 78: // Virtual Thread Mount State
On Tue, 27 May 2025 22:48:15 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Tue, 27 May 2025 22:48:15 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Tue, 27 May 2025 22:48:15 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Tue, 27 May 2025 22:48:15 GMT, Alex Menkov wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify review
On Sat, 24 May 2025 00:17:26 GMT, Alex Menkov wrote:
> This is first (hotspot) part of the update for
> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
> include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> This is first (hotspot) part of the update for
> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
> include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.
On Tue, 27 May 2025 09:48:04 GMT, Stefan Karlsson wrote:
> Just a few drive-by questions:
>
> 1. Did you consider putting this implementation in another file, say
> threadServices.hpp or even its own file? I'm asking because javaClasses seems
> to have become a dumping ground for code that
On Sun, 25 May 2025 13:12:23 GMT, Chen Liang wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewi
On Tue, 27 May 2025 09:48:04 GMT, Stefan Karlsson wrote:
> 1. Did you consider putting this implementation in another file, say
> threadServices.hpp or even its own file? I'm asking because javaClasses seems
> to have become a dumping ground for code that calls from Java code into the
> JVM. I
On Sat, 24 May 2025 00:17:26 GMT, Alex Menkov wrote:
> This is first (hotspot) part of the update for
> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
> include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
On Sun, 25 May 2025 13:11:41 GMT, Chen Liang wrote:
>> This is first (hotspot) part of the update for
>> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
>> include lock information in thread dumps (JDK-8356870).
>> The update has been split into parts to simplify reviewi
On Sat, 24 May 2025 00:17:26 GMT, Alex Menkov wrote:
> This is first (hotspot) part of the update for
> `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to
> include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
This is first (hotspot) part of the update for
`HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include
lock information in thread dumps (JDK-8356870).
The update has been split into parts to simplify reviewing.
The fix contains an implementation of `jdk.internal.vm.ThreadS
49 matches
Mail list logo
