compressed oops and stack slots
Deneau, Tom
tom.deneau at amd.com
Mon Jul 1 12:45:53 PDT 2013
I noticed our stackAlignment in our targetDescription was 1, setting that to 8 (same as wordsize) solved the problem.
Not sure why this didn't affect us somewhere else.
-- Tom
-----Original Message-----
From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Deneau, Tom
Sent: Monday, July 01, 2013 1:12 PM
To: graal-dev at openjdk.java.net
Subject: compressed oops and stack slots
Now that graal supports compressed oops,
I have been implementing the support for compressed oops in the HSAIL backend.
The basic mechanisms seem to be working and almost all of our test cases pass
with compressedOops off or on (including with a heap that is large enough such
that the compression requires a shift).
However, we have one test case that is failing, it does use spills to stack slots
and I think it is the only one of our tests that has a mixture of 32-bit spills
and 64-bit spills. (This test works fine with compressedOops off).
With compressedOops on, we are hitting the assert in FrameMap.indexForStackSlot
(called from FrameMap.setReference)
public int indexForStackSlot(StackSlot slot) {
assert offsetForStackSlot(slot) % target.wordSize == 0;
return offsetForStackSlot(slot) / target.wordSize;
}
In our case
* with +UseCompressedOops , the slot has offset -32, totalFrameSize is 44 so offsetForStackSlot(slot) is 12.
which fails the assertion since target.wordSize is 8
* with -UseCompressedOops , the slot has offset -32, totalFrameSize is 40 so offsetForStackSlot(slot) is 8.
which passes the assertion (target.wordSize is 8)
>From the above information, can you folks tell what I should be doing so that this test works correctly with CompressedOops on?
-- Tom Deneau
AMD
More information about the graal-dev
mailing list