RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages

[Aleksey Shipilev]

On 08/08/2014 01:28 AM, John Rose wrote:
> On Jul 23, 2014, at 11:38 AM, Aleksey Shipilev
> <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote:
> 
>> It seems odd this affects Haswell so much. I've checked on my
>> SandyBridge laptop, and we have the same code, but performance is
>> consistent. Barring that, it would seem like some the second-order
>> microarchitectural effect on Haswell. ...which makes me say this is the
>> mode we should switch to:
>>
>>> ...or "lock addl (%esp-CL-8), 0), pessimistically padding away from
>>> stack users:
>>>  http://cr.openjdk.java.net/~shade/8050147/webrev.02/
>>> <http://cr.openjdk.java.net/%7Eshade/8050147/webrev.02/>
> 
> It's plausible, safe, clean, well-documented, and helps with real chips.
> What's not to like?
> You can count me as a reviewer.

Thanks John. I have second thoughts about this, however.

Since the effect seems to be related to callee-saves, I would rather
step back for some machine-independent constant. Tying in the cache line
size seems not to be future proof, especially if we ever come across the
machine with >128 byte cache lines, which will blow up the instruction
encoding with unknown effects.

Vladimir pointed where to look for frame structure [1], but I still
haven't parsed it to make an educated guess about how much to step back.
Any ideas?

> Nit:  sp+C made me itchy, even though it is clarified several sentences
> down that C<0.  Might as well lead off with sp-C.

Yes, needs fixing in the comments.

Thanks,
-Aleksey.

[1]
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/0b9afe536f5c/src/cpu/x86/vm/x86_64.ad#l2549