Skip to content
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

Add support for allocation limits on arenas #160

Merged
merged 17 commits into from
Aug 5, 2022
Merged

Commits on Aug 4, 2022

  1. Add support for allocation limits on arenas

    Arenas can optionally keep track of an `allocation_limit` which is
    considered when allocating new chunks to an arena.
    
    No new `new` methods were added, and limits must be set after the
    creation of a `Bump` arena. Limits can be changed on the fly and are
    only enforced when attempting to allocate new chunks.
    
    No changes were made to the errors returned by operations like `alloc`
    because of backwards compatibility.
    Eliasin committed Aug 4, 2022
    Configuration menu
    Copy the full SHA
    805f2b6 View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    22b8973 View commit details
    Browse the repository at this point in the history
  3. Make wording around allocation limits more specific

    Clarify that allocation limits are per `Bump` arena
    
    Co-authored-by: Nick Fitzgerald <[email protected]>
    Eliasin and fitzgen committed Aug 4, 2022
    Configuration menu
    Copy the full SHA
    5f0bf99 View commit details
    Browse the repository at this point in the history
  4. Configuration menu
    Copy the full SHA
    0046056 View commit details
    Browse the repository at this point in the history
  5. Configuration menu
    Copy the full SHA
    4456aab View commit details
    Browse the repository at this point in the history
  6. Refactor allocated_bytes to avoid walking chunk list

    ChunkFooter now tracks the allocated bytes, reducing the operation of
    retrieving the allocated bytes to a field lookup instead of a linear
    walk of the chunk list.
    Eliasin committed Aug 4, 2022
    Configuration menu
    Copy the full SHA
    33d1488 View commit details
    Browse the repository at this point in the history
  7. Clarify allocation limit enforcement

    Co-authored-by: Nick Fitzgerald <[email protected]>
    Eliasin and fitzgen committed Aug 4, 2022
    Configuration menu
    Copy the full SHA
    72e3573 View commit details
    Browse the repository at this point in the history
  8. Fix bump allocation limit section documentation at wrong level

    Co-authored-by: Nick Fitzgerald <[email protected]>
    Eliasin and fitzgen committed Aug 4, 2022
    Configuration menu
    Copy the full SHA
    bdaad5c View commit details
    Browse the repository at this point in the history
  9. Configuration menu
    Copy the full SHA
    f13bd35 View commit details
    Browse the repository at this point in the history
  10. Configuration menu
    Copy the full SHA
    29e9c2a View commit details
    Browse the repository at this point in the history
  11. Fix allocations on bumps with small limits exceeding limits

    To ensure that allocations do not exceed the allocation limit imposed on
    a `Bump`, the logic for calculating the final size of an allocated chunk
    was factored out into a separate function so that the limit enforcing
    code higher up in the control flow could more strictly enforce the
    allocation limit, as previously this code did not have visibility into
    the final size of an allocation request.
    
    To ensure that allocations in arenas with small limits could succeed,
    `alloc_layout_slow` was changed to allow bypassing the minimum chunk
    size for new chunks when trying to allocate in new arenas when the limit
    was lower than the default minimum chunk size.
    Eliasin committed Aug 4, 2022
    Configuration menu
    Copy the full SHA
    356dc34 View commit details
    Browse the repository at this point in the history
  12. Refactor new chunk allocation to avoid redundant calculations

    When allocating new chunks, the memory layout for new chunks was
    calculated twice, once for the code checking if the new chunk would
    violate allocation limits and once for the actual code allocating the
    new chunk.
    
    This change caches the calculated new chunk memory layout inbetween
    these steps to avoid the extra calculation.
    
    This change means that `new_chunk` must be marked `unsafe` as before
    this change `new_chunk` could guarantee that the memory details of a
    new chunk were safe (correct alignment, size, etc.), now that it is
    not responsible for calculating these details, callers can cause
    unsoundness through misuse of `new_chunk`.
    Eliasin committed Aug 4, 2022
    Configuration menu
    Copy the full SHA
    9ed1e7e View commit details
    Browse the repository at this point in the history
  13. Remove unnecessary flatten

    Eliasin committed Aug 4, 2022
    Configuration menu
    Copy the full SHA
    00256c2 View commit details
    Browse the repository at this point in the history
  14. Configuration menu
    Copy the full SHA
    00672c6 View commit details
    Browse the repository at this point in the history
  15. Remove stale comment

    Eliasin committed Aug 4, 2022
    Configuration menu
    Copy the full SHA
    cc79669 View commit details
    Browse the repository at this point in the history
  16. Configuration menu
    Copy the full SHA
    535da6c View commit details
    Browse the repository at this point in the history
  17. Configuration menu
    Copy the full SHA
    2339102 View commit details
    Browse the repository at this point in the history