RFR (M) 8135085: Change Method::_intrinsic_id from u1 to u2

[Coleen Phillimore]

Hi Aleksey,

Increasing the size of this field unfortunately gives us a pretty large 
alignment gap in Method* which will affect footprint.

The good news is that the field _method_size is not actually needed.   
In order to increase intrinsic_id, you should also remove this field at 
the same time.   Then we'll only have a u1 alignment gap which we can 
use for something in the future.

Also, because you changed the vmStructs, there's likely a Java 
duplicated code change to make in the serviceability agent.   There 
should be a basic test in the jtreg hotspot/test/serviceability/sa.   
You should run more tests on a change like this.   I will send you 
directions on how to run RBT internally.

thanks,
Coleen

On 9/9/15 1:22 PM, Aleksey Shipilev wrote:
> Hi,
>
> In VarHandles development, we have reached the tipping point when
> Method::_intrinsic_id is not enough to be u1, as we have >255 intrinsics:
>    https://bugs.openjdk.java.net/browse/JDK-8135085
>
> This is a patch that changes u1 -> u2:
>    http://cr.openjdk.java.net/~shade/8135085/webrev.00/
>
> Quite a few places in VM assume the _instance_id size, I changed those
> as well, and also put more asserts where we assume the particular value
> width.
>
> Testing:
>    * JPRT on all platforms
>    * Method::Method instrumentation to figure out the number of Methods
> and their sizeof-s. There seems to be no regression in Method instance
> size at least on Linux x86_64, because the instance alignment seems to
> have enough gaps to fit the larger u2 field. (I played more, and it
> seems three more u1 fields can be fitted in).
>
> Please review! If there are any problems/concerns, could anyone from
> runtime team please take over this work? We will use this prototype
> version in VarHandles to unblock the development for the time being.
>
> Thanks,
> -Aleksey
>