RFR(S) 8173054: [AOT] Avoid zero-shift for compressed oops

[Igor Veresov]

Thanks, Vladimir!

igor

> On Jan 20, 2017, at 11:19 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Okay.
> 
> Thanks,
> Vladimir
> 
> On 1/20/17 11:17 AM, Igor Veresov wrote:
>> 
>>> On Jan 20, 2017, at 7:53 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>> 
>>> Okay.
>>> 
>>> I forgot to ask why you need next change?:
>>> 
>>> -        graalHotSpotVMConfig.objectAlignment,
>>> +        1 << graalHotSpotVMConfig.getOopEncoding().alignment,
>>> 
>> 
>> Just for uniformity. We modify the compression settings that are returned by getOopEncoding(), it’s more consistent to query that instead of taking the host VM alignment (although right now it’s the same value).
>> 
>> igor
>> 
>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On 1/20/17 2:35 AM, Igor Veresov wrote:
>>>> Yes, you’re right. In fact there is a better way of doing it all. I’ll
>>>> just capture the alignment value, which would be the shift value in the
>>>> non-zero shift case.
>>>> 
>>>> Updated webrev: http://cr.openjdk.java.net/~iveresov/8173054/webrev.01/
>>>> 
>>>> igor
>>>> 
>>>>> On Jan 19, 2017, at 10:50 PM, Vladimir Kozlov
>>>>> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>>>> 
>>>>> Thank you, Igor
>>>>> 
>>>>> I am concern with object alignment value. I think it should be
>>>>> recalculated based on shift values in AOTGraalHotSpotVMConfig().
>>>>> 
>>>>> Vladimir
>>>>> 
>>>>> On 1/19/17 6:42 AM, Igor Veresov wrote:
>>>>>> AOT captures VM settings during compilation. For compressed oops it
>>>>>> presents a problem for the case when VM selects a zero-shift mode
>>>>>> (that depends on being able to map the heap into the lower 4G).
>>>>>> Compiling AOT binary with zero-shift limits it's usability. The AOT
>>>>>> compiler should be able to avoid zero-shift.
>>>>>> 
>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8173054/webrev.00/
>>>>>> 
>>>>>> Thanks,
>>>>>> igor
>>>>>> 
>>>> 
>>