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