On Tue, 22 Oct 2024 19:02:50 GMT, Patricio Chilano Mateo <pchilanom...@openjdk.org> 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 use is >> timed-park. Once we address that then we will remove the need to switch the >> thread identity and remove some complexity, esp. for JVMTI and >> serviceability. >> >> In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the >> carrier so a thread-dump/safepoint at just the right time looks like it >> print will be tid of the carrier rather than the mounted virtual thread. So >> we should fix that. (The original code in main line skipped this case so was >> lossy when taking a thread dump when hitting this case, David might remember >> the discussion on that issue). > > 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 just > print tid unavailable if we hit it. We could also add a boolean to > setCurrentThread to indicate we don't want to change the lock_id, but not > sure it's worth it. It should be rare and once we make further progress on timers then the use of temporary transitions will mostly disappear. I think the main thing for the thread dump is not to print a confusing "Carrying virtual thread" with the tid of the carrier. This came up in [pull/19482](https://github.com/openjdk/jdk/pull/19482) when the thread was extended. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812377091
