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

John Rose john.r.rose at oracle.com
Thu Aug 7 22:57:16 UTC 2014

On Aug 7, 2014, at 3:23 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> 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.

This can be partially future-proofed by adding a tuning parameter which defaults to the cache line size.
That way we can easily re-test if we think the tuning point changes.

> 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?

Callee saves will get spilled in the general spill area, IIRC.  That will be near the callee SP, which is unpredictable.

I don't see any area in the generic frame layout which is reliably better than SP - CLSize.  Maybe SP - MaxTinyImmediateOffset, or the min of the two.

— John

>> 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

More information about the hotspot-compiler-dev mailing list