JDK-8206345 : Test8007294.java failed: attempted to spill a non-spillable item
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10,11,12,13
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2018-07-04
  • Updated: 2022-02-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8209639 - assert failure in coalesce.cpp: attempted to spill a non-spillable item
Relates :  
JDK-8192992 - Test8007294.java failed: attempted to spill a non-spillable item
Description
This is a reopen of JDK-8192992 whose fix was found insufficient.

The problem is that a testN_mem_reg is matched but the load matching the mem to the test is far away from the jump and need to be spilled but can't be.

The first fix of JDK-8192992 with the follow ups JDK-8204157 and JDK-8205999 focused on the fact that the load was placed higher up than required. The scheduling in insert_anti_dependences is conservative for all phi and forces the LCA up. 

A proper fix need to search through phi nodes, like we do we mergemens, and hoisting the load only if a successor store is found. For loops, a store in the loop should force the load up above the phi, like currently. 

Fixing insert_anti_dependences is a full enhancements of its own. Possible quick fixes for this bug: 

1) Disable testN_mem_reg0 (only compressed oops with heapbase 0).
Possibly and add a peephole rule that can match this instruction when the load-test and jmp are in the same block.

2) Add some scheduling check to testN_mem_reg0 - the load-test and jmp need to be in the same block.
Comments
Things to evaluate: - Investigate if there is enough information around at matching to evaluate if the test_mem will cause a spill. - test_mem-loads might not be beneficial anymore - could be better to hoist and reorder load. - skip matching test_mem and add a peephole opt to fuse any candidates after global code motion. Deferring to 13
21-11-2018
Right, I'm fine with deferring for now if necessary but I agree that we should find a long term solution.
21-11-2018
There is a workaround for this issue in 12. So there is no urgency in fixing it. But we need a long term solution, because variants of this bug will pop up.
20-11-2018
Setting fix version to 12 for now. Please re-target if you want to fix this for JDK 11.
04-07-2018
ILW = Crash during compilation in register allocator (bailout in product builds), reproducible and happens when compiling common method but seems to be specific to -XX:+AlwaysIncrementalInline, disable compilation or use -XX:-SplitIfWithBlocks = MMM = P3
04-07-2018