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

Change vtable memory representation to use tcx allocated allocations. #86475

Merged
merged 3 commits into from
Jun 29, 2021

Conversation

crlf0710
Copy link
Member

This fixes #86324. However i suspect there's more to change before it can land.

r? @bjorn3
cc @rust-lang/miri

@rust-highfive
Copy link
Collaborator

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 19, 2021
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@RalfJung
Copy link
Member

RalfJung commented Jun 20, 2021

I am very confused by the PR title. Surely Miri should still use its own allocations for stack and heap allocations. Also the change seems to have a lot to do with vtables, but that term does not appear in the PR title. It would help to describe more precisely what is going on. :)

EDIT: Oh, looks like what you mean use "Change Miri to use txc-allocation allocation for vtables". That makes a lot more sense. You had me worried at first here. ;)
That's not the whole change though, is it? It also removes vtable generation from other parts of the compiler.

@bjorn3
Copy link
Member

bjorn3 commented Jun 20, 2021

If you don't know yet ./x.py check should check cg_clif by default unlike ./x.py build. You can make ./x.py build also build cg_clif by adding "cranelift" to the rust.codegen-backends array in config.toml.

@crlf0710 crlf0710 changed the title Change miri to use tcx allocated allocations. Change vtable memory representation to use tcx allocated allocations. Jun 20, 2021
@crlf0710
Copy link
Member Author

Thank you for your comments! I'll update the pr and address the review comments tomorrow evening in my timezone (after about 18 hours)

@oli-obk
Copy link
Contributor

oli-obk commented Jun 21, 2021

Thank you for your comments! I'll update the pr and address the review comments tomorrow evening in my timezone (after about 18 hours)

No rush. Take all the time you need. There's no expectation that reviews are addressed in any timeframe other than what the author feels good with.

@crlf0710
Copy link
Member Author

Thanks! I was a little busy this week, i'll get to it this weekend.

@crlf0710 crlf0710 force-pushed the miri_vtable_refactor branch 2 times, most recently from 10b692c to c1eafa7 Compare June 27, 2021 11:38
@crlf0710
Copy link
Member Author

Updated and addressed the comments.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@bjorn3
Copy link
Member

bjorn3 commented Jun 28, 2021

Only x86_64-apple timed out. All other jobs succeeded. Probably spurious.

@bors retry

@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 Jun 28, 2021
@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@bors
Copy link
Contributor

bors commented Jun 29, 2021

⌛ Testing commit 97772bb with merge 12d658d005db54ae0594fa815a70d2ab79747b70...

@bors
Copy link
Contributor

bors commented Jun 29, 2021

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 29, 2021
@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@crlf0710
Copy link
Member Author

2021-06-29T10:40:18.9223083Z curl: (56) OpenSSL SSL_read: Connection was reset, errno 10054
2021-06-29T10:40:18.9316146Z ##[error]Process completed with exit code 56.

Mmm, it seems another retry is needed? Or do i need to rebase forward? @bjorn3

@bjorn3
Copy link
Member

bjorn3 commented Jun 29, 2021

@bors retry

@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 Jun 29, 2021
@bors
Copy link
Contributor

bors commented Jun 29, 2021

⌛ Testing commit 97772bb with merge e98897e...

@bors
Copy link
Contributor

bors commented Jun 29, 2021

☀️ Test successful - checks-actions
Approved by: bjorn3
Pushing e98897e to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 29, 2021
@bors bors merged commit e98897e into rust-lang:master Jun 29, 2021
@rustbot rustbot added this to the 1.55.0 milestone Jun 29, 2021
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #86475!

Tested on commit e98897e.
Direct link to PR: #86475

💔 miri on windows: test-pass → build-fail (cc @eddyb @oli-obk @RalfJung).
💔 miri on linux: test-pass → build-fail (cc @eddyb @oli-obk @RalfJung).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Jun 29, 2021
Tested on commit rust-lang/rust@e98897e.
Direct link to PR: <rust-lang/rust#86475>

💔 miri on windows: test-pass → build-fail (cc @eddyb @oli-obk @RalfJung).
💔 miri on linux: test-pass → build-fail (cc @eddyb @oli-obk @RalfJung).
@bjorn3
Copy link
Member

bjorn3 commented Jun 29, 2021

Third time's the charm.

@crlf0710 crlf0710 deleted the miri_vtable_refactor branch June 30, 2021 04:03
bjorn3 pushed a commit to bjorn3/rust that referenced this pull request Jul 7, 2021
Change vtable memory representation to use tcx allocated allocations.

This fixes rust-lang#86324. However i suspect there's more to change before it can land.

r? `@bjorn3`
cc `@rust-lang/miri`
Comment on lines +1048 to +1050

pub(super) vtables_cache:
Lock<FxHashMap<(Ty<'tcx>, Option<ty::PolyExistentialTraitRef<'tcx>>), AllocId>>,
Copy link
Member

Choose a reason for hiding this comment

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

Hmm, any reason this is a mutable cache in the global context, instead of a query? It looks like the kind of thing we replaced with queries long ago.

(Maybe we should find a way to ban !Freeze types in GlobalCtxt, outside of incremental/query state?)

cc @oli-obk @wesleywiser

Copy link
Member Author

Choose a reason for hiding this comment

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

I actually gave it a try as a query locally, but without succeed. The compilation complained about keys becoming bigger, something like that, i can't remember the exact error content.

Copy link
Member

Choose a reason for hiding this comment

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

Ah, that's because that key type is a bit too "spread out". Sadly you can't just use TraitRef<'tcx>, without passing some dummy trait for the DefId.

You could "just" update the expected size, but someone would need to check off on that (and I don't know who) - the problem there is it can affect performance even if the new query is completely unused.

Copy link
Member

Choose a reason for hiding this comment

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

Having a cache without any dependency tracking looks like a bug to me.

@@ -26,6 +26,8 @@ pub trait ConstMethods<'tcx>: BackendTypes {
fn const_to_opt_uint(&self, v: Self::Value) -> Option<u64>;
fn const_to_opt_u128(&self, v: Self::Value, sign_ext: bool) -> Option<u128>;

fn const_data_from_alloc(&self, alloc: &Allocation) -> Self::Value;
Copy link
Member

Choose a reason for hiding this comment

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

This is just from_const_alloc, isn't it? Just with a hardcoded offset of 0 and no type.

Copy link
Member

Choose a reason for hiding this comment

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

from_const_alloc also returns a PlaceRef while this returns a raw pointer value.

Copy link
Member

Choose a reason for hiding this comment

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

Right, but the PlaceRef is made from that pointer value and the type/layout passed in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.

Refactor: have miri create an Allocation for the vtable
10 participants