On Wed, 30 Jul 2025 17:54:34 GMT, Kevin Walls wrote:
>> A long-standing omission where MBeanServer.registerMBean documents exception
>> behaviour, but we actually throw an NPE. We should recognise a null object
>> and return the wrapped exception we document.
>>
>> This wrapping behaviour is
On Wed, 30 Jul 2025 17:54:34 GMT, Kevin Walls wrote:
>> A long-standing omission where MBeanServer.registerMBean documents exception
>> behaviour, but we actually throw an NPE. We should recognise a null object
>> and return the wrapped exception we document.
>>
>> This wrapping behaviour is
On Thu, 31 Jul 2025 03:45:10 GMT, Serguei Spitsyn wrote:
>> If JVMTI `StopThread` is done when the thread is in certain various states
>> (but not all states), after the `async` exception is delivered and handled,
>> hotspot leaves the thread's `interrupted` flag set. The end result is the
>>
On Wed, 30 Jul 2025 11:19:33 GMT, Kevin Walls wrote:
> A long-standing omission where MBeanServer.registerMBean documents exception
> behaviour, but we actually throw an NPE. We should recognise a null object
> and return the wrapped exception we document.
>
> This wrapping behaviour is commo
On Wed, 30 Jul 2025 11:19:33 GMT, Kevin Walls wrote:
> A long-standing omission where MBeanServer.registerMBean documents exception
> behaviour, but we actually throw an NPE. We should recognise a null object
> and return the wrapped exception we document.
>
> This wrapping behaviour is commo
On Tue, 29 Jul 2025 23:45:09 GMT, David Holmes wrote:
> And again this issue of leaving the interrupt flag set has existed "forever".
Right, and mostly surfaced when updating JVMTI to support virtual threads.
The related issue is that JVMTI InterruptThread doesn't cause a platform thread
to wa
On Wed, 30 Jul 2025 07:19:34 GMT, Serguei Spitsyn wrote:
>> If JVMTI `StopThread` is done when the thread is in certain various states
>> (but not all states), after the `async` exception is delivered and handled,
>> hotspot leaves the thread's `interrupted` flag set. The end result is the
>>
On Tue, 29 Jul 2025 07:06:21 GMT, David Holmes wrote:
> FWIW I think the fix is reasonable to avoid messing with the interrupt flag,
> but the fact Alan seems to want the "stop" to not interrupt at all makes me
> wonder how stop would then actually work?
I don't think the current proposed chan
On Tue, 29 Jul 2025 02:20:56 GMT, Lei Zhu wrote:
> Hi all,
>
> Fixed type errors in documentation, minor changes.
>
> Thanks!
Good spot, a long standing copy and paste issue it seems.
-
Marked as reviewed by alanb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/26521#pul
On Mon, 28 Jul 2025 06:58:50 GMT, Serguei Spitsyn wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: implemented a suggestion: do not set interrupt flag at all
>
> I've implemented and pushed the suggestion
On Fri, 25 Jul 2025 06:21:29 GMT, Serguei Spitsyn wrote:
>> Once in the handshake the carrier (and thus virtual thread) is "frozen" with
>> regards to any transition. It could be anywhere in the process of
>> mounting/unmounting (depending of course exactly where the carrier might
>> respond t
On Thu, 24 Jul 2025 05:43:16 GMT, Serguei Spitsyn wrote:
> I think, this issue needs a Release Note, same as the JNI related
> enhancement. Not sure about the JVMTI related spec update as it has pure spec
> clarifications which do not have even minor compatibility issues.
I agree. Also one rel
On Fri, 18 Jul 2025 23:55:44 GMT, Chris Plummer wrote:
>> Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal
>> with JDWP OPAQUE_FRAME error.
>>
>> Before virtual threads, OpaqueFrameException did not exist and these API
>> always threw NativeMethodException when JDWP
On Tue, 22 Jul 2025 06:11:45 GMT, Chris Plummer wrote:
>> StackFrame.SetValues, StackFrame.GetValues, ThreadReference.PopFrames, and
>> ThreadReference.ForceEarlyReturn all need updated language related to
>> OPAQUE_FRAME error.
>>
>> (1) The spec for JVMTI says the following for GetLocalsXXX
On Tue, 15 Jul 2025 22:50:00 GMT, Chris Plummer wrote:
> StackFrame.SetValues, StackFrame.GetValues, ThreadReference.PopFrames, and
> ThreadReference.ForceEarlyReturn all need updated language related to
> OPAQUE_FRAME error.
>
> (1) The spec for JVMTI says the following for GetLocalsXXX and S
On Fri, 18 Jul 2025 18:44:45 GMT, Serguei Spitsyn wrote:
>> If JVMTI `StopThread` is done when the thread is in certain various states
>> (but not all states), after the `async` exception is delivered and handled,
>> hotspot leaves the thread's `interrupted` flag set. The end result is the
>>
On Thu, 17 Jul 2025 12:13:22 GMT, David Holmes wrote:
> I need to dive into the code tomorrow but I can't help think that doing an
> actual interrupt is not really what is needed, we just need to unpark the
> thread if it is blocked ...
I think we also need to step back and write down examples
On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber wrote:
>> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java
>> to force inlining of java/lang/String*.* methods. This will make inlining
>> more stable to allow for the expected lock elimination based on c2 escape
>>
On Thu, 3 Jul 2025 15:31:28 GMT, Serguei Spitsyn wrote:
> Then should we say this way: "unable to set a `FramePop` event for the frame"
> ?
The can_generate_frame_pop_events capability uses "Can set .." so I think what
you propose is good. Also the temptation may be to use the word "enable" wh
On Thu, 3 Jul 2025 14:36:15 GMT, Richard Reingruber wrote:
> I found that the runtime of each test is ~300ms with a release build and ~11s
> with a fastdebug build on x86_64 and ppc64. If you like I can remove the
> requirement within this pr and do some more testing. -Xcomp doesn't seem to
>
On Thu, 3 Jul 2025 06:05:26 GMT, Serguei Spitsyn wrote:
> It was decided in a local discussion with Chris and Alan to update the JVMTI
> spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME`
> cases more consistent.
> This impacts the following JVMTI functions:
> - `PopF
On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber wrote:
> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java
> to force inlining of java/lang/String*.* methods. This will make inlining
> more stable to allow for the expected lock elimination based on c2 escape
> an
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
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: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: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
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 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 17:49:42 GMT, Naoto Sato wrote:
> A minor doc fix. Avoiding @spec reference clash in the doc build
Marked as reviewed by alanb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/25985#pullrequestreview-2960662795
On Wed, 25 Jun 2025 11:26:22 GMT, Anton Artemov wrote:
>> This PR contains changes for the 1st phase of the `LockingMode` flag
>> obsoletion.
>>
>> The work is done by @fbredber, I have taken it over and am finishing it
>> while he's on vacation.
>>
>> In the 1st phase one keeps the `Lockin
On Wed, 25 Jun 2025 11:35:51 GMT, Anton Artemov wrote:
>> test/jdk/jdk/internal/vm/Continuation/Fuzz.java line 477:
>>
>>> 475: boolean shouldPin() {
>>> 476: // Returns false since we never pin after we removed legacy
>>> locking.
>>> 477: return traceHas(Op.PIN::contains)
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
On Tue, 24 Jun 2025 13:25:20 GMT, Anton Artemov wrote:
>> This PR contains changes for the 1st phase of the `LockingMode` flag
>> obsoletion.
>>
>> The work is done by @fbredber, I have taken it over and am finishing it
>> while he's on vacation.
>>
>> In the 1st phase one keeps the `Lockin
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
On Tue, 24 Jun 2025 11:16:21 GMT, Anton Artemov wrote:
>> This PR contains changes for the 1st phase of the `LockingMode` flag
>> obsoletion.
>>
>> The work is done by @fbredber, I have taken it over and am finishing it
>> while he's on vacation.
>>
>> In the 1st phase one keeps the `Lockin
On Tue, 17 Jun 2025 08:39:49 GMT, Anton Artemov wrote:
> This PR contains changes for the 1st phase of the `LockingMode` flag
> obsoletion.
>
> The work is done by @fbredber, I have taken it over and am finishing it while
> he's on vacation.
>
> In the 1st phase one keeps the `LockingMode`
On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato wrote:
> Refactored the internal handling of `stdin/out/err.encoding` to allow setting
> them only via command-line options by converting them into `StaticProperty`.
> This change prevents unexpected behavior caused by applications modifying
> these
On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato wrote:
> Refactored the internal handling of `stdin/out/err.encoding` to allow setting
> them only via command-line options by converting them into `StaticProperty`.
> This change prevents unexpected behavior caused by applications modifying
> these
On Fri, 13 Jun 2025 09:14:09 GMT, Kevin Walls wrote:
> Clean backport to jdk25 of this doc-only change.
Marked as reviewed by alanb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/25795#pullrequestreview-2924968150
On Wed, 11 Jun 2025 18:12:49 GMT, Serguei Spitsyn wrote:
>> The JVMTI Exception event callback spec refers to the `catch_klass`
>> parameter which does not exist anymore. Instead the Exception event callback
>> spec should refer to the `catch_method` and `catch_location` parameters.
>> I treat
On Tue, 10 Jun 2025 21:13:11 GMT, Serguei Spitsyn wrote:
>> Then you also need to fix:
>>
>> "If there is no such catch clause, each field is set to 0."
>>
>> Also, technically speaking, can't `catch_location` be 0 even if caught
>> (caught first the bytecode of the method)? Although I doubt
On Tue, 10 Jun 2025 07:17:17 GMT, Serguei Spitsyn wrote:
> The JVMTI Exception event callback spec refers to the `catch_klass` parameter
> which does not exist anymore. Instead the Exception event callback spec
> should refer to the `catch_method` and `catch_location` parameters.
> I treat this
On Fri, 6 Jun 2025 09:49:09 GMT, Kevin Walls wrote:
>> Doc-only cleanup, not part of the API/spec.
>>
>> Remove link to the very old reference implementation of JMXMP in the
>> Javadoc. This may misleadingly imply it is a supported part of the JDK.
>
> Kevin Walls has updated the pull request
On Fri, 6 Jun 2025 08:40:26 GMT, Kevin Walls wrote:
> As is "User-defined connector protocols..." -> "Other connector protocols..."
I think that would be okay.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25670#discussion_r2131785164
On Fri, 6 Jun 2025 07:21:59 GMT, Alan Bateman wrote:
>> @AlanBateman @plummercj @sspitsyn Thanks so much for taking time to review
>> the changes, much appreciated. 🙇
>
>> @AlanBateman @plummercj @sspitsyn Thanks so much for taking time to review
>> the changes,
On Fri, 6 Jun 2025 08:18:16 GMT, Daniel Fuchs wrote:
>> Doc-only cleanup, not part of the API/spec.
>>
>> Remove link to the very old reference implementation of JMXMP in the
>> Javadoc. This may misleadingly imply it is a supported part of the JDK.
>
> src/java.management/share/classes/javax/
On Fri, 6 Jun 2025 06:52:19 GMT, Volkan Yazici wrote:
> @AlanBateman @plummercj @sspitsyn Thanks so much for taking time to review
> the changes, much appreciated.
Okay, but I'm still puzzled as to why the tests were changed as they don't
ready from the console.
-
PR Comment: htt
On Wed, 4 Jun 2025 12:03:15 GMT, Aleksey Shipilev wrote:
> SonarCloud points out that ThreadLock class introduced by
> [JDK-8357650](https://bugs.openjdk.org/browse/JDK-8357650) can be turned into
> static nested class. I don't think this shows any real bug yet, as
> unreferenced enclosing cla
On Wed, 4 Jun 2025 12:03:15 GMT, Aleksey Shipilev wrote:
> SonarCloud points out that ThreadLock class introduced by
> [JDK-8357650](https://bugs.openjdk.org/browse/JDK-8357650) can be turned into
> static nested class. I don't think this shows any real bug yet, as
> unreferenced enclosing cla
On Sat, 24 May 2025 06:57:56 GMT, Alan Bateman wrote:
> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and
> jcmd Thread.dump_to_file to include thread state and lock information. Also
> update the HotSpotDiagnosticMXBean.dumpThreads API description to
writer
> class to do this.
>
> Test coverage is significantly expanded, including updating the test library
> that is used by several tests to parse the thread dump.
>
> Testing: tier1-6
Alan Bateman has updated the pull request with a new target base due to a merge
or
writer
> class to do this.
>
> Test coverage is significantly expanded, including updating the test library
> that is used by several tests to parse the thread dump.
>
> Testing: tier1-6
Alan Bateman has updated the pull request with a new target base due to a merge
or a r
On Fri, 30 May 2025 19:57:09 GMT, Serguei Spitsyn wrote:
> Q: Is the order of dumped properties important?
No, the ordering doesn't matter. The intent with the schema in the API docs is
that we have somewhere to describe the objects name properties. If you re-order
then it still validate.
---
On Fri, 30 May 2025 17:43:15 GMT, Kevin Walls wrote:
>> Alan Bateman 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 five addi
On Wed, 28 May 2025 01:25:27 GMT, Alex Menkov wrote:
>> The change fixes "Thread.print" diagnostic command when mounted virtual
>> thread is waiting on the class initialization monitor.
>>
>> Testing: new test, tier1 sanity run
>
> Alex Menkov has updated the pull request incrementally with one
On Fri, 30 May 2025 11:07:30 GMT, Volkan Yazici wrote:
> Passes the `Charset` read from the `stdin.encoding` system property while
> creating `InputStreamReader` or `Scanner` instances for `System.in`.
>
> `stdin.encoding` is a recently added property for Java 25 in
> [JDK-8350703](https://bug
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 Sun, 25 May 2025 06:21:05 GMT, Alan Bateman wrote:
>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and
>> jcmd Thread.dump_to_file to include thread state and lock information. Also
>> update the HotSpotDiagnosticMXBean.dumpThreads API descri
writer
> class to do this.
>
> Test coverage is significantly expanded, including updating the test library
> that is used by several tests to parse the thread dump.
>
> Testing: tier1-6
Alan Bateman has updated the pull request with a new target base due to a merge
or a r
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: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 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 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 Sat, 24 May 2025 09:37:21 GMT, Shaojin Wen wrote:
>> Alan Bateman 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.
>
> tes
On Mon, 26 May 2025 16:06:01 GMT, Andrey Turbanov wrote:
>> Alan Bateman 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.
>
> src/java.base/share
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 Mon, 26 May 2025 17:25:33 GMT, Aleksey Shipilev wrote:
> [JDK-8356251](https://bugs.openjdk.org/browse/JDK-8356251) changed
> `JvmtiThreadState._saved_interp_only_mode` from `int` to `bool`, which is
> good. But the initializations are still done with `0` literals. Even though
> it is benig
On Mon, 26 May 2025 17:25:33 GMT, Aleksey Shipilev wrote:
> [JDK-8356251](https://bugs.openjdk.org/browse/JDK-8356251) changed
> `JvmtiThreadState._saved_interp_only_mode` from `int` to `bool`, which is
> good. But the initializations are still done with `0` literals. Even though
> it is benig
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 Sun, 25 May 2025 06:00:07 GMT, Alan Bateman wrote:
>> src/hotspot/share/classfile/javaClasses.cpp line 5519:
>>
>>> 5517: oop
>>> java_util_concurrent_locks_AbstractOwnableSynchronizer::get_owner_threadObj(oop
>>> obj) {
>>> 5518:
On Sun, 25 May 2025 05:08:12 GMT, Chen Liang wrote:
>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and
>> jcmd Thread.dump_to_file to include thread state and lock information. Also
>> update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a
>> d
t; fragile and hard to maintain so this is changed to use a supporting writer
> class to do this.
>
> Test coverage is significantly expanded, including updating the test library
> that is used by several tests to parse the thread dump.
>
> Testing: tier1-6
Alan Bateman h
On Sun, 25 May 2025 05:16:36 GMT, Chen Liang wrote:
>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and
>> jcmd Thread.dump_to_file to include thread state and lock information. Also
>> update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a
>> d
On Wed, 21 May 2025 20:35:33 GMT, Alex Menkov wrote:
> The change fixes "Thread.print" diagnostic command when mounted virtual
> thread is waiting on the class initialization monitor.
>
> Testing: new test, tier1 sanity run
test/hotspot/jtreg/serviceability/dcmd/thread/ClassInitMonitorVThread.
Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and
jcmd Thread.dump_to_file to include thread state and lock information. Also
update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a
description of the JSON format dump as that format is intended to b
On Thu, 22 May 2025 11:58:37 GMT, David Holmes wrote:
> To me, in the pinned case, both threads are "really waiting". The carrier
> physically and the vthread "logically". This also indicates it is actually
> doing pinning.
The intended mental model has always been that the carrier is waiting
On Thu, 22 May 2025 09:44:01 GMT, David Holmes wrote:
> At the moment class initialization in a vthread pins the carrier so I'm not
> sure why this is considered a problem??
The output is confusing as it prints the "waiting on the Class initialization
monitor for XXX" twice. It makes it looks
On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici wrote:
> There are several locations in the JDK source where `System.in` and
> `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the
> default charset. As recommended by the recently merged
> [JDK-8356420](https://bugs.open
On Mon, 12 May 2025 23:19:58 GMT, Serguei Spitsyn wrote:
> The tests `SuspendResume1`, `SuspendResume2` and `SuspendResumeAll` are
> intermittently failed with a timeout (deadlock). The tests run with
> `-Djdk.virtualThreadScheduler.maxPoolSize=1` so there is only one carrier.
> The short slee
On Thu, 8 May 2025 19:52:17 GMT, Patricio Chilano Mateo
wrote:
>> Please review this small test fix. We need to make sure the two threads are
>> blocked on the expected locks before invoking findMonitorDeadlockedThreads.
>> In the failing cases, one of the threads is seen as blocked while wait
On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth wrote:
>> This change tries to add timeout to individual testcases so that I am able
>> to run them with a timeout factor of 1 in the future (JDK-8260555).
>>
>> The first commit changes the timeout factor to 0.7, so that I can run tests
>> and test
On Thu, 8 May 2025 19:49:05 GMT, Patricio Chilano Mateo
wrote:
>> test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line
>> 99:
>>
>>> 97: System.out.println("Waiting for thread1 and thread2 to deadlock
>>> ...");
>>> 98: awaitBlocked(thread1, reached1);
>
On Thu, 8 May 2025 13:46:02 GMT, Patricio Chilano Mateo
wrote:
> Please review this small test fix. We need to make sure the two threads are
> blocked on the expected locks before invoking findMonitorDeadlockedThreads.
> In the failing cases, one of the threads is seen as blocked while waiting
Follow up to JDK-8319447 to change the VirtualThread implementation to use
FJP's delayed task handling.
The SPTE based implementation is not removed. It will continue to be used by
tests. If custom schedulers are exposed in the future then they will use this
implementation.
For timed-Object.wa
On Tue, 8 Apr 2025 19:09:02 GMT, Jiangli Zhou wrote:
>> Please review this PR that changes
>> `LoadAgentDcmdTest.getLibInstrumentPath()` to not locate `libinstrument`
>> shared library if running on static JDK, instead just returns
>> "libinstrument." directly. Both test case #1 and #2 in
>>
On Wed, 9 Apr 2025 17:14:27 GMT, Jiangli Zhou wrote:
>> Please review this PR that changes
>> `LoadAgentDcmdTest.getLibInstrumentPath()` to not locate `libinstrument`
>> shared library if running on static JDK, instead just returns
>> "libinstrument." directly. Both test case #1 and #2 in
>>
On Thu, 13 Mar 2025 10:48:14 GMT, Alan Bateman wrote:
> Follow up to JDK-8319447 to change the VirtualThread implementation to use
> FJP's delayed task handling.
>
> The SPTE based implementation is not removed. It will continue to be used by
> tests. If custom scheduler
On Wed, 9 Apr 2025 08:14:04 GMT, Serguei Spitsyn wrote:
> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI
> `GetThreadGroupChildren` does an upcall to java. This results in
> a`ClassPrepare` event the first time it does this, and these events can cause
> problems
On Wed, 9 Apr 2025 08:03:44 GMT, Viktor Klang wrote:
>> It already does, no CAS if the current value is the new value.
>
> I meant the park permit. :)
getAndSetParkPermit isn't changed in this PR. If the park permit is already
granted then getAndSetParkPermit(true) doesn't do anything. More gen
On Tue, 8 Apr 2025 20:05:26 GMT, Viktor Klang wrote:
>> Follow up to JDK-8319447 to change the VirtualThread implementation to use
>> FJP's delayed task handling.
>>
>> The SPTE based implementation is not removed. It will continue to be used by
>> tests. If custom schedulers are exposed in th
On Tue, 1 Apr 2025 20:00:22 GMT, Chris Plummer wrote:
>> Calling ThreadGroupReference.groups() from an event handler can cause a
>> deadlock. Details in first comment. Tested with :jdk_lang on all supported
>> platforms and tier1, tier2, tier3, and tier5 svc testing.
>
> Chris Plummer has updat
On Fri, 28 Mar 2025 21:02:21 GMT, Chris Plummer wrote:
>> Calling ThreadGroupReference.groups() from an event handler can cause a
>> deadlock. Details in first comment. Tested with :jdk_lang on all supported
>> platforms and tier1, tier2, tier3, and tier5 svc testing.
>
> Chris Plummer has upda
On Wed, 26 Mar 2025 20:37:46 GMT, Chris Plummer wrote:
>> Yes, one EventHandler thread dispatching to all listeners. More details
>> below:
>>
>> There is an interface called TargetListener which declares all the event
>> callbacks. TargetAdapter implements TargetListener and provides and empt
On Wed, 26 Mar 2025 20:50:36 GMT, Chris Plummer wrote:
>> Calling ThreadGroupReference.groups() from an event handler can cause a
>> deadlock. Details in first comment. Tested with :jdk_lang on all supported
>> platforms and tier1, tier2, tier3, and tier5 svc testing.
>
> Chris Plummer has upda
On Wed, 26 Mar 2025 18:22:00 GMT, Chris Plummer wrote:
>> Calling ThreadGroupReference.groups() from an event handler can cause a
>> deadlock. Details in first comment. Tested with :jdk_lang on all supported
>> platforms and tier1, tier2, tier3, and tier5 svc testing.
>
> Chris Plummer has upda
On Wed, 26 Mar 2025 06:21:31 GMT, Robbin Ehn wrote:
> One issue with high timeout factor is that make+jtreg only can parallelize
> tests in the same directory. Which means you often end up with just waiting
> for one test to complete before anything else can happen.
jtreg doesn't require tests
On Tue, 18 Mar 2025 02:49:07 GMT, David Holmes wrote:
> Any idea on why things are taking so long? Is the pipe undersized?
It's usually just handled by Windows although I think you can
override/configure with SetNamedPipeHandleState.
-
PR Comment: https://git.openjdk.org/jdk/pull/
On Tue, 18 Mar 2025 00:16:40 GMT, Alex Menkov wrote:
> The change fixes regression from JDK-8319055 (see David's evaluation in the
> CR description)
>
> Testing: sanity tier1;
> tier6, tier7 - in progress
Marked as reviewed by alanb (Reviewer).
-
PR Review: https://git.openjdk.
On Sat, 22 Feb 2025 03:31:53 GMT, Jiangli Zhou wrote:
> Please review the fix in following tests to not check for shared libraries
> when running on static JDK:
>
> test/hotspot/jtreg/serviceability/dcmd/vm/DynLibsTest.java
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemDumpMapTest.java
> te
1 - 100 of 861 matches
Mail list logo
