[aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Thu Jan 11 12:29:58 UTC 2018


This looks good to me.   I will sponsor this fix, once we confirm the 
reviewers and you commit the patch and rerun the webrev (so it's in 
jdk10.patch).   I see this is for jdk10.

thanks,
Coleen

On 1/5/18 1:43 PM, Stuart Monteith wrote:
> I've removed the AARCH64 conditionals, added the empty line I removed,
> and changed the type of "use_XOR_for_compressed_class_base" to bool.
>
> http://cr.openjdk.java.net/~smonteith/8193266/webrev-5/
>
> BR,
>     Stuart
>
>
> On 4 January 2018 at 14:45, Andrew Haley <aph at redhat.com> wrote:
>> Hi,
>>
>> On 04/01/18 14:26, coleen.phillimore at oracle.com wrote:
>>>   I was going to offer to sponsor this since it touches shared code but
>>> I'm not sure I like that there's AARCH64 specific code in
>>> universe.cpp/hpp.   And the name is somewhat offputting, suggesting
>>> implementation details of one target leaking into shared code.
>>>
>>> set_use_XOR_for_compressed_class_base
>>>
>>> I think webrev-3 looked more reasonable, and could elide the #ifdef
>>> AARCH64 in the shared code for that version.   And the indentation is
>>> better.
>> I hate the #ifdef AARCH64 stuff too, but it's always a sign that there
>> is something wrong with the front-end to back-end modularization.  We
>> can handle the use_XOR_for_compressed_class_base later: we really
>> should have a way to communicate with the back ends when the memory
>> layout is initialized.  We can go with webrev-3.
>>
>> --
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



More information about the hotspot-dev mailing list