On Wed, 2 Jul 2025 08:42:22 GMT, Kevin Walls wrote:
> Clean backport to JDK 25.
>
> This change recently integrated in JDK 26 and is through tiers 1 - 4 so far.
Thanks Alan and Serguei, will integrate this clean backport to 25.
-
PR Comment: https://git.openjdk.org/jdk/pull/26088
On Wed, 2 Jul 2025 08:42:22 GMT, Kevin Walls wrote:
> Clean backport to JDK 25.
>
> This change recently integrated in JDK 26 and is through tiers 1 - 4 so far.
It is a clean backport.
-
Marked as reviewed by sspitsyn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/26088
On Wed, 2 Jul 2025 08:42:22 GMT, Kevin Walls wrote:
> Clean backport to JDK 25.
>
> This change recently integrated in JDK 26 and is through tiers 1 - 4 so far.
Clean backport .
-
Marked as reviewed by alanb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/26088#pullreque
Clean backport to JDK 25.
This change recently integrated in JDK 26 and is through tiers 1 - 4 so far.
-
Commit messages:
- Backport 13a3927855da61fe27f3b43e5e4755d0c5ac5a16
Changes: https://git.openjdk.org/jdk/pull/26088/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26
On Tue, 1 Jul 2025 10:20:12 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
On Tue, 1 Jul 2025 10:20:12 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
On Tue, 1 Jul 2025 10:20:12 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
On Tue, 1 Jul 2025 03:01:24 GMT, David Holmes wrote:
>> Kevin Walls has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 13 additional
>> commits sin
On Mon, 30 Jun 2025 11:24:28 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM
> JavaThread from a java.lang.Thread. This is hard to reproduce but a thread
> that has since terminated can provoke a crash. Recognise this and return a
> null ThreadSnapshot.
Kevin Walls has updated the pull req
> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM
> JavaThread from a java.lang.Thread. This is hard to reproduce but a thread
> that has since terminated can provoke a crash. Recognise this and return a
> null ThreadSnapshot.
Kevin Walls has updated the pull req
On Mon, 30 Jun 2025 11:24:28 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
On Mon, 30 Jun 2025 11:24:28 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
On Thu, 26 Jun 2025 08:26:44 GMT, Kevin Walls wrote:
>> Great catch Dan! I totally missed the TLH at the start of
>> `get_thread_snapshot`. I knew something was off here but couldn't quite put
>> my finger on it.
>
> Yes thanks Dan! Will update.
Thanks for all the hints, updated to use the TLH
> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM
> JavaThread from a java.lang.Thread. This is hard to reproduce but a thread
> that has since terminated can provoke a crash. Recognise this and return a
> null ThreadSnapshot.
Kevin Walls has updated the pull req
On Fri, 27 Jun 2025 20:22:12 GMT, Alex Menkov wrote:
> I believe null here is not result of `_thread_h()`, but is returned by
> `java_lang_VirtualThread::continuation(...)` because `_thread_h` is
> lava.lang.Thread object and not java.lang.VirtualThread.
That could only happen if we are dealin
On Fri, 27 Jun 2025 09:35:07 GMT, Kevin Walls wrote:
> But null from JNIHandles::resolve(jthread) is the earliest problem I found.
>
> I'm redoing with the cv_internal_thread_to_JavaThread usage...
>
> A little concerned that ThreadsListHandle::cv_internal_thread_to_JavaThread
> takes jobject
On Thu, 26 Jun 2025 00:38:17 GMT, David Holmes wrote:
> > Line number info puts it in the _java_thread == null branch of:
> > threadService.cpp
> > 1317 vframeStream vfst(_java_thread != nullptr
> > 1318 ? vframeStream(_java_thread, false, true, vthread_carrier)
> > 1319 : vframeStream(java_lang
On Fri, 27 Jun 2025 15:32:52 GMT, Alan Bateman wrote:
>> Not sure I'm understanding.
>> This test chooses to rule out running with all debug builds, because it
>> causes timeouts.
>> I only saw timeouts when I forced it to run in a debug build (win+mac),
>> which are not currently run by choice
On Fri, 27 Jun 2025 15:14:36 GMT, Kevin Walls wrote:
>> There is nothing Linux in this change or test so I think drop the change to
>> the test and create a separate for the timeout you saw.
>
> Not sure I'm understanding.
> This test chooses to rule out running with all debug builds, because it
On Fri, 27 Jun 2025 14:48:32 GMT, Alan Bateman wrote:
>> I saw the test timeout in debug builds on win and mac (as expected).
>>
>> On Linux, fastdebug builds run OK, take about 1m30 in CI and could be
>> useful. If further testing doesn't find a timeout issue, I'd like to leave
>> this in, to
On Fri, 27 Jun 2025 14:44:08 GMT, Kevin Walls wrote:
>> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java
>> line 30:
>>
>>> 28: * an object that is scalar replaced
>>> 29: * @requires vm.compMode != "Xcomp"
>>> 30: * @requires !vm.debug | (os.family
On Fri, 27 Jun 2025 12:24:50 GMT, Alan Bateman wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test requires: permit linux debug testing
>
> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithElimina
On Fri, 27 Jun 2025 12:22:21 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM
> JavaThread from a java.lang.Thread. This is hard to reproduce but a thread
> that has since terminated can provoke a crash. Recognise this and return a
> null ThreadSnapshot.
Kevin Walls has updated the pull req
On Wed, 25 Jun 2025 13:02:03 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
On Wed, 25 Jun 2025 13:02:03 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
On Thu, 26 Jun 2025 12:20:03 GMT, Kevin Walls wrote:
> > This seems like a separate discussion as the minimal VM doesn't have the
> > M&M support
>
> Sure, it's maybe off topic. I now see that few tests handle this. I hit it as
> a minimal build showed me I had the wrong THROW macro, so in get
On Thu, 26 Jun 2025 06:04:20 GMT, Alan Bateman wrote:
> This seems like a separate discussion as the minimal VM doesn't have the M&M
> support
Sure, it's maybe off topic. I now see that few tests handle this.
I hit it as a minimal build showed me I had the wrong THROW macro, so in
getting tha
On Wed, 25 Jun 2025 23:50:59 GMT, David Holmes wrote:
>> src/hotspot/share/services/threadService.cpp line 1477:
>>
>>> 1475: java_thread = java_lang_Thread::thread(thread_h());
>>> 1476: if (java_thread == nullptr) {
>>> 1477: return nullptr; // thread terminated
>>
>> This is
On Wed, 25 Jun 2025 13:02:03 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
On Wed, 25 Jun 2025 22:08:17 GMT, Daniel D. Daugherty
wrote:
>> Kevin Walls has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - comment update
>> - comment update
>
> src/hotspot/share/services/threadService.cpp line 1477:
>
>> 1475:
On Wed, 25 Jun 2025 21:24:13 GMT, Kevin Walls wrote:
> Line number info puts it in the _java_thread == null branch of:
> threadService.cpp
> 1317 vframeStream vfst(_java_thread != nullptr
> 1318 ? vframeStream(_java_thread, false, true, vthread_carrier)
> 1319 : vframeStream(java_lang_Virtual
On Wed, 25 Jun 2025 13:02:03 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
On Wed, 25 Jun 2025 20:48:26 GMT, David Holmes wrote:
> Something still bugging me about this one. From JBS it looked to me like we
> were dealing with a virtual thread but your change is for the non-virtual
> thread. And Alan says something about this only being possible due to a
> temporary
On Wed, 25 Jun 2025 20:48:17 GMT, David Holmes wrote:
>> Kevin Walls has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - comment update
>> - comment update
>
> src/hotspot/share/services/threadService.cpp line 1477:
>
>> 1475: java_t
On Wed, 25 Jun 2025 13:02:03 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
On Wed, 25 Jun 2025 13:02:03 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
On Wed, 25 Jun 2025 12:30:35 GMT, Alan Bateman wrote:
>> Kevin Walls has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - newline
>> - Test fails on minimal VM: require jvmti feature
>
> src/java.base/share/classes/jdk/internal/vm/ThreadDu
> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM
> JavaThread from a java.lang.Thread. This is hard to reproduce but a thread
> that has since terminated can provoke a crash. Recognise this and return a
> null ThreadSnapshot.
Kevin Walls has updated the pull req
On Wed, 25 Jun 2025 12:02:11 GMT, Kevin Walls wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return a
> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM
> JavaThread from a java.lang.Thread. This is hard to reproduce but a thread
> that has since terminated can provoke a crash. Recognise this and return a
> null ThreadSnapshot.
Kevin Walls has updated the pull req
> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM
> JavaThread from a java.lang.Thread. This is hard to reproduce but a thread
> that has since terminated can provoke a crash. Recognise this and return a
> null ThreadSnapshot.
Kevin Walls has updated the pull req
> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM
> JavaThread from a java.lang.Thread. This is hard to reproduce but a thread
> that has since terminated can provoke a crash. Recognise this and return a
> null ThreadSnapshot.
Kevin Walls has updated the pull req
On Wed, 25 Jun 2025 10:15:54 GMT, Alan Bateman wrote:
>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native
>> VM JavaThread from a java.lang.Thread. This is hard to reproduce but a
>> thread that has since terminated can provoke a crash. Recognise this and
>> return
On Tue, 24 Jun 2025 17:00:19 GMT, Kevin Walls wrote:
> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM
> JavaThread from a java.lang.Thread. This is hard to reproduce but a thread
> that has since terminated can provoke a crash. Recognise this and return a
> nul
ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM
JavaThread from a java.lang.Thread. This is hard to reproduce but a thread
that has since terminated can provoke a crash. Recognise this and return a
null ThreadSnapshot.
-
Commit messages:
- ThreadSna
47 matches
Mail list logo
