Fix ephemeron-adoption problem in mark-delay #3332
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes a problem found by CI when upstreaming mark-delay (#2348 / #2358 / #3029) in ocaml/ocaml#13580. The problem concerns adopting ephemerons which have been orphaned by a terminating domain. They are marked by the terminating domain, so survive that GC cycle. They are then adopted at the start of marking in the next cycle, when they should be unmarked (due to the major GC cycle colour-switch). However, at present all domains attempt to adopt orphans at the start of marking, without a subsequent barrier, so it is possible for the terminating domain to get past this point, mark the ephemerons and then orphan them, before some other domain attempts to adopt and picks up the ephemerons. The fact that the ephemerons have already been marked in this cycle is detected in the debug runtime by a failing assertion. It is unclear whether this difference in marking is harmless; the multicore major GC ephemeron marking system is complex and it seems unwise to change this behaviour. In this PR, orphan adoption is moved inside the barrier at the start of marking; it starts with a very cheap check (
no_orphaned_work()
) so this change is almost free in the common case and fairly cheap even if there are orphans.This problem was detected by the ocaml-multicore/multicoretests run automatically by CI on ocaml/ocaml#13580 due to the
run-multicoretests
label.This is one of the three fixes in #3297, which @mshinwell asked to be separated out.