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

rework heap allocation api #93

Merged
merged 3 commits into from
Mar 20, 2024
Merged

rework heap allocation api #93

merged 3 commits into from
Mar 20, 2024

Conversation

tjjfvi
Copy link
Contributor

@tjjfvi tjjfvi commented Mar 20, 2024

  • Fixes UB when heap allocation fails
  • When no memory cap is passed, attempts to allocate 1 TiB, and steps down the size until the allocation succeeds
  • Simplifies the heap allocation API; there are now two main functions:
    • Heap::new_exact, which takes a size in words, and is a useful low-level API for testing/programmatic contexts
    • Heap::new is useful for user-controlled heap allocations; it takes an optional size in bytes, and falls back to the try-1-TiB-and-go-down-from-there approach

@FranchuFranchu can you confirm that running hvmc with no arguments works on your machine, still?

Also, @FranchuFranchu thoughts on this new API?

@tjjfvi tjjfvi requested a review from FranchuFranchu March 20, 2024 14:05
Copy link
Contributor

@FranchuFranchu FranchuFranchu left a comment

Choose a reason for hiding this comment

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

You might also want to change Cargo.toml and update the version field. We haven't reached 1.0 yet, but I think we should get used to semantically version hvm-core.

Comment on lines 17 to 18
/// Allocates a new heap with at most the given size in bytes.
pub fn new(bytes: Option<usize>) -> Option<Box<Self>> {
Copy link
Contributor

Choose a reason for hiding this comment

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

This doc comment is incorrect. It allocates exactly the given size in bytes.

If we wanted it to allocate at most the given size in bytes, then new should fall back to 1-TiB-and-go-down behavior when new_exact returns None

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, yeah, originally I had it step down from bytes.unwrap_or(1 << 40), but I thought it was undesirable if someone explicitly passed an amount of memory and it was silently downgraded.

@FranchuFranchu
Copy link
Contributor

can you confirm that running hvmc with no arguments works on your machine, still?

Works fine, and blazing fast.

thoughts on this new API?

It's correct and I believe it covers all usecases we have right now.

@tjjfvi tjjfvi requested a review from FranchuFranchu March 20, 2024 17:44
@tjjfvi tjjfvi enabled auto-merge March 20, 2024 18:10
@tjjfvi tjjfvi added this pull request to the merge queue Mar 20, 2024
Merged via the queue into main with commit 021babe Mar 20, 2024
5 checks passed
@tjjfvi tjjfvi deleted the rework-heap branch March 20, 2024 18:23
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.

2 participants