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

Replace {Alloc,GlobalAlloc}::oom with a lang item. #50144

Merged
merged 3 commits into from
Apr 22, 2018

Conversation

sfackler
Copy link
Member

The decision of what to do after an allocation fails is orthogonal to the decision of how to allocate the memory, so this PR splits them apart. Alloc::oom and GlobalAlloc::oom have been removed, and a lang item has been added:

#[lang = "oom"]
fn oom() -> !;

It is specifically a weak lang item, like panic_fmt, except that it is required when you depend on liballoc rather than libcore. libstd provides an implementation that aborts with the message fatal runtime error: memory allocation failed, matching the current behavior.

The new implementation is also significantly simpler - it's "just another weak lang item". RFC 2070 specifies a path towards stabilizing panic_fmt, so any complexities around stable weak lang item definition are already being solved.

To bootstrap, oom silently aborts in stage0. alloc_system no longer has a bunch of code to print to stderr, and alloc_jemalloc no longer depends on alloc_system to pull in that code.

One fun note: System's GlobalAlloc implementation didn't override the default implementation of oom, so it currently aborts silently!

r? @alexcrichton

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 21, 2018
name: "oom",
inputs: &[],
output: AllocatorTy::Bang,
},
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: don't need AllocatorTy::Bang anymore

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed, thanks

@alexcrichton
Copy link
Member

@bors: r+

That was easier than I thought it would be!

@bors
Copy link
Contributor

bors commented Apr 21, 2018

📌 Commit b301d05 has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 21, 2018
@bors
Copy link
Contributor

bors commented Apr 22, 2018

🔒 Merge conflict

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Apr 22, 2018
@sfackler
Copy link
Member Author

@bors r=alexcrichton

@bors
Copy link
Contributor

bors commented Apr 22, 2018

📌 Commit 5969712 has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 22, 2018
@bors
Copy link
Contributor

bors commented Apr 22, 2018

⌛ Testing commit 5969712 with merge e028687...

bors added a commit that referenced this pull request Apr 22, 2018
Replace {Alloc,GlobalAlloc}::oom with a lang item.

The decision of what to do after an allocation fails is orthogonal to the decision of how to allocate the memory, so this PR splits them apart. `Alloc::oom` and `GlobalAlloc::oom` have been removed, and a lang item has been added:

```rust
#[lang = "oom"]
fn oom() -> !;
```

It is specifically a weak lang item, like panic_fmt, except that it is required when you depend on liballoc rather than libcore. libstd provides an implementation that aborts with the message `fatal runtime error: memory allocation failed`, matching the current behavior.

The new implementation is also significantly simpler - it's "just another weak lang item". [RFC 2070](https://github.com/rust-lang/rfcs/blob/master/text/2070-panic-implementation.md) specifies a path towards stabilizing panic_fmt, so any complexities around stable weak lang item definition are already being solved.

To bootstrap, oom silently aborts in stage0. alloc_system no longer has a bunch of code to print to stderr, and alloc_jemalloc no longer depends on alloc_system to pull in that code.

One fun note: System's GlobalAlloc implementation didn't override the default implementation of oom, so it currently aborts silently!

r? @alexcrichton
@bors
Copy link
Contributor

bors commented Apr 22, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing e028687 to master...

@bors bors merged commit 5969712 into rust-lang:master Apr 22, 2018
@@ -59,7 +59,7 @@ unsafe impl<T> Alloc for T where T: CoreAlloc {
}

fn oom(&mut self, _: AllocErr) -> ! {
CoreAlloc::oom(self)
unsafe { ::core::intrinsics::abort() }
Copy link
Member

Choose a reason for hiding this comment

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

Why doesn't this use the weak lang item?

Copy link
Member Author

Choose a reason for hiding this comment

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

This is only used for stage0 I believe.

@@ -303,7 +303,8 @@ language_item_table! {

ExchangeMallocFnLangItem, "exchange_malloc", exchange_malloc_fn;
BoxFreeFnLangItem, "box_free", box_free_fn;
DropInPlaceFnLangItem, "drop_in_place", drop_in_place_fn;
DropInPlaceFnLangItem, "drop_in_place", drop_in_place_fn;
OomLangItem, "oom", oom;
Copy link
Member

Choose a reason for hiding this comment

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

Are weak lang items not grouped in here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants