RFR: AArch64: 8179954: AArch64: C1 and C2 volatile accesses are not sequentially consistent
Andrew Haley
aph at redhat.com
Wed May 10 06:07:25 UTC 2017
On 09/05/17 22:39, White, Derek wrote:
> My only comment is in src/cpu/aarch64/vm/templateTable_aarch64.cpp, TemplateTable::getfield_or_static():
>
> The comment in the trailing member around line 2542 says:
> - "It's really not worth bothering to check whether this field
> really is volatile in the slow case."
>
> But getfield_or_static() is used once to "quicken" getfield byte
> codes, as well as used forevermore on all getstatic bytecodes (and
> some weird cases in class sharing?).
>
> I can't claim that makes a definite performance difference (it's
> just the interpreter), but adding an additional unconditional membar
> might make it more likely to matter.
>
> FYI, the ppc and arm64 ports do check if the field is volatile
> before executing the membar (s in the ppc case).
Sure. There's always a trade-off between code complexity and absolute
speed, and we tend to concentrate our fire where it can help the most,
and that's probably not in the slow getfield part of the interpreter.
I know that mispredicted branches hurt, and that fence instructions
hurt; I don't know which hurts the most in general. I'm not at all
sure that the conditional branches around the fences are right, and it
might work better if they all were removed. The right way to fix this
case is to rewrite the interpreter to use stlr and ldar, but that's
too complex for JDK9. It'd be nice to get it done for JDK10.
So yeah, you might have a point, but I really don't think it's worth
changing the patch for JDK9.
Andrew.
More information about the hotspot-dev
mailing list