I don't think you should set this - it isn't needed and also it might clobber stw_request which isn't entirely protected by all_domains_lock in caml_try_run_on_all_domains_with_spin_work.

Remove this line?

Good catch. Looks like a copy-paste error. I'll remove this line.

I'll also remove the assertion on the next line:

CAMLassert(!d->interruptor.interrupt_pending);

It is unclear to me why this is expected to hold.

IIUC there is some involved logic to make sure that other domains work enough for the major GC before being forced into a minor collection.

Here is another possible approach (this is for the record, as I had the chance to propose this to KC verbally already).

• Every time a minor collection is needed while the minor heap is half-empty, do a stop&copy collection into the free half of the minor heap. This reduces the amount of false promotions and (what is important here) avoids increasing the work debt for the major GC.
• Every time a minor collection is needed before the major slice is done, simply transfer the work debt to the next minor cycle.

Note: the major slice happens when the minor-heap is half-full, so the two trigger conditions coincide. Therefore, the major slice can be delayed, but the work debt never accumulates.

In this approach, any additional work needed to keep up with phase changes (see ocaml#11589) should be accounted for separately from the slice-at-middle rendez-vous.

Hi @gadmm, I'm trying to understand how the proposal to perform stop & copy collection in the minor heap is solving the current problem. I'd think that is an orthogonal improvement. Perhaps your intention is to document future GC improvements. Not sure what the best place for this would be. Perhaps ocaml/RFCs?

There are some (not insurmountable) challenges with implementing this copying collection for minor heap given that we may have pointers between the minor heap arenas of different domains. A parallel copying collector will have to synchronize to copy the objects to the to_space. While I've implemented simple Cheney copying collectors before, I don't know the state of the art in parallel copying collections.

Coming back to the lines of code under discussion, in practice, I would think that the best-effort interruption above would work well. If the lock is not obtained, the worst that can happen is that the major slice is pushed to after the next minor collection on the other domains.

Your current strategy is to trigger slices on all domains as soon as one domain reaches half of the minor heap. This is a bit heuristic, for instance due to scheduling hazards mutators on other domains could very well barely be restarting after the minor collection, in which case the splitting will not be effective in reducing latency. It might very-well work in practice, but I was pointing out that there is no need for a heuristic approach, since with the semispace copying approach, the logic for when to do a slice is independent of the work of other domains.

I would not make this suggestion here if I thought it was as complex as you seem to think. I will be happy to discuss details elsewhere but ocaml/RFCs is probably not a good place for this (this concerns the implementation rather than a language change, and also some insiders discouraged in private its use so I do not know what to think about it).

I am not worried about the try_lock; have you considered accessing the interruptor via all_domains instead of stw_participants to avoid having to lock at all? (see this approach here: ocaml@dcb6520#diff-67115925103982a8ebeb085cfab5ef31a182c9a442bc51e053934364d3750dafR1507-R1517)

I would not make this suggestion here if I thought it was as complex as you seem to think.

As with anything in the GC implementation, my experience is that, for anything that is not trivial, there is typically a significant amount of implementation, debugging and tuning effort required. My approach has been to hack up a prototype and only test it on the best-case input for that design. If that is promising, then start implementing that feature for real.

I will be happy to discuss details elsewhere but ocaml/RFCs is probably not a good place for this (this concerns the implementation rather than a language change, and also some insiders discouraged in private its use so I do not know what to think about it).

I shall bring this up again with the caml-devel.

have you considered accessing the interruptor via all_domains instead of stw_participants to avoid having to lock at all? (see this approach here: ocaml@dcb6520#diff-67115925103982a8ebeb085cfab5ef31a182c9a442bc51e053934364d3750dafR1507-R1517)

Is this safe? I am worried about races wrt other operations such as spawning and terminating domains. It felt uneasy to muck with their interruption flag and young limit. If this is safe, it would be nice to write down the guarantee for such a global interruption as code comments along with a short account of why. What do you think?

Given that triggering slices on other domains happens once every minor GC cycle, the current approach of taking the lock for interruption should not be expensive.

The PR I pointed to (ocaml#11307) has to make a minor change to synchronize the read of interruptor_word with domain initialization. Modulo this change, this is safe because interruptor_word is set once and for all. I think ocaml#11307 documents enough the needed synchronisation but let me know if it is unclear (let's discuss it over there). Once ocaml#11307 is accepted, the function caml_interrupt_all_for_signal can be freely re-used for this purpose.

I don't have objections to the current heuristic for triggering slices nor to taking the lock, this is taking a good shot at a first implementation of the feature.

The condition d->major_slice_epoch < atomic_load (&caml_major_slice_epoch) playing the role of the payload of an inter-domain interruption, it should be added among the conditions checked at the end of caml_reset_young_limit. Otherwise, a race might lead to the interrupt being dropped.

Like this 0831bc3?

Yes, this looks right. As a cosmetic comment, I think it would be clearer to read by giving it name.