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.

Sign up for GitHub

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

Jump to bottom

~fn should not use the exchange allocation header #7496

Closed
thestinger opened this issue Jun 30, 2013 · 1 comment
Closed

~fn should not use the exchange allocation header #7496

thestinger opened this issue Jun 30, 2013 · 1 comment
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@thestinger
Copy link
Contributor

It dynamically stores a tydesc in the header, to handle the captured variables. This is blocking the removal of the headers from exchange allocations.

The simplest solution is to switch it to another transitional allocator acting like the old exchange allocator until it gets redesigned.
@thestinger thestinger mentioned this issue Jun 30, 2013
Merged
bors added a commit that referenced this issue Jun 30, 2013
@bors
auto merge of #7495 : thestinger/rust/exchange, r=cmr
040ac2a 
With these changes, exchange allocator headers are never initialized, read or written to. Removing the header will now just involve updating the code in trans using an offset to only do it if the type contained is managed.

The only thing blocking removing the initialization of the last field in the header was ~fn since it uses it to store the dynamic size/types due to captures. I temporarily switched it to a `closure_exchange_alloc` lang item (it uses the same `exchange_free`) and #7496 is filed about removing that.

Since the `exchange_free` call is now inlined all over the codebase, I don't think we should have an assert for null. It doesn't currently ever happen, but it would be fine if we started generating code that did do it. The `exchange_free` function also had a comment declaring that it must not fail, but a regular assert would cause a failure. I also removed the atomic counter because valgrind can already find these leaks, and we have valgrind bots now.

Note that exchange free does not currently print an error an out-of-memory when it aborts, because our `io` code may allocate. We could probably get away with a `#[rust_stack]` call to a `stdio` function but it would be better to make a write system call.
@thestinger thestinger mentioned this issue Jul 8, 2013
Closed
@thestinger
Copy link
Contributor Author

Replaced with #7861.

flip1995 pushed a commit to flip1995/rust that referenced this issue Aug 12, 2021
@bors
Auto merge of rust-lang#7522 - dswij:map-flatten-result, r=llogiq
4e760b6 
Cover `Result` on `map_flatten` lint

Closes rust-lang#7496

changelog: `[map_flatten]` handles `Result` type
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@thestinger