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

[Vladimir Kozlov]

Okay.

I forgot to ask why you need next change?:

-        graalHotSpotVMConfig.objectAlignment,
+        1 << graalHotSpotVMConfig.getOopEncoding().alignment,

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
>>>
>