<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - REGRESSION(r213645): It made JSC tests super slow and timeout on AArch64 Linux"
href="https://bugs.webkit.org/show_bug.cgi?id=169510#c2">Comment # 2</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - REGRESSION(r213645): It made JSC tests super slow and timeout on AArch64 Linux"
href="https://bugs.webkit.org/show_bug.cgi?id=169510">bug 169510</a>
from <span class="vcard"><a class="email" href="mailto:fpizlo@apple.com" title="Filip Pizlo <fpizlo@apple.com>"> <span class="fn">Filip Pizlo</span></a>
</span></b>
<pre>We should figure out what's going on here. This is probably not a Linux versus Darwin thing but a CPU model thing.
Here's a possible hint: <a href="http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150921/300953.html">http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150921/300953.html</a>
It looks like in LLVM, they have to emit clrex when exiting ldx/stx (LL/SC) loops because "some uarchs" need it for "performance". I tried emitting clrex, and on my hardware, it made no difference.
I think in our jargon, "clrex" should be called "WTF::clearLink()", since we use the old computer science terminology for this (load link, store conditional) rather than the ARM terminology (reservations). The way this would look like is that you'd want Atomic<>::transaction() to call clearLink() whenever it returns after having done a loadLink() but before the storeCond() - basically anytime that we would otherwise be leaving the link (the reservation) in place.
If this works then just as transaction() abstracts LL/SC and CAS behind prepare/attempt, you probably want a giveUp() method that is a wrapper for clearLink() on LL_SC platforms and a no-op on CAS platforms. You probably want clearLink() to only be declared when HAVE(LL_SC) just as loadLink()/storeCond() are only declared when HAVE(LL_SC).
I think it's OK to do clearLink() on all ARM64s, if it helps your perf.
If this works, then can you also put a FIXME in B3LowerToAir's code that emits loadlink/storecond, and MacroAssembler's loadLink/storeCond code, and link it to a bug? Once I get around to implementing SharedArrayBuffer atomics, I'll definitely need to use MacroAssembler's and B3's LL/SC. It won't be possible to easily get around this.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>