Problem with testN_mem_reg0 in register allocation.
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Mon Aug 19 08:04:34 PDT 2013
Hi,
we are currently analyzing a bug in our jdk7 VM, which is based on
HS23. It happens on linux x86_64.
Register allocation tries to spill a RefFlags register, and, as to
expect, fails on this leading to a SIGSEGV.
I suspect this is a strange interdependency between gcm and
register allocation
Gcm produces something as the following pattern (I simplified
to get the essentials).
Block 35
Call
209 testN_mem_reg0
Catch
/ \
/ \
|/_ _\|
Block 36 Block 146
... ...
159 testP_reg
158 jmpCon(212)
\ /
\ /
_\| |/_
Block 39
...
/ \
/ \
|/_ _\|
Block 140 ...
208 jmpCon(209)
Then call_catch_cleanup() repairs the position of 209.
It adds 1088, 1089 and 1090.
Block 35
Call
Catch
/ \
/ \
|/_ _\|
Block 36 Block 146
1089 testN_mem_reg0 1088 testN_mem_reg0
... ...
159 testP_reg
158 jmpCon(212)
\ /
\ /
_\| |/_
Block 39
1090 Phi(1089, 1088)
...
/ \
/ \
|/_ _\|
Block 140 ...
208 jmpCon(1090)
Register allocation now wants to spill the register of 1088.
This is necessary as 159 needs the flag register.
Have you seen such a problem before?
We could envision that one the following 3 behaviors is expected and should get fixed:
1. gcm should place node 209 in Block 140.
2. Register allocation should be able to properly rematerialize the testN_mem_reg0 node (which does allow rematerialization).
This would require that it recognizes that the Phi merges twice the same value.
3. The matcher should not match this node (which matches on a Load and Cmp)?
Best reagrds,
Martin & Goetz.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130819/6c13cbd5/attachment.html
More information about the hotspot-compiler-dev
mailing list