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

[Stuart Monteith]

Thank you for looking at it Coleen. I share your dissatisfaction with
webrev-4. I an uneasy about solving the problem in this way, as before
given narrow_klass_base and CompressedClassSpaceSize, you would know
what addresses to expect. However, this contract changed when during
dumping the class space size changes to 4GB, and
CompressedClassSpaceSize no longer matched this size. So webrev-3 is
my attempt to work round this by ignoring CompressedClassSpaceSize and
have another value tell us what we really want to know.
The name is perhaps less than ideal, but it really does contain an
implementation detail leaking into shared code. Perhaps I
misunderstood Andrew's intentions.

BR,
   Stuart

On 4 January 2018 at 14:26,  <coleen.phillimore at oracle.com> wrote:
> Hi 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.
>
> Coleen
>
>
> On 1/4/18 6:35 AM, Stuart Monteith wrote:
>>
>> Hello,
>>   Yes, I deleted a line by mistake. I've moved the calculation, as you
>> suggest, and hold the result in Universe:
>>
>>    http://cr.openjdk.java.net/~smonteith/8193266/webrev-4/
>>
>> I've changed the type of use_XOR_for_compressed_class_base from
>> uint64_t to bool, I saw no reason for it to be anything else.
>>
>> BR,
>>    Stuart
>>
>> On 3 January 2018 at 14:27, Andrew Haley <aph at redhat.com> wrote:
>>>
>>> On 03/01/18 13:53, Stuart Monteith wrote:
>>>>
>>>>     I've redone the patch such that we're passing different values
>>>> depending on whether we are dumping or are using shared classes. There
>>>> is a point before this initialisation where the  default is used,
>>>> which is 4GB:
>>>>
>>>> http://cr.openjdk.java.net/~smonteith/8193266/webrev-3/
>>>
>>> That looks good, except that you seem to have deleted a line
>>> (by mistake?) in universe.hpp.
>>>
>>> If I were doing this, I'd also take the opportunity to calculate
>>> can_use_XOR once, and take it out of the Assembler's constructor.
>>>
>>> --
>>> Andrew Haley
>>> Java Platform Lead Engineer
>>> Red Hat UK Ltd. <https://www.redhat.com>
>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>