mknyszek
Repos
22
Followers
145
Following
1

A bytecode interpreter for a prototype quantum scripting language

3
0

The Go programming language

106140
14942

Go allocation trace utilities

11
1

Simulation of various Go GC pacer models

9
0

Events

issue comment
proposal: arena: new package providing memory arenas

any info for use package arena build Windows kernel driver´╝č set main as driverentry etc.

I don't think Go has any specific support for running as a Windows kernel driver (though I may be misunderstanding what you mean). I'm not certain how arenas helps you with that.

Created at 3 days ago
issue comment
proposal: arena: new package providing memory arenas

will arena support alloc reflect.Value and interface? we want to support alloc object in arena for protobuf/json/bson etc, which most memory footprint is reflect.Value and interface?

@LeGamerDc The arena API that landed in Go 1.20 (behind GOEXPERIMENT=arenas) allow you to do this via an interface in the reflect package.

Created at 3 days ago
issue comment
proposal: arena: new package providing memory arenas

Why does the performance of using arena under windows seem to be worse?

Please file a new issue with details and how to reproduce the behavior.

Created at 3 days ago
issue comment
runtime: `lock ordering problem` between `trace` and `wbufSpans`

I still plan to look into this.

Created at 4 days ago
issue comment
runtime: TestCgoPprofCallback hang on linux-arm

That one failure on linux/arm has been the only one since. Aside from a stream of persistent failures on longtest builders (that seem to be fixed), these are the latest 3:

2022-11-09T22:56:44-89332e0/openbsd-amd64-68 2022-11-01T14:20:31-ad5d2f6/linux-amd64-longtest 2022-11-01T14:11:54-2730170/openbsd-386-70

Created at 4 days ago
issue comment
runtime/pprof: NewCPUProfile + cpuProfile.Start to allow profile configuration

Since we're in the freeze and this is work for a new API, I don't think anything is going to happen here. I'm moving this into Go 1.21. This has been sitting here for quite a long time, and at this point I think we just need someone to implement it. Marking as help wanted.

Created at 4 days ago
issue comment
runtime, syscall: we require pipe2 but Solaris before 11.4 reportedly does not have it

If we don't have any maintainers for the Solaris port, that's not great. The port is not currently broken, but by the new port policy (#53383) if it gets into a broken state and nobody fixes it, it may end up getting removed.

Perhaps we should post on golang-dev looking for an owner. @rorth, @binarycrusader, @jclulow if you know anyone that might be interested please reach out to them if you have time.

For this particular issue, I think if we are supporting Solaris 11.3 indirectly through gccgo (and libruntime/libgo) then:

  1. We should state that explicitly.
  2. We need someone to remove reliance on pipe2 (presumably whoever the new owner is, or a volunteer).

Marking as help wanted.

Created at 4 days ago
issue comment
runtime: TestNeedmDeadlock failures

This continues to be the only failure in recent memory. At the end of the cycle we should put this into the backlog if we don't see any more issues.

Created at 4 days ago
issue comment
runtime: TestNetpollDeadlock failures

Checking manually, the latest instance of this is

2022-11-01T20:46:55-50c5919/solaris-amd64-oraclerel

Created at 4 days ago
issue comment
runtime/pprof: TestLabelSystemstack due to sample with no location

Putting this back in the triage queue.

Created at 4 days ago
issue comment
runtime/pprof: TestLabelSystemstack due to sample with no location

Actually, there seems to have been 2 additional failures since then:

2022-11-17T20:52:28-6e0e492/darwin-amd64-11-aws 2022-09-26T23:54:36-17f83e3/netbsd-arm64-bsiegert

Created at 4 days ago
issue comment
runtime/pprof: TestLabelSystemstack due to sample with no location

watchflakes hasn't updated this bug since Oct 4th. I think we should fix this but since it was introduced in the last release I don't think this is a release blocker (and I don't think it's failing frequently enough to be causing significant harm).

It's prioritized as P1 for triage which sounds right to me. I'll set up a dashboard so we don't miss flakes like this and get around to them soon. I'm going over the other "unassigned" issues now, so they'll take priority if they look more strongly like release blockers.

Created at 4 days ago
issue comment
runtime/trace: execution trace doesn't include pprof labels

Thanks. I think this is addition makes sense. How should these labels be surfaced in the current UI?

Created at 5 days ago
issue comment
proposal: runtime/metrics: add live_objects metrics

I updated the CL to use gcController.heapMarked, but found one odd thing.

It's an accounting artifact currently required for good performance. It would be nice to fix, but I'm not yet sure how without either (1) impacting the allocation fast path or (2) slowing down metrics.Read to ReadMemStats levels (this path would avoid the global latency impact that ReadMemStats has because it's not necessary to actually, fully stop the world, but the worst-case latency of metrics.Read becomes effectively the same as stopping the world).

For users that really need this consistency (like the testing package), ReadMemStats provides it, so there is a workaround. Most of the time though, the skew doesn't make a very meaningful difference, and the memory stats (in /memory/classes) are all at least guaranteed to be consistent with each other. It might be worth mentioning in the docs that this stat specifically isn't necessarily consistent with the /memory/classes stats. We can lift this restriction in the future if we can figure out a way to flush cached efficiently (I'll keep thinking about it).

If we do this, we should probably also export scannable stack bytes and scannable globals bytes, at least as far as they go into the GOGC calculation. We should also really export GOGC and the memory limit as well, since they can change during application execution.

I can prepare CLs for those as well. Should I submit them separately?

Either or. Your current CL is not very big.

Created at 6 days ago
issue comment
sync/atomic: atomic.Pointer[T] can be misused with type conversions.

Sent https://go.dev/cl/452438.

Created at 6 days ago
issue comment
proposal: runtime/metrics: add live_objects metrics

I created a very hacky prototype of this here, but there is probably a much better way to do this.

Yeah, there's a simpler way for bytes. :) You want gcController.heapMarked. You can just read that directly in the metrics callback without any synchronization since it only gets updated during a STW.

Created at 1 week ago
issue comment
proposal: runtime/metrics: add live_objects metrics

A similar proposal was rejected previously (#51966). Part of the problem was inclusion in MemStats, but runtime/metrics also existed and I made some other arguments against it. Mainly, I think relying on it solely as an indicator can be somewhat fragile if you put it in context of the Go 1.18 GOGC changes. I wasn't ever fundamentally opposed to this, but at the time for the use-case presented, it just didn't seem worth it. I also wanted to think more carefully about what implications it could have (and why we didn't do it already).

However, I do think your argument that it's useful for identifying issues with a memory limit is "new information" (now that the memory limit has landed) as far as the proposal processes goes. I think that might be enough to push this over the edge into more serious consideration for me personally.

I think to start with I'd be inclined at this point to call this /gc/heap/live:bytes. This way it lives next to /gc/heap/goal:bytes. /memory/classes to me is more about a breakdown of memory at a higher level and all the metrics inside there are supposed to be orthogonal. We'd have to break up some of the other metrics and I don't think it's worth it for this.

If we do this, we should probably also export scannable stack bytes and scannable globals bytes, at least as far as they go into the GOGC calculation. We should also really export GOGC and the memory limit as well, since they can change during application execution.

I don't really see enough utility from exporting the count of live objects though. I think a memory profile is better for that sort of thing anyway. (Also, we don't currently track that (mod memory profiling) and it's more work.)

Created at 1 week ago
issue comment
x/build/cmd/gomote: CLI UI improvements tracking issue

The main changes landed. (There could be a bit more refactoring and cleanup, but it seems OK for now.) Closing this issue.

Created at 1 week ago
closed issue
x/build/cmd/gomote: CLI UI improvements tracking issue

Goal: fix up the gomote UI by tackling the following GitHub issues,

  • https://github.com/golang/go/issues/32430 gomote takes several commands for very common setup
  • https://github.com/golang/go/issues/29037 gomote commands are too long (kind of, this issue is more about the SSH environment, but the common steps of "push, make.bash" are so common they should probably have a shortcut)
  • https://github.com/golang/go/issues/53273 puttar is confusing

and directly add support for the common use-case of stress testing across several gomotes, a la

  • https://github.com/mknyszek/goswarm

Proposed list of changes to the frontend:

  • [x] Add stateful gomote "groups" that can be used to both shorten gomote commands and manipulate several gomotes at once
    • [x] State will be stored in os.UserConfigDir + "/gomote/groups"
    • [x] Existing commands can either apply to individual gomote instances or groups via the -group flag or GOMOTE_GROUP
    • [x] Add the -count flag to the "create" subcommand for creating multiple gomotes
    • [x] Add the -setup flag to the "create" subcommand for automatically pushing and running ./make.ba{sh|t}
    • [x] Add the -until= flag to the "run" subcommand
    • [x] Add the -collect flag to automatically "gettar" after a "run."
    • [x] Make "gettar" no longer write to stdout by default.
    • [x] Make "puttar" have a nicer argument structure.

The example below demonstrates the new functionality. Following examples build on each other.

$ GOROOT=/path/to/goroot gomote group start my-group
Started gomote group my-group
$ gomote group list
Name          Instances       GOROOT
my-group    (none)
$ gomote -group=my-group create -count=2 -setup linux-amd64
Creating linux-amd64 gomote (1)...
Creating linux-amd64 gomote (2)...
Pushing GOROOT to user-mknyszek-linux-amd64-0...
Pushing GOROOT to user-mknyszek-linux-amd64-1...
Running ./make.bash on user-mknyszek-linux-amd64-0...
Running ./make.bash on user-mknyszek-linux-amd64-1...
$ export GOMOTE_SESSION=my-group
$ gomote create -count=1 -setup windows-amd64
Creating windows-amd64 gomote (1)...
Pushing GOROOT to user-mknyszek-windows-amd64-0...
Running ./make.bat on user-mknyszek-windows-amd64-0...
$ gomote group list
Name          Instances                        GOROOT
my-group    user-mknyszek-linux-amd64-0      /path/to/goroot
              user-mknyszek-linux-amd64-1
              user-mknyszek-windows-amd64-0
$ gomote run go/bin/go test -run="FlakyTest" -count=1000 runtime
PASS
$ gomote run -until-failure='unexpected return pc' go/bin/go test -run="FlakyTest" -count=1000 runtime
runtime: unexpected return pc
...
FAIL
  • [ ] Factor out high-level gomote instance manipulation into a library.
Created at 1 week ago
closed issue
wiki: document gomote for first time users

Thanks for this. If there's one thing that could make the wiki significantly clearer it would be a paragraph about directory structure and the "gomote machine model". It took me a bunch of try-and-error runs to find out. Much of it may be "obvious" in retrospect, but it helps spelling it out right away, especially for first-time gomote users. This would provide newcomers a clearer model of how the gomote looks like from a client's perspective.

Some of the things that would be nice if they were spelled out:

  • each instance of a gomote has its own working directory, accessible via $WORKDIR
  • gomote push does essentially an rsync of the $GOROOT directory into the remote $WORKDIR; i.e., after a gomote push, the local $GOROOT appears as go directory on the gomote (I had to find this out by doing repeated gomote ls commands)
  • when issuing gomote run commands, one needs to specify the full path for commands and files, e.g. go/bin/go tool compile go/src/mypkg/x.go - there appears no notion of a cwd, or perhaps I missed it
  • to change individual uploaded files, make the changes locally and use gomote push $MOTE and it will only upload the changes (this was not obvious to me at first, especially because there's also a gomote put command to push single files. I thought I was supposed to use that one for smaller changes)
  • I didn't figure out to how to use gomote put to get a file into a specific directory on the gomote instance (I still don't know how to do it, but I resorted to just using gomote push all the time.)
  • explain that the gomote self-destructs after 30min of non-use
  • I'm unclear on the -system flag

Originally posted by @griesemer in https://github.com/golang/go/issues/31091#issuecomment-477718369

Created at 1 week ago
issue comment
wiki: document gomote for first time users

I updated the wiki and I think I hit your main points: https://github.com/golang/go/wiki/Gomote.

Closing for now. Feel free to reopen.

Created at 1 week ago
issue comment
runtime: heap size reached GOMEMLIMIT but no GC activity triggered

Oh, haha. It happens. :) Well, thanks for checking and for trying to reproduce!

Created at 1 week ago
issue comment
runtime: heap size reached GOMEMLIMIT but no GC activity triggered

ps: Now I have a guess, the GC is triggered by the goal calculated by GOMEMLIMIT, but it is not complete. During the mark phase, the new allocated object are marked reachable, so the RSS increases. And this occasion is under a http benchmark, the pressure is high, Rss increases too high, finally it's killed. It's a guess, I will test it later :)

Sorry, I'm not sure I follow. If your application allocates around 6.3 GiB in 2 minutes (as per your original post), then that's an allocation rate of about 53 MiB/s. If you have a 1 GiB ballast and your total live heap stays around 2 GiB, that suggests to me that your live heap is small, on the order of MiB. The GC should have no problem keeping up in this scenario I would expect the mark phase to be really short. (Even then, newly allocated memory marked live during a mark phase will become eligible for reclamation next cycle provided it's not referenced by the next mark phase.)

If the application is actually getting to a mark phase, the GC is programmed to become more aggressive as the goal is neared and begins to be exceeded. It'll force the allocating goroutines to assist until it can finish.

I think a reproducer at this point would be the most useful thing.

Created at 1 week ago