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 MemoryExtra by Memory in intptrcast methods #62003

Merged
merged 3 commits into from
Jun 21, 2019
Merged

Replace MemoryExtra by Memory in intptrcast methods #62003

merged 3 commits into from
Jun 21, 2019

Conversation

pvdrz
Copy link
Contributor

@pvdrz pvdrz commented Jun 20, 2019

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 20, 2019
@RalfJung
Copy link
Member

Can you change tag_allocation and tag_static_base_pointer in the same way, for consistency?

@RalfJung
Copy link
Member

Also, please prepare a Miri PR that fixes compiling Miri with these changes. It should not do anything else, so we can land it quickly once this one here lands.

@pvdrz
Copy link
Contributor Author

pvdrz commented Jun 20, 2019

Sure, I'll do the change in rustc and then do the respective miri PR

@oli-obk
Copy link
Contributor

oli-obk commented Jun 21, 2019

@bors r+

@bors
Copy link
Contributor

bors commented Jun 21, 2019

📌 Commit e152c38 has been approved by oli-obk

@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 21, 2019
@bors
Copy link
Contributor

bors commented Jun 21, 2019

⌛ Testing commit e152c38 with merge 56a12b2...

bors added a commit that referenced this pull request Jun 21, 2019
Replace MemoryExtra by Memory in intptrcast methods

r? @RalfJung @oli-obk
@bors
Copy link
Contributor

bors commented Jun 21, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: oli-obk
Pushing 56a12b2 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 21, 2019
@bors bors merged commit e152c38 into rust-lang:master Jun 21, 2019
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #62003!

Tested on commit 56a12b2.
Direct link to PR: #62003

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

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Jun 21, 2019
Tested on commit rust-lang/rust@56a12b2.
Direct link to PR: <rust-lang/rust#62003>

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

@rust-lang/infra no issue was created... did I screw up in #61938 ?

@RalfJung
Copy link
Member

The logs seem reasonable?

[01:41:13] Cloning into 'rust-toolstate'...
[01:41:14] The state of "miri" has changed from "test-pass" to "build-fail"
[01:41:14] [master cd8ed9f] (linux CI update)
[01:41:14]  1 file changed, 1 insertion(+)
[01:41:17] To https://github.com/rust-lang-nursery/rust-toolstate.git
[01:41:17]    17c7197..cd8ed9f  master -> master

@RalfJung
Copy link
Member

RalfJung commented Jun 21, 2019

Oh yes, I did screw up... new is used inside the loop, not outside of it. Not sure how that would have this effect though, instead of showing an error.

And with Python's scoping rules, new should be the state of the last OS it looks at, so this should actually work.

@RalfJung
Copy link
Member

Hm no, that log is created by a totally different script, at https://github.com/rust-lang/rust/blob/56a12b2ad058f22f1ef090713df15598525ba4a4/src/ci/docker/x86_64-gnu-tools/checkregression.py, called at

if python2.7 "$CHECK_NOT" "$OS" "$TOOLSTATE_FILE" "_data/latest.json" changed; then

@RalfJung
Copy link
Member

(Continuing at #62023.)

Centril added a commit to Centril/rust that referenced this pull request Jun 28, 2019
publish_toolstate: don't use 'new' from inside the loop

I think I made a mistake in rust-lang#61938 by using `new` outside the inner loop. This PR fixes that.

However, no issue got created at all for rust-lang#62003 (comment), and I don't know why that is.   The script should be [triggered by Traivs](https://github.com/rust-lang/rust/blob/56a12b2ad058f22f1ef090713df15598525ba4a4/.travis.yml#L240), and I can find no trace of that in [the build log](https://travis-ci.com/rust-lang/rust/jobs/209880042).
Centril added a commit to Centril/rust that referenced this pull request Jun 28, 2019
publish_toolstate: don't use 'new' from inside the loop

I think I made a mistake in rust-lang#61938 by using `new` outside the inner loop. This PR fixes that.

However, no issue got created at all for rust-lang#62003 (comment), and I don't know why that is.   The script should be [triggered by Traivs](https://github.com/rust-lang/rust/blob/56a12b2ad058f22f1ef090713df15598525ba4a4/.travis.yml#L240), and I can find no trace of that in [the build log](https://travis-ci.com/rust-lang/rust/jobs/209880042).
Centril added a commit to Centril/rust that referenced this pull request Jun 28, 2019
publish_toolstate: don't use 'new' from inside the loop

I think I made a mistake in rust-lang#61938 by using `new` outside the inner loop. This PR fixes that.

However, no issue got created at all for rust-lang#62003 (comment), and I don't know why that is.   The script should be [triggered by Traivs](https://github.com/rust-lang/rust/blob/56a12b2ad058f22f1ef090713df15598525ba4a4/.travis.yml#L240), and I can find no trace of that in [the build log](https://travis-ci.com/rust-lang/rust/jobs/209880042).
Centril added a commit to Centril/rust that referenced this pull request Jun 29, 2019
publish_toolstate: don't use 'new' from inside the loop

I think I made a mistake in rust-lang#61938 by using `new` outside the inner loop. This PR fixes that.

However, no issue got created at all for rust-lang#62003 (comment), and I don't know why that is.   The script should be [triggered by Traivs](https://github.com/rust-lang/rust/blob/56a12b2ad058f22f1ef090713df15598525ba4a4/.travis.yml#L240), and I can find no trace of that in [the build log](https://travis-ci.com/rust-lang/rust/jobs/209880042).
@nnethercote
Copy link
Contributor

This caused a perf regression. Is that expected? Could the regression be avoided?

@RalfJung
Copy link
Member

No that's not expected. In fact it seems really strange because the only instance of all of these methods that's used in rustc is basically doing nothing.

Maybe the default instances need to be marked inline(always)?

RalfJung added a commit to RalfJung/rust that referenced this pull request Jul 1, 2019
…-obk"

This reverts commit 56a12b2, reversing
changes made to dbec74f.
bors added a commit that referenced this pull request Jul 1, 2019
[WIP] Debug perf regression from Miri Machine trait changes

Maybe this fixes the perf regression that #62003 seemingly introduced?

Cc @nnethercote
@@ -416,11 +416,11 @@ impl<'mir, 'tcx, M: Machine<'mir, 'tcx>> Memory<'mir, 'tcx, M> {
id: AllocId,
) -> InterpResult<'tcx, &mut Allocation<M::PointerTag, M::AllocExtra>> {
let tcx = self.tcx;
let memory_extra = &self.extra;
let alloc = Self::get_static_alloc(id, tcx, &self);
Copy link
Member

Choose a reason for hiding this comment

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

Oh, I had entirely missed this! This is not what we want. This is the reason for the perf regression. We don't want to ask for a static alloc if we don't absolutely need it. You turned the vast majority of the get_mut calls from one to two HashMap lookups.

Copy link
Member

Choose a reason for hiding this comment

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

This could also explain why MIRI_BACKTRACE=1 made everything so awfully slow when I used it for debugging on CI.

Copy link
Contributor Author

@pvdrz pvdrz Jul 2, 2019

Choose a reason for hiding this comment

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

Oh I remember that change, that was because there was no way to pass self into the get_mut_or without having a mutable and an immutable reference at the same time.

Before doing the MemoryExtra -> Memory change, we passed just self.extra and get_mut_or was called from self.alloc_map so there was no borrowing issues.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, that's why I am reverting to just MemoryExtra now.

Next time you have to reorder code like that in a way that moves an operation out of a closure and makes it executed much more often than previously... please call that out when submitting the PR, so we can review that specifically. :) I should have seen this in the review, but it gets easier when you call out the "most interesting" bits.

Copy link
Contributor Author

@pvdrz pvdrz Jul 2, 2019

Choose a reason for hiding this comment

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

Yeah sorry, that was a little careless from my part. Next time will do

Edit: I assume we could modify how get_mut_or works or adding a get_mut but I don't think it is worth it

bors added a commit that referenced this pull request Jul 2, 2019
Fix perf regression from Miri Machine trait changes

Maybe this fixes the perf regression that #62003 seemingly introduced?

Cc @nnethercote
Centril added a commit to Centril/rust that referenced this pull request Jul 5, 2019
Fix perf regression from Miri Machine trait changes

Maybe this fixes the perf regression that rust-lang#62003 seemingly introduced?

Cc @nnethercote
Centril added a commit to Centril/rust that referenced this pull request Jul 6, 2019
Fix perf regression from Miri Machine trait changes

Maybe this fixes the perf regression that rust-lang#62003 seemingly introduced?

Cc @nnethercote
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.

6 participants