RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages
aleksey.shipilev at oracle.com
Thu Aug 7 22:23:02 UTC 2014
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:
> 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 , but I still
haven't parsed it to make an educated guess about how much to step back.
> 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.
More information about the hotspot-compiler-dev