Perf: SATB and WB coalescing

Aleksey Shipilev shade at redhat.com
Wed Jan 10 20:29:16 UTC 2018


On 01/10/2018 12:43 PM, Aleksey Shipilev wrote:
> On 01/10/2018 12:35 PM, Roman Kennke wrote:
>> Ah!
>> I made something like this a while ago and it hasn't gone in back then:
>> http://cr.openjdk.java.net/~rkennke/gc-phase-flag/webrev.01/
> 
> I still think the phases themselves are inconvenient to encode, because they don't say everything
> about the heap. For example, you would want to disambiguate the idle phase that has forwarded
> objects waiting for CM-with-UR to fix stuff up, and idle phase where everything is fixed up. Maybe
> just introducing separate "idle" and "idle-need-fixup" phases would be enough?

Ah, that is probably solved by treating need_update_refs specially.

> Then we can approach compiler checking for "idle" state, and optimize the happy path accordingly.

Okay, so the dirty patch for the idea:
  http://cr.openjdk.java.net/~shade/shenandoah/single-flag/webrev.00/

perfasm for the offending test:
  http://cr.openjdk.java.net/~shade/shenandoah/single-flag/single-flag.perfasm

Both SATB and WB are checking off the same TLS flag.

Now, two ideas:

 *) The way the patch is structured now, successful testb $0x0, 0x3d8(%r15) means no barriers are
required until the next safepoint poll (e.g. no marking, no evac, no update-refs, no partial, and
*no need to update refs*) -- which means the heap is as stable as it gets;

 *) Can we instruct compiler to trust the value of 0x3d8(%r15) until the next safepoint poll? I
think that would eliminate excessive L1 accesses for that TLS field at expense of wasting a register
-- which might be the lesser evil;

-Aleksey



More information about the shenandoah-dev mailing list