8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I

[Christian Thalinger]

Looks good.  Maybe you should remove “64 bit” from the comments.

On Oct 30, 2013, at 1:16 PM, Roland Westrelin <roland.westrelin at oracle.com> wrote:

> Thanks for the review, Vladimir. Here is a new webrev:
> 
> http://cr.openjdk.java.net/~roland/8027445/webrev.01/
> 
> Roland.
> 
> 
> On Oct 30, 2013, at 8:09 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
>> On x86 in 64-bit mode any 32-bit arithmetic will clear upper 32 bits. That is why it is not problem on x86.
>> 
>> On SPARC we need explicitly clear upper bits. We have special macroassembler instruction signx(Register d ), please use it instead of sra(). And it can happen in 32 bit mode since SPARC's registers are 64-bit, so don't put it under #ifdef LP64.
>> 
>> You are correct about code in enc_String_Compare but for consistency I would suggest to do sign extension there too before next instruction (since chr1_reg is used later):
>> 
>> __ subcc(limit_reg, 1 * sizeof(jchar), chr1_reg);
>> 
>> One additional instruction outside a loop will not kill performance.
>> 
>> Thanks,
>> Vladimir
>> 
>> On 10/30/13 11:36 AM, Roland Westrelin wrote:
>>> http://cr.openjdk.java.net/~roland/8027445/webrev.00/
>>> 
>>> On 64 bit, the integer length input to the StrEquals node may have some bits set in its higher half and cannot be used directly for pointer arithmetic. StrComp is not affected because we add and subtract the length for each memory access. AryEq is not affected because we reload the length for both arrays. I added test cases for all of them anyway. I wasn’t able to reproduce it on x86 but it’s unclear to me whether something similar could happen or not.
>>> 
>>> Roland.
>>> 
>