You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using rsc/compilebench's -alloc flag, all compiles currently report "0 B/op 0 allocs/op". Presumably something in cmd/compile changed that broke this. We should either revert that change, or update rsc/compilebench accordingly.
This appears to be because runtime/pprof switched to writing binary pprof files, so compilebench's code to parse the # TotalAlloc and # Mallocs lines no longer work.
Just hit this myself. Sadness. (I wonder whether anyone else was parsing the pprof output to get memstats and will also be impacted by this change.)
I don't see an obvious way to add ignored to the binary pprof output, and I really don't want to embed a protobuf decoder in compilebench anyway.
I propose instead that we add a -memstats=<file> flag to cmd/compile. When provided, on exit, we call runtime.ReadMemStats and write the JSON-encoded results to <file>.
compilebench will have to probe whether the compiler accepts the flag. If yes, it uses it and reads the result. If no, it omits it and attempts to read the pprof output. There will be a stretch of commits in Go 1.8 and the beginning of Go 1.9 for which compilebench forever cannot emit alloc info. (Or in dire straights you can patch runtime/pprof/pprof.go's WriteHeapProfile to call writeHeap(w, 1) instead of writeHeap(w, 0).)
I assume that at some point @matloob will want to eliminate the old code, but as an interim measure, that'd be really useful. Particularly if it could go in for 1.8--it is a tiny, safe change--but I'm not going to hold my breath for that.
In general, I'd argue that changing file format should give the users at
least one release to migrate to new format, which means we should at least
release Go 1.8 to support both formats and also with the ability to switch
format at runtime (so that people using Go 1.8 compiled programs without
source code can still use tools that only works with the old format.)
I think we should address this before Go 1.8.
Activity
mdempsky commentedon Jan 12, 2017
This appears to be because runtime/pprof switched to writing binary pprof files, so compilebench's code to parse the
# TotalAlloc
and# Mallocs
lines no longer work./cc @matloob
josharian commentedon Jan 20, 2017
Just hit this myself. Sadness. (I wonder whether anyone else was parsing the pprof output to get memstats and will also be impacted by this change.)
I don't see an obvious way to add ignored to the binary pprof output, and I really don't want to embed a protobuf decoder in compilebench anyway.
I propose instead that we add a
-memstats=<file>
flag to cmd/compile. When provided, on exit, we callruntime.ReadMemStats
and write the JSON-encoded results to<file>
.compilebench
will have to probe whether the compiler accepts the flag. If yes, it uses it and reads the result. If no, it omits it and attempts to read the pprof output. There will be a stretch of commits in Go 1.8 and the beginning of Go 1.9 for whichcompilebench
forever cannot emit alloc info. (Or in dire straights you can patch runtime/pprof/pprof.go'sWriteHeapProfile
to callwriteHeap(w, 1)
instead ofwriteHeap(w, 0)
.)How does that sound?
minux commentedon Jan 20, 2017
josharian commentedon Jan 20, 2017
I assume that at some point @matloob will want to eliminate the old code, but as an interim measure, that'd be really useful. Particularly if it could go in for 1.8--it is a tiny, safe change--but I'm not going to hold my breath for that.
minux commentedon Jan 20, 2017
bradfitz commentedon Jan 20, 2017
Can you prepare a non-scary CL before Monday?
josharian commentedon Jan 20, 2017
False alarm. While preparing a CL, I accidentally read the documentation (oops). CL on its way.
josharian commentedon Jan 20, 2017
gopherbot down? CL 35484
minux commentedon Jan 20, 2017
josharian commentedon Jan 21, 2017
But those who have the problem have a one line fix available. They'd have to do the same thing with a GODEBUG envvar.