Skip to content

Conversation

wks
Copy link
Collaborator

@wks wks commented Oct 9, 2025

We remove OnAllocationFail and add three boolean fields to AllocationOptions:

  • eager_polling: whether to poll before acquiring pages from the page resource
  • allow_overcommit: whether we allow overcommit
  • at_safepoint: whether this allocation is at a safepoint

This will allow new combinations that cannot be expressed by the previous OnAllocationFail type. Particularly, it allows both polling and over-committing to happen in one allocation attempt. If this allocation is also not at a safepoint, this combination will allow the current mutator to allocate normally in this allocation, but block for GC at the nearest safepoint.

Note: This PR implements the idea proposed in #1382 (comment). I created a new PR because the resulting commit will be radically different from #1382.

TODO:

  • Rebase this PR upon Refactor Space::acquire #1401 after Refactor Space::acquire #1401 is merged.
  • Check if AllocationOptions can still be stored and loaded atomically. It should suffice if its size is smaller than the word size. If Rust is unhappy with three boolean fields, replace it with a bit field. AllocationOptions cannot be loaded or stored atomically. We replaced Atomic with RefCell.

This PR supersedes the following PRs:

@wks wks mentioned this pull request Oct 10, 2025
wks added 2 commits October 13, 2025 17:54
We remove OnAllocationFail and add three boolean fields to
AllocationOptions.
@wks wks force-pushed the feature/overcommit-still-triggers-gc3 branch from 59ff447 to fa47af7 Compare October 13, 2025 10:04
@wks
Copy link
Collaborator Author

wks commented Oct 13, 2025

After this PR, the decision tree becomes: (assuming this is a mutator thread, and GC is already initialized)

  • Does the allocation option allow eager polling
    • If yes, poll, and move on.
    • If no, just move on.
  • Is any of the following true? (a) The poll above didn't trigger GC (Consider it "not triggered" if we skipped polling), or (2) the allocation option allows over-commit
    • If yes, try to get pages from the page resource, and move on.
    • If no, just move on.
  • Have we got pages from the page resource?
    • If yes, do the mmapping and return the address.
    • If no, are we at safepoint?
      • If yes, then
        • Have we tried getting new pages from the page resource?
          • If yes, force a GC, and move on.
          • If no, just move on.
        • block for GC.
        • return NULL.
      • If no, then return NULL immediately.

The control flow is more linear than before, with three steps, each using one boolean option.

By combining the three options, we can replicate the behaviors of the previous OnAllocationFail variants.

Variant eager_polling allow_overcommit at_safepoint
RequestGC true false true
ReturnFailure true false false
OverCommit false true false

We can make a new combination to poll (scheduling GC in the background) and overcommit at the same time, and postpone blocking for GC to the next safepoint. This can be useful for VMs where allocation never happens at safepoints.

new behavior eager_polling allow_overcommit at_safepoint
both poll and overcommit true true false

But I wonder whether we can remove the eager_polling option (i.e. always making it true). I can't think of any use cases where we don't want to poll. Polling only affects GC threads in the background. Even if GC is not initialized at this time, GC workers will be able to start the first GC immediately after GC is initialized. So it seems to be harmless to let it poll all the time.

@wks wks marked this pull request as ready for review October 14, 2025 07:54
@wks wks requested a review from qinsoon October 14, 2025 07:54
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.

1 participant