Request for reviews (S): 6880034 for HS16 and HS17
Vladimir.Kozlov at Sun.COM
Tue Oct 6 10:07:57 PDT 2009
Thank you, John
I will push this to HS17 first and let it be tested for some time
before pushing to HS16.
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
> This is the right time to do such cleanups. Thanks!
> -- John
> On Oct 5, 2009, at 4:26 PM, Vladimir Kozlov wrote:
>> 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().
>> 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
More information about the hotspot-compiler-dev