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

[Tom Rodriguez]

On Tue, 23 Mar 2021 06:28:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 8264016: [JVMCI] add some thread local fields for use by JVMCI
>
> Hi Tom,
> 
> Is it feasible to create a JVMCI helper side-object that is only created when needed, rather than embedding all the fields directly in the JavaThread instance?
> 
> Thanks,
> David

Well the goal is to have storage that is only one or two loads away so adding a level of indirection isn't great.  Many of the other JVMCI fields aren't really performance critical so they could be an extra indirection away but that's not a compatible JVMCI change since they are directly written by Graal for deopt.  It also wouldn't save much space.  I know there is sensitivity around making JavaThread larger so I tried not to go too crazy.  Obviously I'd prefer to stick with what I have.
Out of curiosity I'd used the clang option ``-Xclang -fdump-record-layouts`` to look at JavaThread in 8, 11 and 17.  It's definitely getting fatter.  8 is 1024, 11 is 1264 and 17 is 1408, plus the huge alignment wastage caused by biased locking, though I guess that's not a problem in 17.  Anyway, I could probably get back the space I'm using by rearranging some of the fields of JavaThread.  There's a lot of wastage from switching between pointer, int and bool.  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.

> src/hotspot/share/runtime/thread.hpp line 1020:
> 
>> 1018:   intptr_t*  _jvmci_reserved0;
>> 1019:   intptr_t*  _jvmci_reserved1;
>> 1020:   oop        _jvmci_reserved_oop0;
> 
> Can this use OopStorage? We've been getting rid of oop fields and the corresponding oops_do support.

Wouldn't using OopStorage require an extra level of indirection for the field?

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

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