RFR: 8273122: ZGC: Load forwarding entries without acquire semantics
Erik Österlund
eosterlund at openjdk.java.net
Tue Aug 31 07:24:22 UTC 2021
On Mon, 30 Aug 2021 09:17:12 GMT, Hao Tang <github.com+7947546+tanghaoth90 at openjdk.org> wrote:
> JDK-8272138 introduced an unbound membar release() between the object copy and the forwarding table insertion.
>
> Thread A (Relocation):
> copy();
> release();
> cas_forwarding_table();
> cas_self_heal();
>
> The membar guarantees that the contents of the forwarded object are ready after a forwarding entry is loaded. Since load_object_content(ref) depends on the result of load_forwarding_table(), load_acquire can be safely changed to a simple load.
>
> Thread B (Remapping/Relocation):
> ref = load_forwarding_table(); // acquire (current version) -> relaxed (our proposal)
> load_object_content(ref);
>
> Our experiment on heapothesys demonstrates >5% time reduction spent on concurrent mark/relocation on AArch64.
>
> ---------
> ### Progress
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change must be properly reviewed
>
>
>
>
>
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
>
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.java.net/jdk pull/5298/head:pull/5298` \
> `$ git checkout pull/5298`
>
> Update a local copy of the PR: \
> `$ git checkout pull/5298` \
> `$ git pull https://git.openjdk.java.net/jdk pull/5298/head`
>
> </details>
> <details><summary>Using Skara CLI tools</summary>
>
> Checkout this PR locally: \
> `$ git pr checkout 5298`
>
> View PR using the GUI difftool: \
> `$ git pr show -t 5298`
>
> </details>
> <details><summary>Using diff file</summary>
>
> Download this PR as a diff file: \
> <a href="https://git.openjdk.java.net/jdk/pull/5298.diff">https://git.openjdk.java.net/jdk/pull/5298.diff</a>
>
> </details>
We usually do not relax things to rely on data dependency in C++ code, as the C++ standard gives us no guarantees that the data dependency will be retained in the generated machine code. It only gives threats that it might not work. In practice probably not, but still. So I don't know how I feel about this. Have you tried to use load consume instead? If that yields the same improvement, we can incorporate load_consume into HotSpot. I think that is an interesting experiment worth running first.
-------------
PR: https://git.openjdk.java.net/jdk/pull/5298
More information about the hotspot-gc-dev
mailing list