-
Notifications
You must be signed in to change notification settings - Fork 18k
runtime: failure to detect write barriers inside nowritebarrierrec / questionable write barriers #73430
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
Comments
@golang/compiler I initially thought this was not a problem because it all hangs on an unlock at the end of gcFlushBgCredit, but then realized that the caller depends on this. And also, not detected. |
cc @golang/runtime |
One thing that's a little confusing is why it looks like (Referring to:)
|
|
cc @rhysh |
1 similar comment
cc @rhysh |
I can reproduce the failure by changing
But part of the output I see is I haven't found why
|
Go version
near dev tip as of mid-April 2025, e.g. 13b7c7d
Output of
go env
in your module/workspace:What did you do?
For other reasons, I modified the inlining budget from 80 to 800, then tried to rebuild with
./make.bash
What did you see happen?
A slow, bloated build.
What did you expect to see?
(annotated to add more information so as to avoid repeated work)
I see several things going on here.
First, it indeed looks like operations that are superficially write-barrier triggering. They may not all be "real" write barriers, but they are definitely stores of pointer values into data structures.
Second, they were not detected until the inlining was turned very far up. There might be other write barriers that aren't getting detected.
Third, I think we need to fix the stack traces in the write-barrier-rec report, because inlining is missing I think, some of those I had to figure out carefully.
The text was updated successfully, but these errors were encountered: