RFR: 8336944: Shenandoah: Should only relativize stack chunks for successful evacuations

Aleksey Shipilev shade at openjdk.org
Tue Jul 23 12:09:32 UTC 2024


On Mon, 22 Jul 2024 23:56:46 GMT, William Kemper <wkemper at openjdk.org> wrote:

> In some cases, different threads may race to evacuate an object. The race is won by "CAS"ing in the forwarding pointer. The threads that lose this race must "back out" their allocation. The work to relativize stack chunks should only happen for the thread that wins the evacuation race.

Marked as reviewed by shade (Reviewer).

So, my original concern was that doing relativization on already public `StackChunk` instances exposes us to more risk. But now I am looking around, and seeing we actually doing this during marking as well, which is an even more frequent case!

https://github.com/openjdk/jdk/blob/e83b4b236eca48d0b75094006f7f888398194fe4/src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp#L75-L79

So I think we can go with a simple patch here.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1185:

> 1183:     // Successfully evacuated. Our copy is now the public one!
> 1184:     shenandoah_assert_correct(nullptr, copy_val);
> 1185:     ContinuationGCSupport::relativize_stack_chunk(copy_val);

Please move it before the assert, so that we are sure relativization did not foobar the `copy_val`. Asserts in these methods verify that we return good things.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20288#pullrequestreview-2193791051
PR Comment: https://git.openjdk.org/jdk/pull/20288#issuecomment-2245060685
PR Review Comment: https://git.openjdk.org/jdk/pull/20288#discussion_r1687944160


More information about the hotspot-gc-dev mailing list