Request for reviews (S): 6880034 for HS16 and HS17

[Vladimir Kozlov]

Thank you, John

I will push this to HS17 first and let it be tested for some time
before pushing to HS16.

Thanks,
Vladimir

John Rose wrote:
> I believe the only sane way to number the 32-bit halves of 64-bit values 
> is with some sort of consistently applied rule.  Given that goal, the 
> most consistent rule is to appeal first to memory storage order (first 
> word then second word in memory layout) and project that order into the 
> register file.  This means arithmetic order is irrelevant to naming 
> conventions, since the "high" word is the first word on big-endian 
> systems, but the second word in x86, etc.
> 
> The present fix is a good cleanup which makes register numbering more 
> consistent.  (Historically, the SPARC code of HotSpot was ported from 
> x86, where an arithmetic low-order word is also the memory first-order 
> word.  On Intel you can be sloppy about which is the "high word", but on 
> a big-endian machine you cannot.  The SPARC code still has some traces 
> of sloppiness.)  Note that the integer registers are still 
> inconsistently numbered from this viewpoint.
> 
> In order to cope with a buggy choice of subword numbering, we have (in 
> the past) debugged our way to a bunch of local fixes where the words are 
> swapped as needed, at each use point.  Doing a cleanup like this might 
> have a bug tail (which is why we haven't been eager to attempt it).  The 
> bug tail, if it exists, will manifest in further stack walker or 
> deoptimization bugs where words get swapped, and (upon examination) the 
> swapping code can be simply deleted, given the more rational numbering 
> scheme.
> 
> This is the right time to do such cleanups.  Thanks!
> 
> -- John
> 
> On Oct 5, 2009, at 4:26 PM, Vladimir Kozlov wrote:
> 
>>
>> http://cr.openjdk.java.net/~kvn/6880034/webrev.01
>>
>> Fixed 6880034: SIGBUS during deoptimisation at a safepoint on 64bit-SPARC
>>
>> Problem (found and described by Volker Simonis):
>>  Wrong numbering of the 16 upper double registers in sparc.ad
>> maps the invalid half (R_D32x, R_D34x, ..) of the double
>> registers F32-F62 to even VMReg numbers (96, 98, ..) and the valid
>> part (R_D32, R_D34, ..) to odd VMReg numbers (97, 99, ..). Later on,
>> when the locals array for the safepoint is constructed in
>> Compile::FillLocArray(), the call to OptoReg::as_VMReg(regnum) for a
>> valid, even double register >= F32 (e.g. 96) returns the invalid, odd
>> part (e.g. 97). This odd VMReg number is than stored in the Location
>> part of the local and leads to the the fact that reg->reg2stack()
>> returns odd values for float registers >= F32.
>> This finally leads to a BUS error due to an unaligned double read
>> when the location of the register is accessed through the reg_map
>> during deoptimisation in StackValue::create_stack_value().
>>
>> Solution:
>> Fix the double register encodings in sparc.ad.
>> Use FloatRegisterImpl::number_of_registers instead of 64
>> in RegisterSaver::save_live_registers() and restore_live_registers().
>> Replace if(true) with comments in save_live_registers().
>>
>> Contributed by: volker.simonis at gmail.com
>>
>> Reviewed by:
>>
>> Fix verified (y/n): y, bug's test
>>
>> Other testing:
>> JPRT, CTW
>>
>