Adapter sharing is broken with -XX:+ValueTypePassFieldsAsArgs

[Tobias Hartmann]

Hi Roland,

the problem was handling the empty value type receiver when processing java.lang.__Value.hashCode()I. We need to differentiate between a "T_VALUETYPE, T_VOID" signature and a "T_OBJECT, T_OBJECT" signature (T_OBJECT, T_VOID and T_VALUETYPE were widened to T_LONG).

Here's the new webrev:
http://cr.openjdk.java.net/~thartmann/valhalla/vt_prototype/webrev.13/

Thanks,
Tobias

On 27.03.2017 16:10, Tobias Hartmann wrote:
> Hi Roland,
> 
> thanks for looking at this!
> 
> On 27.03.2017 15:43, Roland Westrelin wrote:
>> Why the change lines 2254-2281?
>> You skip over the T_VALUETYPE/T_VOID markers, right?
> 
> Yes, I check for the T_VALUETYPE/T_VOID scope to avoid widening when we are passing the fields of a value type (see 'is_valuetype' argument of adapter_encoding).
> 
>> I don't think that's correct. With your change:
>>
>> class MyValue1 {
>>     int f1;
>>     long f2;
>> }
>>
>> class MyValue3 {
>>     int f1;
>> }
>>
>> class MyValue4 {
>>     long f2;
>> }
>>
>> class MyValue2 {
>>     MyValue3 f1;
>>     MyValue4 f2;
>> }
>>
>> MyValue1 and MyValue2 would share the same adapters but that would only
>> be correct if they have the same layout (because now adapters embed hard
>> coded offsets for fields). Is it true? Is it guaranteed that it doesn't
>> change in the future?
> 
> Right, that's not intended and probably not guaranteed in the future.
> 
> I tried to remove the 'continue' statements but that triggers the "failed: code must match" assert again. Investigating.
> 
> Thanks,
> Tobias
>