RFR: Common TLS access to GC state, where possible
Aleksey Shipilev
shade at redhat.com
Mon Jan 15 13:38:51 UTC 2018
On 01/15/2018 01:27 PM, Roman Kennke wrote:
> Am 15.01.2018 um 13:23 schrieb Aleksey Shipilev:
> I tried the initial Roland patch with traversal GC (against the then evac-in-progress flag), and
> have seen occurances of back-to-back evac-loads-checks that have not been common-ed. Roland is
> looking at it. I suggest to at least hold it back until this is resolved or confirmed to be a
> separate issue.
This is a separate issue, having nothing to do with barrier moves. This is about commoning the TLS
access, so that this:
testb $0x2, 0x3d8(TLS)
jne SLOW
...
testb $0x2, 0x3d8(TLS)
jne SLOW
...
becomes:
mov %r11, 0x3d8(TLS)
and $0x2, %r11
test %r11, %r11
jne SLOW
...
test %r11, %r11
jne SLOW
...
...saving the TLS access on back-to-back barriers, which are dormant anyhow.
> Also, I am not sure if the patch already does it: what about also moving up the actual tests? And
> thus creating longer paths with/without barriers? I suspect it would be slightly trickier now
> because of the different masks that it needs to check? It might not be very useful with default
> heuristics because we tend to interleave different barriers (SATB vs. evac), but may be
> tremendously useful for traversal GC, where we only have one phase and can thus group all the
> barriers into one path (enqueue, WBs, *hopefully* even RBs and acmp barriers), and remain
> barrier-free in another?
Let's have some perspective, and not put all our eggs in one basket, okay? This patch helps the
cases where (multiple) barriers cannot be optimized. It does not move the barriers around --
instead, it makes their fastpaths faster by not accessing the TLS every time.
The whole machinery actually helps both SATB and WB checks, because after recent GC state both SATB
and WB are checking against the same flag. It also aids future work, because it brings forward the
matchers for generic GC state loads, not only evac-in-progress loads. If you want to have the
barrier-free paths, you have to care about the generic GC state, not just evac-in-progress.
Please note the optimization is disabled by default, but we want the C2 scaffolding anyway.
-Aleksey
More information about the shenandoah-dev
mailing list