-
Notifications
You must be signed in to change notification settings - Fork 110
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
Commits on Aug 4, 2022
-
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.
Configuration menu - View commit details
-
Copy full SHA for 805f2b6 - Browse repository at this point
Copy the full SHA 805f2b6View commit details -
Configuration menu - View commit details
-
Copy full SHA for 22b8973 - Browse repository at this point
Copy the full SHA 22b8973View commit details -
Make wording around allocation limits more specific
Clarify that allocation limits are per `Bump` arena Co-authored-by: Nick Fitzgerald <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 5f0bf99 - Browse repository at this point
Copy the full SHA 5f0bf99View commit details -
Configuration menu - View commit details
-
Copy full SHA for 0046056 - Browse repository at this point
Copy the full SHA 0046056View commit details -
Configuration menu - View commit details
-
Copy full SHA for 4456aab - Browse repository at this point
Copy the full SHA 4456aabView commit details -
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.
Configuration menu - View commit details
-
Copy full SHA for 33d1488 - Browse repository at this point
Copy the full SHA 33d1488View commit details -
Clarify allocation limit enforcement
Co-authored-by: Nick Fitzgerald <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 72e3573 - Browse repository at this point
Copy the full SHA 72e3573View commit details -
Fix bump allocation limit section documentation at wrong level
Co-authored-by: Nick Fitzgerald <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for bdaad5c - Browse repository at this point
Copy the full SHA bdaad5cView commit details -
Configuration menu - View commit details
-
Copy full SHA for f13bd35 - Browse repository at this point
Copy the full SHA f13bd35View commit details -
Configuration menu - View commit details
-
Copy full SHA for 29e9c2a - Browse repository at this point
Copy the full SHA 29e9c2aView commit details -
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.
Configuration menu - View commit details
-
Copy full SHA for 356dc34 - Browse repository at this point
Copy the full SHA 356dc34View commit details -
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`.
Configuration menu - View commit details
-
Copy full SHA for 9ed1e7e - Browse repository at this point
Copy the full SHA 9ed1e7eView commit details -
Configuration menu - View commit details
-
Copy full SHA for 00256c2 - Browse repository at this point
Copy the full SHA 00256c2View commit details -
Configuration menu - View commit details
-
Copy full SHA for 00672c6 - Browse repository at this point
Copy the full SHA 00672c6View commit details -
Configuration menu - View commit details
-
Copy full SHA for cc79669 - Browse repository at this point
Copy the full SHA cc79669View commit details -
Configuration menu - View commit details
-
Copy full SHA for 535da6c - Browse repository at this point
Copy the full SHA 535da6cView commit details -
Configuration menu - View commit details
-
Copy full SHA for 2339102 - Browse repository at this point
Copy the full SHA 2339102View commit details