On Mon, 20 Nov 2023 00:59:35 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> @dcubed-ojdk >> I don't know FJP implementation well enough to point at the code where it >> happens. However, I observe that new `JavaThread `is being created between >> two points of the execution path. >> - First point is in the `JvmtiEventControllerPrivate::recompute_enabled()` >> at the line where a `ThreadsListHandle` is set. I've added a trap checking >> if any `JavaThread` pointed by `state->get_thread()` is not protected by the >> `tlh`. I can see this trap is not fired (I can't say it has never been >> fired). >> - Second point is in the >> `JvmtiEventControllerPrivate::enter_interp_only_mode()`. If a >> `ThreadsListHandle` is NOT set then I can observe a `JavaThread` referenced >> by the state->get_thread() which is not protected by any TLH. It a TLH added >> into `JvmtiEventControllerPrivate::enter_interp_only_mode()` then this >> `JavaThread` is observed as protected by TLH. >> >> I've removed a part of this comment with stack traces as my traps were not >> fully correct, need to double check everything. This issue is not well >> reproducible but I'm still trying to reproduce it again. >> One approach would be to remove this change in the >> `src/hotspot/share/prims/jvmtiEventController.cpp` from PR and try address >> it separately. > > Just to re-iterate what Dan was saying, the TLH is only of use if you are > accessing threads known to be included in the TLH. I've spend some time trying to reproduce the original issue to provide some details to Dan but there is no luck yet. I'm sure the issue still exists but it is better to investigate and address it separately from this PR. So, my plan is to remove this line with TLH from the `jvmtiEventController.cpp`. BTW, if it is still needed Alan promised to point to the code where the FJP compensating mechanism adds new carrier threads. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16686#discussion_r1401283561
