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

[Coleen Phillimore]

On Wed, 24 Mar 2021 18:53:18 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> We made the _threadObj field in JavaThread an OopStorage to avoid a crash during thread deletion.  It's not recommended to add oops directly to runtime data structures.  I have to dig up the bug first.
>> 
>>> I haven't done a deep analysis of how much could be recovered but I could look into reducing the overall size JavaThread by > repacking if it makes adding these fields more palatable.
>> 
>> We have this sort of on our (internal) list with other improvements, so don't do anything here.
>> We also had a JVMCI bug that suggested adding these fields to a side .hpp file and referring to it in JavaThread by that container.  Like HandshakeState.  You can optimize the field layout inside this as you want.
>> 
>> I'm marking "Request changes" until I've had time to dig up the bug.
>
> No the C++ compiler just emits them in the declared order.  Since we group the field declarations by their relatedness it's not easy to get a completely good overall packing.  There's actually less direct waste than I expected in 17, though there are lots of cases where int are used to stored bools.  clang doesn't appear to optimize the storage for enums so there are lots of small enums stored in ints instead of bytes.  I believe gcc will use the smallest storage available.  There's also dubious stuff like the ``char[64]`` in the HandshakeState and lots of statistics that could live elsewhere.  Is there a bug I could attach my observations to?  It's nothing earth shattering but the clang reported layout is interesting to see.

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

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

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