add `ConcurrentStickyImmix` collector

[oscardssmith]

TL;DR

We have ConcurrentImmix and StickyImmix, but having the combination will be useful for use-cases that have higher allocation load than ConcurrentImmix can support while still valuing low pause times.

Goals

• Low pause times of ConcurrentImmix
• Taking advantage of Generational hypothesis

Success Metric

The GC is implimented

Motivation

This will be a useful collector for languages as an intermediate step to LXR. LXR has some additional requirements, while ConcurrentStickyImmix should be just as easy to support on the runtime side as ConcurrentImmix

Description

This is the main section of the MEP. Describe the enhancement in detail.

If you have already made prototype implementations for this MEP, add hyperlinks to the relevant PRs,
commits, repositories, etc.

If not, describe how you intend to implement this MEP. You should think about all parts of
mmtk-core that your MEP may interact with.

This section will be long. Feel free to add more subsections.

Impact on Performance

This should be a higher performance GC than ConcurrentImmix

Impact on Software Engineering

unknown

Risks

Long Term Performance Risks

There shouldn't be any. This would be a separate algorithm and imposes no constraints on other algorithms.

Long Term Software Engineering Risks

This would involve introducing additional code.

Impact on API

This shouldn't have any API impacts

Alternatives

It's possible that the language changes needed to support LXR are small enough that this isn't necessary, but at the very least, I think it would be beneficial to have a "normal" high performance concurrent collector as a performance baseline for LXR to benchmark against.

[qinsoon]

Implementing ConcurrentStickyImmix is probably not hard, and it is a good exercise to validate the reusability of MMTk core components (given that StickyImmix and ConcurrentImmix are already implemented). However at this point, I do not see a strong reason to prioritize its implementation

For the Julia binding, the work of integrating concurrent Immix is to verify the feasibility of running concurrent GCs with Julia. Once it is working, we could proceed directly to nonmoving LXR. Integrating LXR may just impose a similar level of complexity on the binding side compared to integrating concurrent sticky immix, which makes it a more compelling next step. However, if we encounter difficulties when integrating LXR, concurrent sticky immix could serve as an intermediate solution, at which point it may be worth prioritizing its implementation.

[oscardssmith]

Agreed that this isn't high priority if LXR gets merged into MMTK-core.