RFR: 8307068: store a JavaThread* in the java.lang.Thread object after the JavaThread* is added to the main ThreadsList [v2]
Daniel D. Daugherty
dcubed at openjdk.org
Tue May 2 20:54:45 UTC 2023
On Tue, 2 May 2023 09:02:26 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> Daniel D. Daugherty 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 eetop field is defined as a Java volatile and so the VM should nominally always perform "volatile" reads and writes ie acquires and releases. But I said nominally, because in many cases there are other synchronization "release" barriers that must have occurred before we could get to the operations that read the eetop field. So I think it is only code that could interact with just started threads, that would need the explicit acquire; while I think any set of the eetop to non-null needs to have release semantics.
@dholmes-ora - Thanks for the review. I updated the comments and switched
from `java_lang_Thread::set_thread()` to `release_set_thread()` in the second
location.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/13723#issuecomment-1532134378
More information about the hotspot-runtime-dev
mailing list