RFR: 8264016: [JVMCI] add some thread local fields for use by JVMCI

[Tom Rodriguez]

On Wed, 24 Mar 2021 22:09:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> co-author is a strong word.  :)  But that does ring a bell.  Why was threadObj problematic but the other existing oop fields were not?  JavaThread::oops_do_no_frames visits a lot of roots that aren't OopStorage.
>> I can tackle JDK-8137018.  I think we'll need to add an alias mechanism to vmStructs_jvmci.cpp to maintain backward compatibility but that's fairly straightforward.
>
> well, I didn't even list myself as author of that one.  _threadObj was a problem because some code (like thread dump management code) was accessing it from a terminating thread and the barriers were messed up. It was more complicated than that.  I don't know if this will be an issue for these declarations, and if you hide them in another place, we'll never know.

I see.  These fields will only be accessed from generated code so I don't think there are the same runtime considerations with them.  Obviously it will be our problem to diagnose and fix if issues like that crop up.  We just don't want to break an obvious invariants that would require the use of OopStorage.  Do you now approve of these changes?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3147