summaryrefslogtreecommitdiff
path: root/src/cmd/trace/trace_test.go
Commit message (Collapse)AuthorAgeFilesLines
* all: go fix -fix=buildtag std cmd (except for bootstrap deps, vendor)Russ Cox2021-10-281-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | When these packages are released as part of Go 1.18, Go 1.16 will no longer be supported, so we can remove the +build tags in these files. Ran go fix -fix=buildtag std cmd and then reverted the bootstrapDirs as defined in src/cmd/dist/buildtool.go, which need to continue to build with Go 1.4 for now. Also reverted src/vendor and src/cmd/vendor, which will need to be updated in their own repos first. Manual changes in runtime/pprof/mprof_test.go to adjust line numbers. For #41184. Change-Id: Ic0f93f7091295b6abc76ed5cd6e6746e1280861e Reviewed-on: https://go-review.googlesource.com/c/go/+/344955 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
* all: go fmt std cmd (but revert vendor)Russ Cox2021-02-201-0/+1
| | | | | | | | | | | | | | | | Make all our package sources use Go 1.17 gofmt format (adding //go:build lines). Part of //go:build change (#41184). See https://golang.org/design/draft-gobuild Change-Id: Ia0534360e4957e58cd9a18429c39d0e32a6addb4 Reviewed-on: https://go-review.googlesource.com/c/go/+/294430 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* all: update references to symbols moved from io/ioutil to ioRuss Cox2020-10-201-5/+5
| | | | | | | | | | | | | | | | | | | The old ioutil references are still valid, but update our code to reflect best practices and get used to the new locations. Code compiled with the bootstrap toolchain (cmd/asm, cmd/dist, cmd/compile, debug/elf) must remain Go 1.4-compatible and is excluded. Also excluded vendored code. For #41190. Change-Id: I6d86f2bf7bc37a9d904b6cee3fe0c7af6d94d5b1 Reviewed-on: https://go-review.googlesource.com/c/go/+/263142 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
* cmd/trace: move viewer data structs into cmd/internal/traceviewerMichael Matloob2020-08-121-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | The ViewerEvent, ViewerData and ViewerFrame structs are moved into cmd/internal/traceviewer, and renamed Event, Data, and Frame. The structs are the same, except for the following: A definition for the JSON "bp" field that's defined in the trace format, but missing in the structs has been added. Also, the Tid and Pid fields on Event have been renamed TID and PID to better match Go style. Finally, the footer field on ViewerData, which hasn't been used for a while, has been removed. This CL is in preparation for the usage of these structs by cmd/go's tracing functionality. Updates #38714 Change-Id: I345f23617b96d4629b876ae717f89d56a67e05a3 Reviewed-on: https://go-review.googlesource.com/c/go/+/239098 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
* runtime: emit trace event in direct semaphore handoffRhys Hiltner2020-01-021-0/+33
| | | | | | | | | | | | | | | | | | | | | | When a goroutine yields the remainder of its time to another goroutine during direct semaphore handoff (as in an Unlock of a sync.Mutex in starvation mode), it needs to signal that change to the execution tracer. The discussion in CL 200577 didn't reach consensus on how best to describe that, but pointed out that "traceEvGoSched / goroutine calls Gosched" could be confusing. Emit a "traceEvGoPreempt / goroutine is preempted" event in this case, to allow the execution tracer to find a consistent event ordering without being both specific and inaccurate about why the active goroutine has changed. Fixes #36186 Change-Id: Ic4ade19325126db2599aff6aba7cba028bb0bee9 Reviewed-on: https://go-review.googlesource.com/c/go/+/211797 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
* cmd/trace: revert internal/traceparserHana Kim2018-11-221-24/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | The performance improvement is not as big as we hoped. Until the API is feature complete, we postpone the release and avoid added complexity. This change was prepared by reverting all the changes affected src/cmd/trace and src/internal/traceparser packages after golang.org/cl/137635, and then bringing back MMU computation APIs (originally in src/internal/traceparser) to the src/internal/trace package. Revert "cmd/trace: use new traceparser to parse the raw trace files" This reverts https://golang.org/cl/145457 (commit 08816cb8d7ed16b9c804587ff02c1ad1c3af6cd5). Revert "internal/traceparser: provide parser that uses less space and parses segments of runtime trace files" This reverts https://golang.org/cl/137635 (commit daaf361f74c3665bcb364356c5a9dd9f536c78c3). Change-Id: Ic2a068a7dbaf4053cd9674ca7bde9c58e74385b4 Reviewed-on: https://go-review.googlesource.com/c/150517 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
* cmd/trace: use new traceparser to parse the raw trace filesPeter Weinberger2018-10-301-22/+24
| | | | | | | | Change-Id: I8b224ae48a2f8acd5a64c9ff283e97821479a9a8 Reviewed-on: https://go-review.googlesource.com/c/145457 Run-TryBot: Peter Weinberger <pjw@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
* runtime, sycall/js: add support for callbacks from JavaScriptRichard Musiol2018-06-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This commit adds support for JavaScript callbacks back into WebAssembly. This is experimental API, just like the rest of the syscall/js package. The time package now also uses this mechanism to properly support timers without resorting to a busy loop. JavaScript code can call into the same entry point multiple times. The new RUN register is used to keep track of the program's run state. Possible values are: starting, running, paused and exited. If no goroutine is ready any more, the scheduler can put the program into the "paused" state and the WebAssembly code will stop running. When a callback occurs, the JavaScript code puts the callback data into a queue and then calls into WebAssembly to allow the Go code to continue running. Updates #18892 Updates #25506 Change-Id: Ib8701cfa0536d10d69bd541c85b0e2a754eb54fb Reviewed-on: https://go-review.googlesource.com/114197 Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* cmd/trace: distinguish task endTimestamp and lastTimestampHana Kim2018-04-241-0/+59
| | | | | | | | | | | | | | | | | | | A task may have other user annotation events after the task ends. So far, task.lastTimestamp returned the task end event if the event available. This change introduces task.endTimestamp for that and makes task.lastTimestamp returns the "last" seen event's timestamp if the task is ended. If the task is not ended, both returns the last timestamp of the entire trace assuming the task is still active. This fixes the task-oriented trace view mode not to drop user annotation instances when they appear outside a task's lifespan. Adds a test. Change-Id: Iba1062914f224edd521b9ee55c6cd5e180e55359 Reviewed-on: https://go-review.googlesource.com/109175 Reviewed-by: Heschi Kreinick <heschi@google.com>
* cmd/trace: generate jsontrace data in a streaming fashionHana Kim2018-03-071-13/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update #21870 The Sys went down to 4.25G from 6.2G. $ DEBUG_MEMORY_USAGE=1 go tool trace trace.out 2018/03/07 08:49:01 Parsing trace... after parsing trace Alloc: 3385757184 Bytes Sys: 3661195896 Bytes HeapReleased: 0 Bytes HeapSys: 3488841728 Bytes HeapInUse: 3426516992 Bytes HeapAlloc: 3385757184 Bytes Enter to continue... 2018/03/07 08:49:18 Splitting trace... after spliting trace Alloc: 2352071904 Bytes Sys: 4243825464 Bytes HeapReleased: 0 Bytes HeapSys: 4025712640 Bytes HeapInUse: 2377703424 Bytes HeapAlloc: 2352071904 Bytes Enter to continue... after httpJsonTrace Alloc: 3228697832 Bytes Sys: 4250379064 Bytes HeapReleased: 0 Bytes HeapSys: 4025647104 Bytes HeapInUse: 3260014592 Bytes HeapAlloc: 3228697832 Bytes Change-Id: I546f26bdbc68b1e58f1af1235a0e299dc0ff115e Reviewed-on: https://go-review.googlesource.com/92375 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> Reviewed-by: Peter Weinberger <pjw@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* cmd/trace: init goroutine info entries with GoCreate eventHana Kim2017-12-201-29/+56
| | | | | | | | | | | | | | | | | | | | golang.org/cl/81315 attempted to distinguish system goroutines by examining the function name in the goroutine stack. It assumes that the information would be available when GoSysBlock or GoInSyscall events are processed, but it turned out the stack information is set too late (when the goroutine gets a chance to run). This change initializes the goroutine information entry when processing GoCreate event which should be one of the very first events for the every goroutine in trace. Fixes #22574 Change-Id: I1ed37087ce2e78ed27c9b419b7d942eb4140cc69 Reviewed-on: https://go-review.googlesource.com/83595 Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* cmd/trace: Record mark assists in execution tracesHeschi Kreinick2017-02-101-0/+41
| | | | | | | | | | | | | | | | | | | | During the mark phase of garbage collection, goroutines that allocate may be recruited to assist. This change creates trace events for mark assists and displays them similarly to sweep assists in the trace viewer. Mark assists are different than sweeps in that they can be preempted, so displaying them in the trace viewer is a little tricky -- we may need to synthesize multiple slices for one mark assist. This could have been done in the parser instead, but I thought it might be preferable to keep the parser as true to the event stream as possible. Change-Id: I381dcb1027a187a354b1858537851fa68a620ea7 Reviewed-on: https://go-review.googlesource.com/36015 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
* cmd/trace: fix goroutine viewAustin Clements2016-11-181-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | Currently, trace processing interleaves state/statistics updates and emitting trace viewer objects. As a result, if events are being filtered, either by time or by goroutines, we'll miss those state/statistics updates. At best, this leads to bad statistics; however, since we're now strictly checking G state transitions, it usually leads to a failure to process the trace if there is any filtering. Fix this by separating state updates from emitting trace object. State updates are done before filtering, so we always have correct state information and statistics. Trace objects are only emitted if we pass the filter. To determine when we need to emit trace counters, rather than duplicating the knowledge of which events might modify statistics, we keep track of the previously emitted counters and emit a trace counter object whenever these have changed. Fixes #17719. Change-Id: Ic66e3ddaef60d1acaaf2ff4c62baa5352799cf99 Reviewed-on: https://go-review.googlesource.com/32810 Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
* cmd/trace: fix a runnable goroutine count bugHyang-Ah (Hana) Kim2016-10-111-0/+62
When starting tracing, EvGoCreate events are added for existing goroutines that may have been blocking in syscall. EvGoCreate increments the runnable goroutine count. This change makes the following EvGoInSyscall event decrement the runnable goroutine count because we now know that goroutine is in syscall, and not runnable. Made generateTrace return an error, at any given time, the number of runnable/running/insyscall goroutines becomes non-negative. Added a basic test that checks the number of runnable/running goroutines don't include the goroutines in syscall - the test failed before this change. Change-Id: Ib732c382e7bd17158a437576f9d589ab89097ce6 Reviewed-on: https://go-review.googlesource.com/25552 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>