Possibly related: #49035, though my expectation was that this only affected the high-water mark (that may also be the case here; it is more concerning if the steady-state memory is significantly higher).

Thanks for the repro, and the profiles.

One more thing, I have generally pretty generic VSCode settings, but I do have experimentalWorkspaceModule enabled.

Ok, this is interesting. Looking at your 19GB.withNames heap profile, things are not as I would have expected:

      flat  flat%   sum%        cum   cum%
    4.25GB 45.81% 45.81%     4.26GB 46.01%  golang.org/x/tools/internal/lsp/cache.expandErrors
    1.84GB 19.85% 65.66%     1.84GB 19.85%  strings.(*Builder).WriteString (inline)
    1.21GB 13.07% 78.73%     3.11GB 33.56%  golang.org/x/tools/internal/lsp/cache.typeErrorDiagnostics
    0.58GB  6.23% 84.97%     0.58GB  6.23%  go/types.(*Checker).recordTypeAndValue
    0.24GB  2.62% 87.58%     0.24GB  2.62%  go/types.(*Checker).recordUse
    0.11GB  1.21% 88.79%     0.11GB  1.21%  go/types.(*Scope).Insert
    0.10GB  1.05% 89.85%     0.10GB  1.05%  go/types.NewScope
    0.07GB  0.75% 90.60%     0.07GB  0.75%  fmt.Sprintf
    0.07GB  0.71% 91.31%     0.07GB  0.79%  go/types.(*Checker).recordSelection
    0.06GB  0.68% 91.99%     0.06GB  0.68%  go/types.(*Checker).recordDef

Half of the heap is allocated in expandErrors. I checked recent heap dumps of my own gopls, and don't see anything similar.

It seems likely that we either have a memory leak, or there were a tremendous amount of errors in memory at the high-water mark. I will try to reproduce with your repo, but any additional clues you might have would be useful.

@heschi might also find this interesting...

Few days after this behavior started and was persistent (like, even once gopls got killed, the new instance quickly degraded into the same behavior) it stopped. I do not know why. Maybe it is connected with the state of the editors and code in the editors at that particular moment, so after I continued working (or, tried to work, given instability) and closed tabs and stuff, it seems it is gone. So sadly I cannot provide more input into this.

Maybe it is connected with the fact that I had VScode running first with old go version and then I upgraded go while VScode and all tabs were left open. Maybe this confused it?

Thanks for the follow-up. I suppose it's theoretically possible that upgrading the Go command led to an explosion in errors, due to some sort of go list thrashing?

Unfortunately tracking this down is probably not worthwhile, but we should perhaps reinitialize gopls if ever we detect that the Go binary has changed.

Sounds good.

Is reinitializing gopls sufficient, or shouldn't it be cleaner and safer for the user or the editor (vscode) to rebuild the gopls and restart the session with the updated Go?

This is unfortunately a relatively low priority, so moving it to unplanned while we focus on 1.18 support.