Skip to content

Add a stop-the-world, serial Compressor #1340

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 20 commits into
base: master
Choose a base branch
from

Conversation

no-defun-allowed
Copy link
Collaborator

This PR adds a Compressor-esque garbage collector, which is based on MarkCompact but uses a mark bitmap for forwarding metadata like the Compressor.

@k-sareen k-sareen self-requested a review July 15, 2025 05:37
@no-defun-allowed
Copy link
Collaborator Author

The current failure to compile mock_test_allocator_info is a one-line fix, but I don't think the mock VM tests are going to work, as the mock VM uses header metadata and the Compressor requires mark bits to be in a side bitmap.

@k-sareen
Copy link
Collaborator

Thanks for the PR @no-defun-allowed! The major thing I see is that currently the Compressor plan is not using the LOS. Was this intentional or accidental?

@no-defun-allowed
Copy link
Collaborator Author

Thanks for the PR @no-defun-allowed! The major thing I see is that currently the Compressor plan is not using the LOS. Was this intentional or accidental?

Definitely accidental. Thanks for the review.

@qinsoon
Copy link
Member

qinsoon commented Jul 16, 2025

The current failure to compile mock_test_allocator_info is a one-line fix, but I don't think the mock VM tests are going to work, as the mock VM uses header metadata and the Compressor requires mark bits to be in a side bitmap.

You can cherry pick this commit to the PR: qinsoon@ac90d4b.

It runs mock VM with side metadata. Compressor currently fails for tests that are not using contiguous space.

@no-defun-allowed
Copy link
Collaborator Author

You can cherry pick this commit to the PR: qinsoon@ac90d4b.

Thanks!

It runs mock VM with side metadata. Compressor currently fails for tests that are not using contiguous space.

Right. Should we skip such tests when running with the Compressor?

@qinsoon
Copy link
Member

qinsoon commented Jul 16, 2025

It runs mock VM with side metadata. Compressor currently fails for tests that are not using contiguous space.

Right. Should we skip such tests when running with the Compressor?

Is there any intrinsic reason why the compressor cannot run with discontiguous spaces? I feel there is none. It would be better to allow running Compressor with discontiguous spaces.

At the same time, there might be practical reasons that this might be not easy, or it requires too much efforts. It is also okay to skip those tests.

@no-defun-allowed
Copy link
Collaborator Author

Is there any intrinsic reason why the compressor cannot run with discontiguous spaces? I feel there is none. It would be better to allow running Compressor with discontiguous spaces.

I feel that way too. The judgement was more about how closely we want to follow the Compressor paper - one simple approach to support discontiguous spaces would be to compress [sic] each chunk of a space, which would also give a simple way to parallelise (which is not the way in the paper).

The block offset vector is currently a Rust Vec<AtomicUsize> which I do the address-to-block calculation assuming a contiguous heap; I should be using some other metadata mechanism for that anyway.

@k-sareen
Copy link
Collaborator

The block offset vector is currently a Rust Vec which I do the address-to-block calculation assuming a contiguous heap; I should be using some other metadata mechanism for that anyway.

For what its worth, ART also uses a uint32_t* for the offset vector calculation.

@no-defun-allowed
Copy link
Collaborator Author

Now the block offset vector and the marks are in their own local metadata. I'm still undecided on if and how to support discontiguous spaces, since the forwarding algorithm in the Compressor paper seems very tied to having a contiguous space.

@qinsoon
Copy link
Member

qinsoon commented Jul 18, 2025

The failures for 32 bits was caused by this: #1342. However, you reverted the side metadata commit for mock VM, so the bug won't appear in the PR any way.

@qinsoon
Copy link
Member

qinsoon commented Jul 18, 2025

Now the block offset vector and the marks are in their own local metadata. I'm still undecided on if and how to support discontiguous spaces, since the forwarding algorithm in the Compressor paper seems very tied to having a contiguous space.

If that's the case, just skip the tests that use discontiguous space for Compressor.

@no-defun-allowed
Copy link
Collaborator Author

I added a MMTK_PLAN=discontiguous set to the CI script, for tests which require discontiguous heaps. The script also removes the Compressor from all on i686, since i686 defaults to a discontiguous heap too; some tests like test_vm_layout_default should still be tested on x86_64 but will panic on i686.

@k-sareen
Copy link
Collaborator

I've made an issue for the commit that fixes the space mapping since it's a very subtle bug that I think can be checked with assertions (cd3bde3): #1343

@k-sareen k-sareen requested a review from qinsoon July 21, 2025 04:59
Copy link
Member

@qinsoon qinsoon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found the Transducer implementation is not easy to understand. A bit more comments would be helpful.

We probably also need a PR for OpenJDK that supports Compressor.

@@ -197,6 +197,9 @@ extreme_assertions = []
# Enable multiple spaces for NoGC, each allocator maps to an individual ImmortalSpace.
nogc_multi_space = []

# Disable multiple spaces for Compressor.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reason that we want to keep this feature? Would it be useful to anyone?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be the most space-efficient an algorithm can be. I believe Steve mentioned it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@no-defun-allowed Just mention in the comment there that this is configuration will move all objects. Don't use if you can't tolerate that. This is primarily for understanding how space-efficient we can be.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. Also the non-moving semantic can't be used with this feature.

It would be better if we can panic when the non-moving semantic is ever used. This probably would need a 'fake allocator' that panics when used, and the non-moving semantic is mapped to it. I am not sure if it is worth it.

/// each block by serialising the state using [`Transducer::encode`];
/// the state can then be deserialised using [`Transducer::decode`].
#[derive(Debug)]
struct Transducer {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a bit hard to understand how this type works. More comments would help. For example, explain what each fields mean. Also you could comment step to say that address is always either the start of an object, or the end of an object, etc.

@qinsoon qinsoon requested a review from wks July 21, 2025 05:56
@qinsoon
Copy link
Member

qinsoon commented Jul 21, 2025

I also requested reviews from @wks

Copy link
Collaborator

@k-sareen k-sareen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the updates! I think it looks pretty good now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants