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

[Tom Rodriguez]

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

>> I have a fix for the Mutex in HandshakeState.  Here's a bug for you to fill in. That would be great.
>> https://bugs.openjdk.java.net/browse/JDK-8264145
>
> One of the things we've talked about is making the hierarchy be something like:
> Thread
> NamedThread
>     ->  WatcherThread
> SafepointAwareThread
>     ->  CompilerThread
>     -> JavaThread
> 
> So that CompilerThread isn't a JavaThread.  But we're not going to do that very soon.

Regarding loom, it seems like there would have to be a major migration of lots of state into java.lang.Thread.  Or some more explicit backup and restores of various chunks of JavaThread during migration.  I know from previous discussions that things like the deferred_locals are problematic but JFR and any TLAB statistics/allocation tracking also seems problematic.  Is there some systematic solution to the general problem?  If these fields needed to live in Thread, then we could inject these fields into java.lang.Thread when JVMCI is enabled.  The access wouldn't have to be hugely different.  Is a resolution to the loom issue something that can be deferred?

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

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