RFR: 8284533: Improve InterpreterCodelet data footprint

[Coleen Phillimore]

On Thu, 7 Apr 2022 15:02:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current `InterpreterCodelet` lays the fields in inefficient order. Stub generation aligns codelets and their related code at `CodeEntryAlignment` (`CEA`), which means with `CEA=16` we are taking two `CEA` units for `InterpreterCodelet` data. Rearranging the fields a bit improves the interpreter code density a bit, dropping its `sizeof` to 16 and thus taking one `CEA` unit. 
> 
> It would be even more important as we tune up stub generation to allow smaller alignments for data sections in the stub, but the effect is visible even now on small `CEA`-s. These small `CEA`-s are default on some platforms (ARM, selected x86 configs).
> 
> Size instrumentation on x86_64 release bits:
> 
> 
> # Before
> sizeof: 24
> _size: @0
> _description: @8
> _bytecode: @16
> 
> # After
> sizeof: 16
> _size: @8
> _description: @0
> _bytecode: @12
> 
> 
> Interpreter sizes on x86_64 release bits and `-XX:CodeEntryAlignment=16`:
> 
> 
> # Before
> code size        =     92K bytes
> avg codelet size =    347 bytes
> 
> # After
> code size        =     87K bytes
> avg codelet size =    331 bytes
> 
> 
> Point performance run (SPECjvm2008:serial) on x86_64:
> 
> 
> Before: 73.188 ± 0.113  ops/s
> After:  74.952 ± 0.356  ops/s
> 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`

Marked as reviewed by coleenp (Reviewer).

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

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