Request for reviews (S): 6880034 for HS16 and HS17
John.Rose at Sun.COM
Mon Oct 5 22:38:37 PDT 2009
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!
On Oct 5, 2009, at 4:26 PM, Vladimir Kozlov wrote:
> Fixed 6880034: SIGBUS during deoptimisation at a safepoint on 64bit-
> 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