Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork33.3k
GH-126892: Reset warmup counters when JIT compiling code#126893
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
The warmup numbers are going to be wrong once#126816 is merged.
Do you want to get that merged first, then update this. Or the other way around?
I'll do that then this. |
Fixed the tests (I also needed to change the logic a bit since the bytecode re-specializes before we JIT a new trace). |
48c50ff intopython:mainUh oh!
There was an error while loading.Please reload this page.
| __run_using_command=[_strace_binary]+strace_flags) | ||
| __run_using_command=[_strace_binary]+strace_flags, | ||
| # Don't want to trace our JIT's own mmap and mprotect calls: | ||
| PYTHON_JIT="0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Guessing this showed up in thetest_fileio testtest_syscalls_read?
I have been keeping an eye on / working through a couple other issues where mmap(NULL) and mprotect show up, trying to figure out if just excluding those two from that test would be good/effective (memory allocation happening in reading files is fine / not what the test is focused on).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Yeah, I was wondering if this was susceptible to catching badly-timed arena allocations and such too. Might make sense to have an option to ignore themmap/munmap/mprotect family of functions instead of this ad-hoc fix.
I'm just not familiar with how this is being used, and didn't want to change the meaning/behavior of the tests too dramatically.
Uh oh!
There was an error while loading.Please reload this page.
19% fewer traces created, no change in uops executed. No performance impact.