> 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
> next time the thread does something like `Thread.sleep()`, it w
> 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
> next time the thread does something like `Thread.sleep()`, it w
> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as
> a temporary backward compatibility flag under JDK-8192936 and was immediately
> marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire
> in JDK 27.
>
> TBD: Need to submit a related CSR.
>
>
On Fri, 25 Jul 2025 17:48:01 GMT, Daniel D. Daugherty
wrote:
> then we can get to L836 even when we started off with a null java_thread.
Sure. My point was more the other way round - we could have a null JavaThread
without the null coming from line 836.
The comment was just trying to expand
On Fri, 25 Jul 2025 16:21:57 GMT, Patricio Chilano Mateo
wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move comment
>
> src/hotspot/share/runtime/threadSMR.hpp line 48:
>
>> 46: // perform an operation on a tar
On Fri, 25 Jul 2025 18:06:38 GMT, Daniel D. Daugherty
wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move comment
>
> Thumbs up on the changes. I think I only have a few nits.
Thanks for the review @dcubed-ojdk
> The `cv_internal_thread_to_JavaThread` method will now check if the thread is
> a mounted virtual thread, and if so protect the carrier thread. User's of the
> API that need to deal with virtual threads must still check the carrier
> themselves as it could change asynchronously, but it is now
> Fix gcc warning about double close. forkedChildProcess() calls
> closeDescriptors(), which always closes STDERR_FILENO + 1 and STDERR_FILENO +
> 2. However, if it fails at some point after that, then forkedChildProcess()
> will attempt to close these same two files again. Fixed by making
> fo
