RFR: 8336944: Shenandoah: Should only relativize stack chunks for successful evacuations
Aleksey Shipilev
shade at openjdk.org
Tue Jul 23 11:18:45 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.
I suggest something like:
// Additional twist for stack chunks
if (copy_val->is_stackChunk()) {
// We need to call into relativization code for stack chunks. For that, we need
// a proper object with all metadata set right. There is a race with fwdptr
// installation from the thread that might have already won the CAS and over-written
// the mark word now holding the fwdptr, and we have just picked it up by accident.
// Additionally, memory copy is not atomic, so whatever we read from that mark word
// could be partial.
//
// Check that original mark is still not forwarded. This means no one have installed
// yet, and so we overwrite mark in our private copy with a safe value, relativize,
// and try to install the copy. In all other cases, the installation would fail.
markWord old_mark = p->mark();
if (!old_mark.is_marked()) {
copy_val->set_mark(old_mark);
ContinuationGCSupport::relativize_stack_chunk(copy_val);
}
}
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20288#issuecomment-2244959839
More information about the hotspot-gc-dev
mailing list