Google's Go compiler and runtime team meets periodically (roughly weekly) to discuss ongoing development of the compiler and runtime. While not open to the public, there's been desire by the community to learn what the compiler and runtime team is working on. While we learn what is a good format, and what works and doesn't, we will start publishing meeting minutes here.

These compiler and runtime meeting minutes are under development. We welcome feedback on content, format, level of detail, timeliness, and so on. If the minutes are helpful, please let us know. If they are less than helpful, we welcome constructive comments on how to improve them.

Notes on agenda items that address Google specific needs are elided.

This meta-issue records minutes of Google's Go compiler and runtime meetings as issue comments, so that they can be cross-linked easily with the relevant issues. This meta-issue is for minutes only; comments that are not meeting minutes will be deleted.

Comment From: jeremyfaller

2021-01-19

These compiler and runtime meeting minutes are under development. We welcome feedback on content, format, level of detail, timeliness, and so on. If the minutes are helpful, please let us know. If they are less than helpful, we welcome constructive comments on how to improve them.

Notes on agenda items that address Google specific needs are elided.

• We continued a discussion about increasing the bootstrap version of Go from 1.4 to 1.16 after the 1.17 release. We wanted to make sure it wasn't hard for people to build from scratch, but we would like to use features that have been added over time. Consensus was that this would be okay to submit as a formal proposal.
• We discussed Austin's benchmark unit proposal. Consensus was hopeful that it would be accepted.
• We discussed the weak maps proposal. A number of corner cases, gotchas, and subtleties were discussed. Consensus was that the discussion on the issue was up to date.
• After falling off the prior week's agenda, we began a discussion about releasing the compiler and runtime meeting notes. We all felt communication with the community was important, and we would start with an internal publication of meeting notes. No dates were set for a final decision.

Comment From: jeremyfaller

2021-01-26

These compiler and runtime meeting minutes are under development. We welcome feedback on content, format, level of detail, timeliness, and so on. If the minutes are helpful, please let us know. If they are less than helpful, we welcome constructive comments on how to improve them.

Notes on agenda items that address Google specific needs are elided.

• We continued discussing whether or not there were any concerns with publishing compiler and runtime meeting notes. No issues were raised, so it's likely I will go ahead and start publishing the notes.
• We discussed the redirecting crash output proposal. No major concerns were raised, but consensus was that a call would be best approach (against environment variables, etc).
• We discussed the pain merging the development branches (master -> dev.regabi -> dev.typeparams). The consensus was that without acceptance of the generics proposal, we need to keep living with the pain.
• We briefly discussed using the type checker in dev.typeparams as the default type checker. Using that type checker is blocked on either acceptance of generics proposal or a separate proposal to move to a new type checker.

Comment From: jeremyfaller

2021-02-02 These compiler and runtime meeting minutes are under development. We welcome feedback on content, format, level of detail, timeliness, and so on. If the minutes are helpful, please let us know. If they are less than helpful, we welcome constructive comments on how to improve them.

Notes on agenda items that address Google specific needs are elided.

• We continued our discussion of moving to the new default typechecker on dev.typeparams. Engineering effort continues at a break-neck pace, and we're hopeful we'll be able to have this early.
• We discussed the issue with spinning M's, and have seen large improvements for unique workloads within Google. Consensus was that this was an excellent find.
• We had a brief discussion of integer constant resolution.
• We briefly discussed merging the dev.regabi branch back to master when the tree opens. Consensus was that it would be safe to merge when the tree opened.
• We discussed some recent additions to dev.typeparams, that added support for generic functions and types. It's possible the backend work will happen on the branch's compiler soon.

Comment From: jeremyfaller

2021-02-08

These compiler and runtime meeting minutes are under development. We welcome feedback on content, format, level of detail, timeliness, and so on. If the minutes are helpful, please let us know. If they are less than helpful, we welcome constructive comments on how to improve them.

Notes on agenda items that address Google specific needs are elided.

• We briefly discussed the status of 1.16.
• We discussed the tree reopening, and landing of the dev.regabi branch, and the dev.typeparms branches on master. Current plans are to merge dev.regabi during the first week. If both proposals (1, 2) are accepted, dev.typeparams will also be merged during that week.
• We discussed the new pacer proposal, and its benefits.
• We also discussed the status of the register abi. While functionality is gated behind a flag, we don't want to go into code-freeze, enabling the ABI that late. We discussed the amount of soak time we think we will need.

Comment From: jeremyfaller

2021-02-16

These compiler and runtime meeting minutes are under development. We welcome feedback on content, format, level of detail, timeliness, and so on. If the minutes are helpful, please let us know. If they are less than helpful, we welcome constructive comments on how to improve them.

Notes on agenda items that address Google specific needs are elided.

• We had a small celebration about the acceptance of the Generics Proposal.
• We discussed merging the dev.typeparams branch to master. There are public API typechecking changes on that branch that aren't stable. As a result, we will likely hide the APIs using buildtags.
• We continued a long-running discussion on making types2 the default typechecker. We still don't need to make a decision here, so back into the oven it goes.
• We discussed revising the syntax for typelists in generics. An internally floated proposal is similar to public proposals. More to come.
• We discussed adding attendance to entries in this document. As no one objected to having their name added, I will start doing that. I won't start by CC-ing people, just linking to their github profile for now.

Attendees: Carlos Amedee David Chase Austin Clements Matthew Dempsky Jeremy Faller Robert Griesemer Than McIntosh Martin Möhrmann Patrik Nyblom Michael Pratt Keith Randall Dan Scales Ian Lance Taylor Cherry Zhang

Comment From: jeremyfaller

2021-02-23

These compiler and runtime meeting minutes are under development. We welcome feedback on content, format, level of detail, timeliness, and so on. If the minutes are helpful, please let us know. If they are less than helpful, we welcome constructive comments on how to improve them.

Notes on agenda items that address Google specific needs are elided.

• We celebrated the reopening of tree for 1.17 development.
• We discussed some of the features we want to land for 1.17, including the register ABI, foundational work for generics, the new gc pacer, improvements to the scheduler, escape analysis improvements, and possibly some phase changes to the compiler. We also had a more in-depth discussion of subtle points in types2.
• We discussed the work on register ABI. A hello world is working (in review, not fully committed). More work for return values has also started, and we're having some success there.
• A new ABI with G in R14 and a zeroed X15 has shown reasonable promise to offer good runtime performance improvements. Work is ongoing to confirm results, and clean up some poorly understood overhead in wrappers. Also, not all of the places where we use G in assembly have been converted over. More data to come.
• We discussed an issue that turning on stack poisoning seems to bork the openbsd-amd64-68 trybot.
• We discussed a proposal to add zeroing for cryptographic functions. Consensus was that this is non-trivial.

Attendees: Carlos Amedee David Chase Austin Clements Matthew Dempsky Jeremy Faller Robert Griesemer Than McIntosh Martin Möhrmann Patrik Nyblom Michael Pratt Keith Randall Dan Scales Ian Lance Taylor Cherry Zhang

Comment From: jeremyfaller

2021-03-02

These compiler and runtime meeting minutes are under development. We welcome feedback on content, format, level of detail, timeliness, and so on. If the minutes are helpful, please let us know. If they are less than helpful, we welcome constructive comments on how to improve them.

Notes on agenda items that address Google specific needs are elided.

• We discussed the current status of our 1.17 and 1.18 goals, including the register ABI, and generics.
• We discussed a small issue on sum types. Likely more external communication to come.
• We discussed how best to handle the meeting notes (this issue), and questions and feedback. We decided it would be best to move queries to the mailing list(s) for now.
• We discussed moving GOEXPERIMENT, and how important it would be to help the registerABI work to land.
• We discussed a subtle issue in the register ABI to simplify the internal representation and requirements for go & defer. Specifically, having the compiler rewrite defer f(x) ⇒ x' := x; defer func() { f(x') }().

Attendees: David Chase Austin Clements Matthew Dempsky Jeremy Faller Robert Griesemer Than McIntosh Patrik Nyblom Michael Pratt Keith Randall Dan Scales Cherry Zhang

Comment From: jeremyfaller

2021-03-09 These compiler and runtime meeting minutes are under development. We welcome feedback on content, format, level of detail, timeliness, and so on. If the minutes are helpful, please let us know. If they are less than helpful, we welcome constructive comments on how to improve them.

Notes on agenda items that address Google specific needs are elided.

• Again, we discussed the status of our 1.17 and 1.18 goals.
• We hope that move GOEXPERIMENT knob is accepted, as the current plan with the register ABI is to use it for turnup.
• We discussed the progress on type lists. An internal proposal likely addresses all concerns, and an external document will be available.

Attendees: David Chase Austin Clements Matthew Dempsky Jeremy Faller Robert Griesemer Than McIntosh Martin Möhrmann Patrik Nyblom Michael Pratt Keith Randall Dan Scales Ian Lance Taylor Cherry Zhang

Comment From: jeremyfaller

2021-03-16

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• We discussed typelists again.
• We discussed possibly updating MIPS to MIPS32r2. The thinking is that R2's been around for a long time (10years?), and there is significant performance to be gained in the crypto libraries if we adopt it. Previous attempts have failed because of Loongson users. Discussion will likely continue.
• We discussed how to address amd64 per-architecture optimizations. Haswell specific optimizations have shown large improvements in certain workloads, and it might be worth providing for these wins. Discussion will likely continue.

Attendees: The notetaker would like to apologize for leaving off Michael Knyszek from previous attendance. I don't have a good system yet, and it's quite manual. David Chase Austin Clements Matthew Dempsky Jeremy Faller Robert Griesemer Michael Knyszek Than McIntosh Martin Möhrmann Patrik Nyblom Michael Pratt Keith Randall Dan Scales Ian Lance Taylor Cherry Zhang

Comment From: jeremyfaller

2021-03-23

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Most of the meeting was a discussion about 1.18.
• We discussed changes to the standard library for generics in 1.18
• We discussed followon work for the register ABI (beyond amd64).
• We discussed measuring PGO and other GC (Immix) ideas.

Attendees: I was absent from the meeting, and unable to grab the screenshot.

Comment From: jeremyfaller

2021-03-30

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• We discussed the remaining outstanding work, now that we're 1 month from the code freeze.
• Windows/ARM: completed, status of cgo is unknown
• RegisterABI: most of the rest of the changes are in review, will be able to start debugging in earnest.
• GC Pacer: Not complicated, but currently unscheduled. Register ABI is taking precedence, and if we get a chance, it'll get in.
• Scheduler Improvements: Most CLs are ready for review, need to do more testing for metrics.
• Improving Escape Analysis: Most CLs are ready for review
• Haswell Improvements: Needs a proposal first.
• Compiler phase changes: (interleaving front-end and SSA) mostly delayed.
• We discussed using GOEXPERIMENT as a one true feature gating system. Register ABI work has found this to be helpful

Attendees: Lost to the sands of time. I forgot to take a screenshot.

Comment From: jeremyfaller

2021-04-06

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• We discussed turning up the register abi. Our current plan is to turn the five flags that control it one-by-one, and watching the builders/trybots. The date for this turn up is TBD.
• We discussed branching again (during the freeze) for register abi and generics. Our current plan is to use a single branch for both.
• We discussed how debug information for generics was going to work. We talked about how other compilers (gcc, swift) do it. Some issues might be brought up in a future meeting with the delve folks.

Attendees: David Chase Austin Clements Matthew Dempsky Jeremy Faller Robert Griesemer Michael Knyszek Patrik Nyblom Michael Pratt Keith Randall Dmitri Shuralyov Ian Lance Taylor Cherry Zhang

Comment From: jeremyfaller

2021-04-20

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• We discussed regabi which has been completely enabled in master. Please let us know if there are any instabilities. Performance (while still changing) is showing ≥ 5% wins, and smaller binaries by 2%, with 10% smaller .TEXT sections.
• We discussed the status of types2. It's not in yet, but we intend to get it in before release.

Attendees: David Chase Matthew Dempsky Jeremy Faller Robert Griesemer Michael Knyszek Than McIntosh Martin Möhrmann Patrik Nyblom Michael Pratt Keith Randall Dan Scales Ian Lance Taylor Cherry Zhang

Comment From: jeremyfaller

2021-05-11 These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

I'm a little behind updating these notes. I'll consolidate the last couple of meetings into this one.

• The freeze is on. Generics and the register ABI work will continue on a the dev.typeparams branch.
• The register ABI is holding true on the ~5% performance improvement, and smaller binaries. There are some regressions in some benchmarks, likely related to live variables over loops with register pressure, but we might not feel comfortable fixing these for 1.17.
• On May 11, we discussed the Uber blog post. We think it's being adequately discussed on the proposal.
• On May 4, we discussed Ian's slices proposal.
• We continue to track the 1.17 release milestone. So far, it looks like we're on track for the 1.17 beta.

Comment From: changkun

Ping. Is the meeting stopped since May? :)

Comment From: thanm

2021-11-30 These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

Resuming notes after a fairly long hiatus.

• 1.18 release freeze continues; C&R team has been working mainly on bug fixing and preparing for a beta "1" release predicted to come out some time next week.
• Generics status:
  • for the front end, Robert reports that existing bugs break down mainly into two categories: problems with type inference (including some that cause infinite recursion), and problems with error reporting (error message confusing or not quite as clear as it could be). None of these should block the first beta.
  • back end is in good shape, delve / debugging works well, no known issues.
  • documentation: a generics tutorial is in the works and being reviewed
• Notable bugs: the team has been focusing on a collection of memory corruption bugs (#49209, #49259, #49453, #49689, #49686 ). Key recent findings:
  • these bugs are 100% correlated with NetBSD/OpenBSD on AMD processors (Intel processors don't seem to be impacted, ditto linux)
  • the bugs happen both on VMs (GCP, AWS) and on bare metal
  • the bugs are reproducible going back several Go releases (we've seen crashes on Go 1.10 and Go 1.12 as part of the bootstrap)
  • we are leaning towards not keeping these as release blockers given the above
• Notable bugs part 2: there is a new issue (#49138) with the race detector issue on macOS 12.
  • Cherry reports: the race detector SIGABRTs on MacOS 12. MacOS has a new malloc (“nano malloc”); setting env var MallocNanoZone=0 disables it. We are hearing from apple that the new malloc maps at a specific address, and TSAN also maps something fixed there. Apple probably won’t change their malloc. Cherry working on a fix.

Attendees: Jeremy Faller Austin Clements Robert Griesemer Michael Knyszek Than McIntosh Martin Möhrmann Patrik Nyblom Michael Pratt Keith Randall Dan Scales Cherry Mui

Comment From: thanm

2021-12-07

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

[Resuming after yet another hiatus, hope to put these out on a more regular timetable at some point].

• 1.18 release freeze continues
• C&R team has been working mainly on bug fixing
• Discussion of bugs as blocking beta release of 1.18
• runtime/pprof: new test TestLabelSystemstack is flaky Fix in review
• all: rewrite interface{} to any Waiting on one x/tools vet CL (and vendoring)
• doc: write Go 1.18 release notes misc discussion.
• discussion of the 1.18 GC pacer changes and their impact on builder instability
• structured builder output would help
• should we consider changing things so that we never stop on the first error when doing builder all.bash runs?

[Attendees list missing, apologies from note-taker].

Comment From: thanm

2022-01-05

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• 1.18 release freeze continues
• C&R team has been working mainly on bug fixing
• 🎉 Go 1.18 beta 1 released (2021-12-14)
• FreeBSD memory corruption problems
• folks from the release team are now updating the builders to incorporate the kernel fix
• bugs expected to be fixed by this include #46272, #49967, #49752
• Notable bugs and bugs discussed in detail

• 50427

• 50321

• 50276

• 50177

• 49912

• 46794

• 48656

• 48619

• 43056

• 50097

• 50084

• 49959

• 50391

• 50321

• 50190

• 50417

[Attendees list missing, apologies from note-taker].

Comment From: thanm

2022-01-18

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• 1.18 release freeze continues
• C&R team has been working mainly on bug fixing
• 🎉 FreeBSD corruption issues are now behind us (kernel bug resolved). Much rejoicing, this was a very painful problem to track down.
• Discussion of notable bugs
• Discussion of areas where we are looking ahead for post 1.18 work
• Go vision, runtime vision
• Core health
• PGO
• cmd/cover
• Generics polishing
• SetMemoryLimit
• Performance monitoring

[Attendees list missing, apologies from note-taker].

Comment From: thanm

2022-01-18

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• 1.18 release freeze continues
• C&R team has been working mainly on bug fixing
• Austin has circulated a spreadsheet with ideas on things we can do to improve "core project health", e.g. improve developer velocity, catch bugs earlier, reduce toil on the part of the release team. Team is reviewing and adding to it.
• Generics
• Several bugs fixed in generics since the first beta
• we recently had a user-visible change to export data
• google internal testing doesn't specifically stress generics to the degree that it does with non-generic code
• conclusion: it would help to have a second beta release
• Notable bugs

• 49912 Robert is going to be looking into this. Marked as release blocker.

• 50417 Dan has committed fix.

• 50619 Just found; this may trigger a second beta

• 50642 fix is in progress for this.

[Attendees list missing, apologies from note-taker].

Comment From: thanm

2022-01-25

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• 1.18 release freeze continue
• C&R team has been working mainly on bug fixing
• Notable bugs
• team members are working on triaging a couple of potential 1.18 bugs identfied as part of Google internal testing. More work needed to identify root cause.
• release blocker #50685 fix is being tested.
• Generics status:
• Several fixes have been checked in recently, another fix anticipated shortly for #50619.
• expectation is that we'll start preparing a 2nd beta release shortly after that goes in

Attendees: Jeremy Faller Ian Lance Taylor Austin Clements Robert Griesemer Michael Knyszek Than McIntosh Martin Möhrmann Michael Pratt Keith Randall Dan Scales Cherry Mui

Comment From: thanm

2022-02-01

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• 1.18 release freeze continues
• second 1.18 beta release went out earlier this week (yay)
• C&R team has been working mainly on bug fixing
• Notable bugs:
• discussion of #35006 (updating C compiler on windows builders)
• issue #50936 (SIGSEGV in gentraceback during SIGPROF handling); this issue (now fixed) came up during Google-internal testing
• issue #50113 (deadlocks during syscall.AllThreadsSyscall); fix being tested CL 381534
• we have four remaining release blockers, #45867, #49912, #50427, and #50887
• team members are brainstorming to identify + prioritize ideas to improve "core team health" (developer productivity)

Attendees: Jeremy Faller Ian Lance Taylor Austin Clements Robert Griesemer Michael Knyszek Than McIntosh Martin Möhrmann Michael Pratt Keith Randall Dan Scales Cherry Mui Alex Rakoczy Matthew Dempsky

Comment From: thanm

2022-02-15

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• 1.18 release freeze continues
• C&R team has been working mainly on bug fixing
• Bug highlights:
• no C&R release-blocking bugs at the moment, which is good

• 50113 has now been fixed (thank you Michael Pratt); this was a tricky bug

• discussion of #49679 (currently no way to reproduce)
• discussion of #45867 (may want to change the test here)
• discussion of #48505 Consensus seems to be towards adding GOAMD64=V1 and GOAMD64=V3 builders at some point.
• discussion of out-of-tree ports (arch and os)

Attendees: Austin Clements Cherry Mui Dan Scales David Chase Dmitri Shuraylov Ian Lance Taylor Jeremy Faller Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Than McIntosh

Comment From: thanm

No meeting this week (Feb 22, 2022).

Comment From: thanm

2022-03-01

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• 1.18 release branch cut, 1.19 tree open for development
• Discussion of issues relating to enabling of unified IR
• How many changes do we anticipate would have to be made on both the non-unified-IR and unified-IR paths? How long do we keep both working after enabling unified IR?
• consensus seems to be that we have to maintain both code paths until we commit to unified IR.
• we’ve basically been doing this for months now. mdempsky@ isn’t too concerned.
• discussion of testing strategy (we need both yes- and no-unified builders)
• austin@: can we break unified IR into multiple sub-experiments like we did regabi?
• considering making extra dictionary stuff a separate flag/experiment.
  • mdempsky@: Working on dictionaries right now (currently all stenciled), but want to get that working before flipping the switch.
• How long do we think we need to soak?
  • mpdempsky@: most likely enable next week
• Discussion of tentative major Go 1.19 C&R items/deliverables
• Switch to unified IR
• Generics bugs
• Generics tech debt
• Compile speed (#49569)
• Type checker error messages
• khr@: Jump tables
• SetMemoryLimit (#48409)
• drchase@: Revisit initial heap size?
  • mknyszek@: enabling currently not in scope, but can be turned on via a GOEXEPRIMENT nob
• cmd/cover overhaul
  • thanm@: about to put the proposal into the proposal process. Working on implementation. Getting good results.
• Proposals: arenas (CL), runtime.Pinner (CL), key erasure, extra runtime/metrics, turn off idle mark workers for periodic GC, external time
• khr@: Larger starting stack size
• Discussion of (#51410)
• recently caused a performance problem for a google-internal application

Attendees: Alex Rakoczy Austin Clements Cherry Mui Dan Scales David Chase Dmitri Shuraylov Eli Bendersky Ian Lance Taylor Jeremy Faller Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2022-03-01

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Discussion about triaging of builder problems
• what sort of automation can we develop to make overall process easier?
• often when a bug is filed for a specific builder test failure, someone will check a change to the test to skip the specific scenario (e.g. GOOS/GOARCH) until the bug is fixed.
• what are we doing to ensure that these skips aren't forgotten about and left in forever?
• ... ideally we could encode these skips in a way that we can see if they stop failing.
• impromptu GitHub project demo
• more discussion of #51410
• not the only known performance cliff
• austin points out that our map is pretty old; at what point do we rewrite the map using the latest and greatest techniques?
• gri@: now that we have generics, it may make sense to do this in userland.
• iant@: different people have different requirements for maps. It may make sense to have a range of map implementations that aren’t in the runtime at all.
• cmd/cover rewrite proposal has been released to public process
• robpike@ still argues for a source transform
• mdempsky@: The original userland fuzzing was a source transform and the compiler-native support is way less intrusive and much easier to maintain.
• Status
• unified IR
  • mdempsky@: still working on dictionary stuff. Importer was blocked, now unblocked. Finding some bugs and working on them. Still on track to land in next week or two.

Attendees: Alex Rakoczy Austin Clements Cherry Mui David Chase Dmitri Shuraylov Eli Bendersky Ian Lance Taylor Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2022-03-15

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Go 1.18 just went out!🎉🎉🎉 (much cheering)
• The compiler now requires the -p flag (CL 391014)
• The code paths to support a missing -p flag still need to be cleaned up.
• plan is to eventually eliminate the "". convention from the linker if possible
• Status
• Generics
  • [Robert]: given that we have only 1.5 months for development in this cycle, not enough time for huge projects (parameterized aliases, big compile time improvements)
  • focus will most likely be mainly on bugs
  • [Keith] working on some generics performance CLs
• Unified IR
  • [Matthew]: planning on landing soon (now that 1.18 release is out)
  • held up by annoying dead code issue
  • continuing to work on shape types in unified IR
• SetMemoryLimit
  • [MichaelK]: big stack of CLs in progress.
  • hope to land by the end of March
• cmd/cover
  • [ThanM]: Based on proposal feedback, now looking at a hybrid design that combines source-to-source rewriting with compiler support. Solves tricky problems with source position information in the compiler and some tricky problems with source rewriting.
  • rollout: still optimistic it can be landed in the next month and a half. austin@: Worth identifying descope options.

Attendees: Alex Rakoczy Austin Clements Cherry Mui David Chase Eli Bendersky Jeremy Faller Keith Randall Martin Möhrmann Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2022-03-22

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• ABI spec now has a shortlink: go.dev/s/regabi
• meta-remark: planning on moving the "center of gravity" for front-end discussions to this meeting
• status
• Type checker
  • Doing cleanups. Looking into performance. Minor fixes. Thinking about generics support that we postponed (does that need proposals?)
  • Clearing out a lot of unnecessary code from non-types2-based checking. Taking advantage of required -p flag.
  • CL is out to not require -p, but make unlinkable objects. Idea: if it’s package main, treat as -p main.
• Generics
  • Slow trickle of user issues. Nothing major. (🎉)
• Unified IR
  • Burning down tech debt to make this switch easier. Making dictionary code easier to reuse.
• SetMemoryLimit
  • Heap goal is responding to the limit. Next step is the scavenger. Then testing everything. Some CLs are out for review.
• cmd/cover
  • Focusing on cmd/go. Many script tests verify odd aspects of coverage. More or less convinced that the hybrid approach is the right way to go.
• Supporting out-of-tree OS ports
  • Examples: Ron Minnich’s repository, Fuchsia
  • What is the incentive for us to actually make this easier?
  • What support would we provide for out-of-tree ports?
  • [Robert]: Do we have builders for out-of-tree ports?
  • [Austin]: I think that’s one thing we most want to get out of.
  • [Keith]: We should kick out one or more of our least-maintained ports (we all know what they are) and see what it actually takes.
  • [Austin]: we could also do our own out-of-tree port and own it ourselves for a little while.
  • [MichaelP]: cleanups in the syscalls in the runtime package make make it easier (as a side effect) to support out-of-tree ports.
  • [Than]: If we do this, it would be helpful to have a way for an out-of-tree maintainer to have a way to get our blessing at some hash that passes all.bash. The blessing would be in the eye of the general public.
  • [Keith]: We could have a wiki page that says “if you’re interested in running on Dragonfly, go over here, we think this ports works.”

Attendees: Alex Rakoczy Austin Clements Cherry Mui Dmitri Shuraylov Eli Bendersky Jeremy Faller Keith Randall Martin Möhrmann Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2022-03-29

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• discussed plans for the typechecker in Go 1.19
• discussion of Russ's sync/atomic types CL.
• this is an interesting CL since it represents the first real use of generic types in std
• some potential/possible fallout from static analyzers and other tools that don't yet grok generics
• discussion of freeze timeline and team meeting dates
• Updating Windows builder C toolchain
• [Than] plan is to wait until all the CLs are in, then sync with the release team to organize the actual builder update. CLs have to wait for proposal approval due to API change made in debug.pe
• discussion of timeline for updating bootstrap version of Go on builders
• core team will own/prioritize this; may slip to next release
• general feeling at this point is that it’s a lot more work to update the builders than to live with the status quo for another ~6 months.
• discussion of recent dvyukov@ CL to update linux_amd64 race syso (removes goroutine limit)
• would be great to get this rolled out to all applicable builders for 1.19
• [Than]: I want to make sure it gets built with the new Windows C compiler.
• [Cherry]: we have a tool that automates the update via gomotes, once new compiler is in place we can just use that
• status
• Front end
  • Just fixing bugs in type checker and parser, plus "-p" cleanup.
• Unified IR
  • Added a go/types importer.
  • Other generics issues
  • Bugs have been easy to diagnose and solve.
• SetMemoryLimit
  • Updating CLs from comments.
  • Stuck on not being able to ready a goroutine from inside the allocator. Working on it.
  • Targeting end of week for having all the CLs ready.
• cmd/cover
  • Working on cmd/go. Unit tests are passing with both new and old coverage. A lot more unit tests to write.
  • After that, going to focus on reporting changes.
  • Committed to the hybrid approach at this point.

Attendees: Austin Clements Cherry Mui David Chase Dmitri Shuraylov Eli Bendersky Ian Lance Taylor Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2022-04-12

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• one month to go (roughly) before release freeze
• Updates
• Front-end/generics
  • [Matt] compiler is now switched over to unified IR export format, which caused a bunch of problems with x/tools tests. For now, disabled trybot. Need a better solution for major export format changes.
  • generics issues: bugs are coming in, but the rate overall seems to be manageable at the moment. Several failures are in consistency changes with new code going through the old importer for things where those checks no longer make sense.
• SetMemoryLimit
  • moving closer to land this feature
  • plan is to document limitations on small heaps (with plan to improve in the future), feature-flag big change but don’t worry about small corner-case differences
  • Michael P and Austin to review CLs
• cmd/cover
  • Plan: drop old compiler-only support from CL stack, put hybrid CLs out for review. Prioritize matching current functionality, with new functionality for later.
  • What should “go build -cover” cover? “go test -cover pkgs…” covers just pkgs, but that doesn’t seem like the right default for go build. Cover the main module by default?
  • [Than] The argument for instrumenting everything is that you can filter it down at reporting time.
  • [Michael K]: if I were to use “go build -cover”, instrumenting everything is what I would expect.
  • [Ian] I suspect most people aren’t going to care about coverage of std. And probably “low level libraries” though we don’t know what that is.
  • [Than] defaulting to packages in the main module may be best.
  • [Kieth] one factor is run-time cost of coverage instrumentation.
  • [Than] benchmarking needed here. Definitely faster than -race, but not sure exactly how much.
• discussion of https://github.com/golang/go/issues/52209 [cmd/compile, cmd/link: generate dwarf type info in compiler] and related stack of CLs
  • Than to review and keep an eye on progress.
  • Noted that this is a fairly large project, will probably take a while to get through all the details.

Attendees: Austin Clements Carlos Amedee Cherry Mui David Chase Dmitri Shuraylov Eli Bendersky Heschi Krienek Ian Lance Taylor Keith Randall Martin Möhrmann Matthew Dempsky Michael Knyszek Michael Pratt Than McIntosh

Comment From: thanm

2022-05-10

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

[no meetings previous 2 weeks due to quiet week, internal team summit]

• Go 1.19 release freeze has started
• Call for discussion of outstanding CLs that need final reviews this week
• [Michael K] Sent out a series. Fix for SetMemoryLimit, several CLs to add metrics, resolve an external proposal for more metrics. (Sent to austin@ and drchase@, but anyone can look.)
• [Robert] rfindley@ has a bunch of type checker CLs to follow-up on a bug fix. (gri@ to review or adonovan@)
• [Keith] Larger starting stack CL sequence (mknyszek@ still reviewing)
• [Ian] Good time to check issues with 1.19 milestone and fix them or push them to 1.20 or backlog.
• please update the release notes!
• Generics plan for H2’2022? (1.20 and early planning for 1.21)
• [Eli] we want to get a jump on the planning process for this work
• candidates
  • performance work
  • possibly/potential interaction with PGO
  • unified IR
  • type inference improvements
  • features like internal types (may be low demand)
  • figure out what to do about x/exp packages that use generics (graduating things to std and additional proposals that haven’t even made it to exp)
  • [Robert] There are ~5 proposals for how the built-in type comparable should work. We have to resolve this sooner than later. (Problem is that interfaces are comparable but may panic and “comparable” only includes types that are comparable without panics.)
  • elimination of implementation restrictions we currently have. (And should we?)
  • [Robert] error message tuning
  • [Keith] compiler speed
• [Matthew] are we going to create a 1.20 dev branch? Would like to land unified IR fixes so its ready.
• [Austin] I’d be fine with a dev.unified.
• do we want to have an external monthly version of this meeting?
• discussion about logistics (possibly something like existing tools meeting)
• Lighterweight option: office hours with C&R team?

Attendees: Austin Clements Carlos Amedee Cherry Mui David Chase Dmitri Shuraylov Eli Bendersky Ian Lance Taylor Keith Randall Matthew Dempsky Michael Knyszek Robert Griesemer Than McIntosh

Comment From: randall77

2022-06-21

(Sorry we've been slack about this in the past few weeks, it fell through the vacation cracks.)

• New performance dashbard https://perf.golang.org/dashboard/
• Diff from most recent release
• Discussions about better release automation and a submit queue
• [Robert] Would this affect how we run try bots?
• [Michael K] We could be much more aggressive about culling the try bot set so it’s really fast. That would encourage running try bots more, and the SQ could catch everything else.
• [Matthew] Can we mail reviewers only once trybots have passed?
• Generics updates
• [Matthew] Big stack of CLs for adding rtype fields to IRs for runtime type information. For dictionaries in the unified IR world. Adding regress tests on master, marked as broken in non-unified mode.
• [Robert] Mostly fixing bugs, clearing up spec. Biggest outstanding issue is comparable.
• Discussion of release blockers

• 53378. Rhys has a proposed fix.

• 53374

  • [Cherry] Range of possible solutions. 1.18 changed ARM64 prologue slightly: previously, small frames didn’t have a signal-unsafe window. We could go back to that (though this probably affects other LR arches).
  • [Iant] This implies we’re doing our prologues incorrectly.
  • [Cherry] We do it that way so we can always unwind. C avoids this problem because it has richer unwinder information that can say “we’ve decremented SP, but haven’t saved LR yet.” We could enrich our unwinder information with that extra bit. I’m hesitant to do that at this point for 1.19.
  • [Cherry] Another angle is from the runtime: immediately at thread entry from assembly, set up a signal stack. Involves tons of assembly code across several architectures.
  • [Austin] I’m inclined to revert prologue for small frames for 1.19 and do the better metadata for 1.20. That’s fragile, but it’s just a stop-gap.
  • [Cherry] That doesn’t help other LR arches, but maybe those issues are old anyway. We would have to manually inspect the frames up to setting the signal stack to make sure they’re small.
• External runtime meeting notes
• [Keith] We haven’t released external notes for about a month.
• [Austin] Than’s been out and I guess we don’t have any bench depth on this.

Attendees: Alex Rakoczy Austin Clements Cherry Mui David Chase Dmitri Shuraylov Eli Bendersky Ian Lance Taylor Keith Randall Matthew Dempsky Martin Möhrmann Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2022-06-28

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• 1.19 release freeze continues
• we reviewed the list of release blocking bugs
• Michael K held the first C&R issue triage meeting last week
• Michael P reports: We discussed process. Plan is to go through new issues (and maybe performance) to determine general priority and who should look at it next using the assignee field. MK is planning to get gopherbot to at least auto-add label and maybe add to the project and track which issues are not getting updated.
• Generics updates/Unified IR
  • Matthew: Landed all CLs last week. A few more on implicit conversions and tricky cases around for-range. When that’s done, I’ll wire up stuff for creating dictionaries.
  • Robert: Minor updates on error messages.
  • Ian: I’ve updated the iterator proposals again. Added an optional Done method that will be called by range loops. Simplified MakePipe to runtime.Iterate(func(yield func)) that creates a goroutine to run the generator function and makes it very similar to Russ’ and Jonathan’s proposals (plus clever runtime scheduling). We can apply a compiler optimization so instead of a separate goroutine, we can do everything in-line.
  • Keith: My worry is there will be a big performance cliff depending on whether the compiler can figure that out.
  • Ian: I think we can make the goroutine thing pretty efficient, too, but that is a concern.
• note from hana: expect more improvement work in compiler/runtime-delve interaction than in the editor integration domain near future, wonders if someone from the C&R team might be willing to attend the dlv meetings. thanm@ will reach out.
• https://perf.golang.org/dashboard/ now has change detection
• no meeting next week

Attendees (partial): Austin Clements Cherry Mui David Chase Dmitri Shuraylov Ian Lance Taylor Keith Randall Matthew Dempsky Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2022-07-12

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Go 1.19 rc1 is out! 🎉
• Go 1.20 planned items
• Core project health
  • Austin and Heschi to prioritize again and start assigning
• PGO preview
  • MVP is compiler support for reading profiles with one or two simple optimizations. Considering what cmd/go support we have beyond that.
• Unified IR
  • Coming along. David’s benchmarking shows 8% build time slow-down, but there’s been minimal optimization effort. Unified IR export format has debug markers for checking sync (moving that from static to run-time flag). Dictionary support is close.
• Go generics planning for H2’2022 - still need to narrow down scope
• cmd/cover
  • Slipped from landing at tree-open; bottle neck at the moment is getting the cmd/* CLs reviewed.
  • More work needed on reporting changes.
• Arenas?
• Discussion of Go 1.19 release blocking issues
• Discussion of Go 1.19 non-release blocking issues
• runtime: upgrade to v3 version of race detector #49761
  • [Than] still working on updating windows syso to V3
  • problem area seems to relate to differences in how TSAN shadow memory is handled between v2 and v3
  • also work needed on Go linker to support import symbol thunks
  • thunk support needed when using updated C toolchain, and V3 tsan requires updated toolchain, see #53540
  • Q: What happens if we don’t fix this for 1.19? A: we’ll be stuck with the v2 race detector on Windows and will continue to run into problems using Go with more up-to-date system toolchains.
• There are a couple unified IR bugs. Should those just move to 1.20? sounds like answer is yes
• runtime: modified timer results in extreme cpu load #51654
  • backport likely
  • [Michael P]: Probably just figured out what’s wrong.
• global variable init bug https://github.com/golang/go/issues/51913
  • [Matthew]: May cause programs to be slightly larger or take slightly longer to init. Confident in fix correctness.
  • Q: Would we do something different in 1.20?
  • [Matthew]: Would probably land the same fix. We might be able to improve the optimization.
  • [Cherry]: Do people depend on this buggy behavior?
• New GC guide has rolled out: https://go.dev/doc/gc-guide

Comment From: thanm

2022-07-19

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Go team is participating in a "friction fixit week"
• Friction fixit week
• Go 1.19
• No C&R release blocking bugs at the moment
• Non-release blockers
  • Matthew: We should stop backporting generics fixes to 1.18. Maybe keep doing backports to 1.19.
  • We think this is okay per policy because these things never worked.
  • runtime: upgrade to v3 version of race detector #49761
    • Dmitri sent comments on latest version of LLVM CL. On hold at the moment.
    • Than: We’re going to need Windows builders with both the old and new toolchain for a while. Old versions of Go won’t understand host objects from new toolchains, so if we just rolled out the new C toolchain, we couldn’t test old supported versions of Go. So we’ll need to test old Go versions on the old C toolchain and the new Go versions with the new C toolchain. Newer versions of Go still support the older toolchain (unless it’s a TSAN build once we upgrade to TSAN v3).
    • tracking issues for this work: update Windows toolchain (#35006), syso update (#49761, #53539), problems with new compilers and new builders (#53540)
• Go 1.20 early in cycle status
• Unified IR
  • On a branch during the freeze. We’ll merge that ASAP but keep it behind an experiment.
  • Matthew: I've got CLs out for explicit RTTI everywhere. Cuong has reviewed them. Waiting for another reviewer on them. Then working on populating RTTI from dictionaries. David is working on internal google testing.
• cmd/cover
  • Review progress:
    • cmd/cover CL reviewed by Bryan, comments incorporated
    • Bryan also looked over the cmd/go CLs; working on his comments now.
    • one or two C&R CLs that need reviewing.
    • Hadn’t anticipated how things work on Android, so there may be extra work there. Go test -cpuprofile=x doesn’t work on Android because cmd/go creates a directory on the host but then the guest tries to write to that path and it doesn’t exist. Currently, -cover works but -coverprofile doesn’t, but with new cmd/cover not even -cover works.
• Michael K: might want to get in my ("remove cache misses from findObject") and Keith’s (one bit bitmaps) GC changes just to soak.
• Keith: Mine shouldn’t cause conflicts, but it would be good to let it soak.
• Other nasty bugs
• runtime: random crashes on macOS 13 Ventura Public Beta (#53800)
• Cherry: This is a very weird bug. It looks like some old value suddenly overwrites a new value on a stack. Now trying to clobber with timestamp bits and after a stack gets copied a bunch of times it suddenly shows old timestamps.
• Keith: Are we sure it’s just stacks?
• Cherry: No.
• Michael P: Sounds like maybe a kernel CoW or page moving race condition.
• Matthew: Can we send a repro to Apple to bisect on their end what might have changed?
• Cherry: been exchanging emails with Apple. They said it started between a couple of different kernel intermediate versions ("seeds")
• Than: I wonder if running under a debugger with a hardware watchpoint might help? Have to know what’s going to get clobbered.
• runtime: running cmd.exec within goroutine sometimes leaves process with 100% CPU #53863
• Darwin-specific. Has a C repro, but we could work around the kernel bug.
• Cherry: I can send Apple an email.

Attendees: Austin Clements Cherry Mui David Chase Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Than McIntosh

Comment From: randall77

2022-07-26

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Discussion about WebAssembly stack switching
• Go 1.19
• Release scheduled next Tuesday.
• Go 1.20
• CLs that need to land before the tree opens?
  • Clean-up p and g (mpratt, high priority, lots of conflict potential)
  • Lock ranking redo (austin, medium priority, would conflict hard with changes to the lock rank graph, but I’m not sure we’re expecting any of those)
• When is the tree reopening?
  • August 8th
• Unified IR will be merged, but may not quite be ready right at opening.
  • May set to enabled on the branch for more coverage before merging.
• One bit heap bit CLs from Keith.
• MK’s pacer changes.
• Others?
• “Quarterly” ARM meeting
• New ARM assembler stuck in review. Goal is to support easy addition of SVE instructions and general maintainability, but there are design disagreements, mostly around the handling of generated code versus hand-written code.
• PMU-based pprof also stuck in review. Some questions around approach and API design. mpratt is on it.
• SIMD API. Saw community proposal go by. Russ is active on it. We’re all agreed that we want something platform-independent and vector-length agnostic. ARM is especially interested in it being vector-length agnostic because of new SVE instructions. austin told them not to expect this any time soon. They’re okay with that and just want to be involved in any design work that does happen.
• ARM is looking at performance gaps where emulated x86 Go binaries on M1 outperform native ARM Go binaries. They’ll share their analysis.
• ARM is working on Memory Tagging Extension support for Go for interoperating with C code compiled with MTE (sort of a hardware-accelerated ASAN).

Attendees: David Chase Keith Randall Matthew Dempsky Michael Pratt Than McIntosh

Comment From: thanm

2022-08-09

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Go 1.20 status review
• All early-in-cycle changes are in and the tree is generally open 🎉
• Overall generics status
  • Go generics planning for H2’2022
  • [Keith]: Some small optimizations. Iterators???
  • User survey responses on generics adoption challenges are looking good, a lot of people are happy
• Unified IR [Matthew]
  • Supports local type definitions within generic functions.
  • Merged to master, but is currently off. CL stack is almost ready for switching to shape-based stenciling and turning on unified IR.
  • There are some google-internal packages that fail to compile with OOMs or time-outs.
  • [David]: for the google-internal issues, we are down to two problems with unknown cause. One obvious time-out in progress. A few other failures.
• Core project health [Austin]
  • AI for everyone: what do you want to work on?
• PGO preview [Cherry]
  • Planning doc talks about our targets for 1.20 and later.
  • For 1.20, we’ll focus on the compiler and maybe do something simple on the cmd/go side.
  • At most we’ll automatically pick up profiles from the main package.
  • A longer version of the design doc is almost ready for team review.
  • We’re planning to use pprof format for this version (we may revisit that).
  • We’ll have to add a little more to the pprof profiles from the runtime.
  • Orthogonal to proposals to change runtime/pprof API.
• cmd/cover [Than]
  • Almost done with Bryan Mills’s comments.
  • Biggest change is better support for Android/wasm (where you can’t fork/exec from a running test process).
• updated Windows TSAN support mostly done now
  • New version of TSAN runtime requires updated builder compiler
  • will need to keep older windows builder configs alive as well since older Go releases need the older compilers.
• One bit heap bitmap [Keith]
  • Checked in and then reverted.
  • Issue with accessing uninitialized bitmaps of noscan spans.
  • Will fix that and try again.
• Pacer changes [Michael K]
  • Revisiting a design decision from a while ago to pick a better smoothing function.
• Arenas [Michael K]
  • Planning to land GOEXPERIMENT=arenas. Already working on this.
  • Now it recycles address space and sets memory to fault (rather than unmapping it). Need to rewrite bitmap code to work with the 1-bit bitmap.
• Bootstrap is now Go 1.17 (#44505)
• How often should we update the bootstrap? (#54265)
• [Austin]: If we update every year, does that mean building from scratch scratch takes an extra step every year?
• [Michael K]: What’s the value of building it from scratch scratch? Even ports don’t start there.
• [Matthew]: “Trusting trust”. Bootstrapping to a new platform, though 1.4 already doesn’t work on all platforms. We could bootstrap off gccgo.

Attendees: Austin Clements Cherry Mui David Chase Eli Bendersky Jenny Rakoczy Keith Randall Matthew Dempsky Michael Knyszek Than McIntosh

Comment From: thanm

2022-08-16

• Discussion of externally contributed 1.20 C&R work (from 1.20 planning thread)
• Linux/riscv64 plugin support [Meng Zhuo mengzhuo1203@gmail.com] ⇒ Cherry to take a look?
• "And riscv codegen from upstream" (unsure what that means)
  • [Michael P]: ARM folks mentioned generated codegen from an ISA description. Maybe it’s the same thing for RISC-V.
• runtime.Pinner (CL, issue [Sven Anderson sven@redhat.com] ⇒ Austin to take a look
• Ppc64le POWER10 assembler/compiler support [Lynn laboger@linux.vnet.ibm.com]
  • [Eli]: The new porting policy (see accepted proposal) is in place now. Will this require a significant investment of time from the C&R team to review? Or is this just a cursory review?
  • [Keith]: There’s a distinction between ports that have more than one maintainer who can review each other’s changes and ports that only have one maintainer.
  • [Eli]: Ports need to have two maintainers now.
  • [Keith]: I don’t think we’re there yet for all ports, so we have to keep helping people along.
  • [Austin]: We should be helping the port get out of the tree if it can’t get another maintainer.
  • [Eli]: If we keep doing what we’ve been doing, this policy will fall by the wayside. If there are important ports that are having trouble finding another maintainer, we can have a grace period, but we need to be explicit.
  • ⇒ David to take a look
• Move DWARF type gen into compiler (CL stack, issue) [guangyuan zhou zhouguangyuan.xian@gmail.com]
  • [Matthew]: I’ve spot checked compiler stuff. Some of the CLs need work, communication is proceeding.
  • [Matthew]: Another concern: this requires descriptions of a lot of more runtime types in the compiler. The linker used descriptions from runtime source; the new scheme adds a dozen more types into builtins that have to be kept in sync with the runtime. We’re going to have to be much more careful about keeping those in sync, or we’re going to have to generate the builtins file from the runtime source. Are we willing to endure that pain?
  • [Austin]: I’m okay with pushing back on this. It’s definitely "nice to have", but not critical for anything.
  • [Than]: Linker parts look okay. If I had done this myself, I would generate DWARF in the compiler differently. Author just moved the current (weird) way we generate DWARF in the linker and moved that to the compiler. We can improve that later. It does cause a 2–3% compile time slow-down.
  • [Matthew]: How much do the object files get bigger?
    • A: unknown
  • [David]: Does the link time get better?
  • [Than]: There’s only a small link time win from the numbers I saw (surprising); could simply be due to larger objects. Might be worth digging into this a bit more.
  • [Austin]: What’s the motivation for this?
    • Link time reduction and complexity in the linker. Is it worth doing this?
    • [Than]: The author was motivated to improve debug info in shared libraries. There’s no way to connect the DWARF in a shared library with the DWARF in, say, the runtime. This CL shows how the new scheme for linkshared will work.
  • [Austin]: I think we need to step back and look at the reasons for doing this and whether this change is actually satisfying at least some of them.
• //go:notinheap cleanup (https://go-review.googlesource.com/c/go/+/421878/7) [Cuong Manh Le]
  • [Matthew]: The first couple CLs seem good to land. I would rather runtime people approve the runtime side. It turns some arrays/non-structs into structs to do the field embedding.
  • [Keith]: I have this on my to-do list.

Comment From: thanm

2022-08-23

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Public iterators discussion
• This is mostly agreeing on a standard interface, but has a few impacts on compiler (see "Range loops") and compiler/runtime (see "Appendix: Efficient implementation of iter.NewGen")
• Status
• Unified IR (mdempsky@)
  • Turned on by default on tip, but not yet on for google internal use. Some useful bug reports, including issue https://github.com/golang/go/issues/54625 related to k8s
  • One last google-internal failure, hope to have it enabled for google internal use this week or next. If it takes longer, that’s concerning and we should revisit enabling it externally.
  • Gating criteria for build speed and RAM impact?
    • +10% build time.
    • Really focused on correctness and feature-completeness. A lot of string building and other things that we could reduce.
  • Plan: fix k8s, enable in google3, then build speed
• Core project health (austin@)
  • We’re starting to assign the next round of tasks. Partly this has been blocked by wanting to team up people from releases and people from C&R, but not wanting to distract release folks from relui.
  • Release automation work continues, but Heschi and Jenny have freed up to work on other things.
  • Austin, Heschi, and Eli will touch base once more and really kick some things off.
• PGO preview (cherryyz@)
  • Design doc shared with team. Good feedback. No major problems. Okay to proceed. Planning to make a simplified version of the tool doc and making that public to get feedback. For the implementation side, we’re going to sync with Uber.
  • [Austin]: Write a short proposal to send through the process? Very little of this actually has to go through proposal review.
  • [Cherry]: Just the cmd/go and workflow integration. Maybe link to detailed docs.
  • [MichaelP]: Might include runtime/pprof API.
• cmd/cover (thanm@)
  • Finished all of Bryan’s comments, waiting for more feedback from Bryan.
  • IDE integration?
    • Haven’t figured out how to enable regular coverage display; hoping to meet with Hana when she gets back.
    • Pretty sure this is a VSCode Go thing, not gopls.
    • You can already point it at a previously collected coverage profile, it just doesn’t seem to show anything.
  • Start thinking about how to communicate this change to the community. “Integration test coverage” is a good, succinct phrasing that captures most of the point. Blog post?
• One bit heap bitmap (khr@)
  • Landed! Had to fix arena bug. Another bug with noscan spans; need to chose between khr@ and mknsyzek@ fix.
  • Interaction with arenas?
    • [MichaelK]: It does interact with arenas, but the bitmap changes have already landed and I copied khr's change to the google3 patch into my version. Seems to work.
• Pacer changes (mknyszek@)
  • [MichaelK]: Can land any time, but I want to experiment a bit more first. * Small CL.
• Arenas (mknyszek@)
  • [MichaelK]: Ready for review; modulo a few questions over how to roll out.

Attendees: Austin Clements Cherry Mui David Chase Eli Bendersky Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• discussion of demo on new functionality in cmd/cover coming in 1.20
• [Robert]: does the metadata have a signature in case the binary changes?
• [Than]: yes. filename incorporates hash.
• [Austin]: differential coverage: would be interesting to have tooling that would report on a given commit what lines are no longer covered in addition to things that are newly covered.
• [Hana]: go tool covdata subtract use case seems similar to go tool pprof -base, which is clear what is base.
• [MichaelP]: In addition to the covdata tool, do we provide a package that people can use to build their own tools?
• [Than] We’d like to, but haven’t yet. There are packages for this, but they’re all internal right now. It makes sense to eventually export those to an x/ repo.
• [Keith]: Why not default to covering all packages? Or “all but std”? Since you can always filter later, you might as well collect all the data.
• [Than]: I think it’s easier for the user to only think about packages in the main module. There also is some overhead here. For example, building the runtime with coverage slows things down.
• [Keith]: I could see having it on for everything but the runtime (and maybe a few other std things) and having the reporting tools filter it by default.
• [Alan]: Seems like it might be worth measuring at least
• [Austin]: What do operations mean on coverage profiles with different metadata?
• [Than]: Similar to today’s results when the source skews from the profile. For merging, it hashes the metadata of each function and if they’re different it treats them as different functions. Source file, lines and columns, and statement structure. If there are insertions above the function (but not in the function itself), that will be considered a change.
• [Austin]: We’re using function-relative line offsets in PGO to address that.
• [MichaelP]: That metadata will be in the binary at some point for PGO, and coverage could use it.
• [MichaelK]: This sounds like what Linux perf does when you compare profiles from “different” binaries: lots of -s and lots of +s. Pprof just hashes on the symbol name, which works a lot better, at least at a function level.
• [Than]:: For profiling, I see how you definitely want “best effort” matching.
• [Austin]: better matching seems as though it would be important for differential coverage
• [Robert]: We have “go fmt”, “go test”, etc. Now we have “covdata”, which seems inconsistent. Maybe "go tool cov" would be better?
• [Than]: Delve team folks are asking about how much work it would be to implement issue 31132 “runtime: stop single goroutine”.
• [MichaelK]: What’s the use case?
• [Austin]: Resuming a single goroutine seems clear. I’m not sure for stopping a single goroutine.
• [Than] upstream delve issue is https://github.com/go-delve/delve/issues/1529
• [MichaelP]: seems doable, but there are weird edge cases.
• [Austin] Some of this is already there for GODEBUG=gcstoptheworld
• [MichaelP]: We need to preempt all goroutines. After a breakpoint stops the process, you have to let them resume a little bit and then stop.
• Status
• Go generics planning for H2’2022
  • Comparable, Iterators
  • [Robert] Ian and I are discussing a new comparable approach. Ian did a write-up. Plan is to share it at the summit next week. It will simplify what we have now and be backward-compatible and solve the comparable problem.
• Unified IR
  • [Matthew]: k8s bug is fixed. internal google testing pending. Build speed and RAM are the next priorities.
• PGO preview
  • [Cherry] new code drop from Uber
  • [Cherry] working on new external design doc
  • [MichaelP] started hacking on runtime support. Mostly about binary size. Already cut down 1% with pclntab change.

Attendees: Austin Clements Cherry Mui David Chase Eli Bendersky Jenny Rakoczy Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2022-10-04

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• FYI
• Public “redefining for loop variable semantics” discussion. Almost entirely supportive!
• CL 431919 looks like another example of where go:nosplitrec would have been useful.
• discussion around developing 3 year compiler/runtime strategy
• [Matthew]: We’ve tossed around moving away from self-contained export data. With protobufs in particular, you get n^2 growth. There are trade-offs. Blaze would have to ship around a lot more .x files, though the total size would probably be a bit smaller.
  • [Austin]: How much of a problem?
  • [Matthew]: It’s definitely a nuisance. It was a problem with unified IR. People have had to modify their code to deal with this sometimes (though they were happy to do it because it sped up compiles).
• [Ian] related: the “action chain” problem with Go limits parallelism.
• [Matthew]: You don’t have to look at function bodies for type exports, at least. Java had something like this. We could at least type-check everything and then figure out inlining between packages.
• [Ian]: We’ve had complaints about it in the past for very large builds. It may be somewhat dominated by link time.
• discussion of overhead, increases in "process" overhead relating to getting Go development work done
• [Robert]: If we really want to increase our velocity, we have to reduce our processes. It starts with little things like the two Googler review rule. They add up. Can we remove red tape.
• [David]: Important to automate new processes. You can’t necessarily automate all new process, but you could say any new process has to come pre-automated. E.g., for two-Googler rule, we now have a dashboard. That could have been required from the beginning.
• [Austin]: Partly Go’s maturity has added a lot of internal process.
• [Robert]: Last week there was a big uptick in contributors sending a huge number of tiny changes. A lot weren’t substantial improvements and could have introduced bugs. Should we say something to the outside? Or just ignore them?
• [Ian]: These seem similar to an LSC. If anyone doesn’t want to look at them, don’t look at them. We can push back on churn. I think most recent ones have been improvements.
• [Than]: I think we should push back more, at least to the extent of communicating to ensure people understand it’s a zero-sum game. The time we spend reviewing these takes away from time we could be improving go.
• [Austin]: There’s an ingress vs egress problem.
• [Ian]: Some folks who send these sorts of will turn into useful contributors over time, though most don’t. Many recent changes are coming from Chinese contributors, and if the large Chinese Go community is getting more involved, we want to encourage that.

Comment From: thanm

2022-10-11

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• FYI
• (Another situation showing the need for go:nosplitrec -- CL 441859)
• Couple of interesting talks at GopherCon on using a WebAssembly VM written in Go to load and isolate plugins written in wasm into a Go program.
• It’s not totally clear how a trend like this would affect us, except that it would be nice if those plugins could be written in Go and offer a good experience. (Probably requires WASI; if loading multiple plugins, maybe binary size matters?)
• [MichaelP]: Do we know what language people were writing these plugins in?
• [Ian]: Some were in Go. Another example was specific to writing the plugins in some particular language.
• [Keith] The plugins also worked on all architectures.
• [MichaelP]: Was this a security sandbox?
• [Ian]: Partly. It was a good talk.
• [Cherry]: Were they doing a single entry or lots of crossings?
• [Ian]: They were running a subprocess and just passing a byte stream over stdin/stdout.
• Bitmap change
• Post-mortem: the bitmap change caused a fair amount of roll-out and debugging pain. How can we improve the process in the future? Were there process steps we missed (e.g., GOEXPERIMENT-gating the change)?
• [Keith]: We didn’t wrap it in any knobs. It’s difficult because we were changing the data structures, too, so it would be hard to keep around both the old and new code.
• [Austin]: It could have been behind build tags to choose statically.
• [Matthew]: Could we have put both paths behind build tags? What could have been different about how GOEXPERIMENT works today that would have made this easier?
• [Keith]: #ifdef’ing individual functions (and struct fields) so you don’t have to move them all to a separate file first.
• [MichaelK]: Separating it into files wouldn’t have been easy. You’d need to fork the heapArena type, or have an indirection. (Embedding helps with this.) I’m not sure how much build tagging this would actually have helped. There were some corner cases being caught only be cgo checks (e.g., those are one of the very few places we read bitmaps for noscan objects). It was pretty clear from the dashboard right away that this was the problem.
• [Austin]: The breakage lasted a while on the dashboard, right?
• [Keith]: We figured out that it was the bitmap change quickly, but it took a while to figure out the fix.
• [Keith]: Doing it early in cycle was more valuable than gating it, since we could stabilize it long before the freeze.
• 3 year strategy
• What are the structural barriers in the compiler? E.g., we've been saying for years that we'd like to move inlining to SSA, but that requires moving at least escape analysis to SSA, and maybe a high level SSA. Are there more things like that and are there common themes? Things we could address for the long term health of the compiler project?
• [Matthew]: Get rid of the middle end. Do as much as possible in SSA and get to SSA as directly as possible. There’s a roadmap to that and I have some ideas. * [Robert]: I believe we still use the old type checker for parts. We should get rid of that.
• [Matthew]: We still use it when we generate code internally in the backend. It’s used less and less. We don’t use it for checking user code. E.g., wrappers, equality and hashing functions, desugaring in some walk steps. Unified IR got rid of a lot of this in the frontend, but most of what’s left is in the backend. If we had a higher-level SSA with function calls and map lookups, etc, we could directly generate those, and desugaring those would happen as SSA passes.
• [Austin]: Do you wind up with SSA level mismatches?
• [Ian]: There is an analogous thing in gccgo where sometimes you’re at a lower level and you want to generate at a higher level. I just call the lowering steps by hand and that works.
• [Eli]: What’s the cost of keeping the old type checker?
• [Keith]: It’s just a convenience so you can generate IR without specifying all of the types. It can fill in the types for you. Getting rid of it would make existing code more verbose.
• [Matthew]: As we’ve been adding IR nodes, we’ve been making their constructors fill in things like that. That makes the API simpler and leaves less room for mistakes.

Attendees: Austin Clements Cherry Mui David Chase Eli Bendersky Ian Lance Taylor Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Sameer Adjmani Than McIntosh

Comment From: thanm

2022-10-18

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2022-10-18 * approximately one month until release freeze (again) * Unified IR export data size is apparently causing some unexpected load increase in one of the Google-internal build systems; discussion about what might be causing this and how to handle it. * [Matthew] notes: * Unified IR encodes the full package graph in the export data, which has more overhead than I expected, especially for small packages. Previously, we only wrote out the packages that were relevant. We could drop that precise graph as a way to reduce export data size. * In indexed export format, we used compressed positions, which isn’t implemented in unified IR yet. That would probably be an easy win. * Unified IR doesn’t do as aggressive unreachable method pruning, which could also be a factor. * note that any export data format change requires many steps, unfortunately * [Robert]: I think second item (compressed pos) is an easy win. It made quite a difference in the earlier format. * [Eli]: Would fixing this make build speed better, too? * [Matthew]: I think most of the issues are elsewhere. But might possibly help for the google-internal case, maybe. * [Matthew]: Prioritizing export format issues over build speed makes sense because of the length of the pipeline. * [Keith]: Q: Extra synchronization stuff in the format? * [Matthew]: That’s not on by default. * Batching write barriers. * Keith has circulated an early stage doc laying out a design for reducing write barrier overhead, and an experimental CL * discussion about CL and of cgocheck=2 mode, which depends on the existing write barrier scheme * Keith to talk with Ian about how much cgocheck=2 is used * Status * "Comparable" work * [Robert] We have a proposal. Sent to Axel Wagner and gotten some good feedback, but doesn’t see anything wrong with it. Waiting for Ian. Hopefully we can send it out this week. The actual change would be ~5 lines of code, so we could actually do it if we get it approved in time. That would fix the comparable issue and would be forward-compatible with the full change in the doc. * [Robert] implementation could be done behind a flag. * Build speed/RAM (unified IR) * David evaluating a GC hack targeting this * PGO preview (cherryyz@) * [Cherry]: on the compiler side, Uber’s CL seems in reasonable shape. We’re planning to bring their code in and iterate from there. * [Cherry]: inlining heuristics may need more work. * [Cherry]: Runtime start line numbers are in, but needs to be incorporated into the profile consumer. cmd/go flag needs work on building multiple targets. * [David]: Have we tried profiling the compiler? * [Cherry]: probably need the revised inlining heuristics for that work. Also, the compiler is hand-optimized. * Integration testing coverage * [Than]: all CLs in, turned on. Working through long tail of bugs. * Arenas * [MichaelK]: done, all systems go at this point. * Pacer changes * [MichaelK]: no updates * Core project health work * [Austin]: Proceeding on various fronts.

Comment From: thanm

2022-10-25

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• ARM’s big asm change (go.dev/cl/424138) seems stalled. What is it blocked on?
• [Cherry]: Some older CLs not the right approach. Need to take a look at newest iterations. Plan to take a look this week.
• C&R team met with ARM folks to sync up on Go related things
• Any objections to openbsd/ppc64 port? (issue #56001)
• no objections in meeting so far
• [discussions of google-internal compiler deployment issues]
• [discussions of google-internal testing issues]
• topic: making it easy to change the compiler’s export info
• brainstorming has been happening on this in various meetings
• number of stakeholders who would benefit, including gopls, the vulnerability checker, etc.
• [Matthew] I’ve been experimenting with approaches to speed up export data compilation
• General discussion of how we should go about categorizing/measuring tasks that we think of as "maintenance"
• [Keith]: Responding to external CLs. How much are we reviewing CLs? How much time does it take to review? Time spent chasing bugs in these CLs? Time saved by contributors doing work for us?

Attendees:

Cherry Mui David Chase Eli Bendersky Ian Lance Taylor Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh Jenny Rakoczy

Comment From: thanm

2022-11-01

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Page tracer demo at team meeting(presented by mknyszek)
• Should we land this?
• mpratt@: I like it and I’m in favor of merging it. Keep behind a GODEBUG so we don’t have a compatibility promise.
• mknyszek@: Ideally this would eventually just be part of the execution tracer.
• khr@: Can we steal back the P page cache?
• mknyszek@: It mostly impacts smaller heaps. We could flush it at the same time as mcaches.
• austin@: I think the bar for landing tooling that’s primarily for our own debugging should be pretty low.
• Should we have an x/exp subdirectory for debugging tools?
• FYI
• public discussion of rsc@’s “user-defined iteration using range over func values”
• Status
• Unified IR export data size increase
  • mdempsky@: I have plans for position compression. I might do just the function bodies since those dominate space and that won’t need the x/tools step. In the short term, I don’t know that there’s other stuff to do. Longer-term, thin export data or some larger-scale build restructuring.
• David’s GOGC boost CL
  • khr@: I’m happy with it. It’s ugly but safe. It depends on finalizers (being prompt).
  • mknyszek@: What directly solves this problem is a memory target, but that’s another GC knob.
  • mdempsky@: I agree with Keith. Some of the GOGC computations are kind of magic, so it would be nice if Michael or Austin could look it over. Alt: SetMemoryLimit until we reach that, then restore GOGC?
  • mknyszek@: The calculations look correct. SetMemoryLimit: if the live heap grows fast and the finalizer doesn’t run promptly, you could get into thrashing and slow things down. The risk of the GOGC approach if the finalizer is delayed is that the GC uses more memory.
  • mdempsky@: I think the target heap size David has is low enough that even if we overshoot significantly, it’s okay.
• PGO preview (cherryyz@)
  • Landed Uber’s compiler CL! Doing lots of improvements now and tuning heuristics. Doing benchmark measurements.
  • Considering switching from fixed percent threshold to a CDF threshold (this is what LLVM does).
  • Working on cmd/go changes. Not sure we’ll get to supporting multiple main packages. If we don’t get to that, default –pgo=off so you have to pass –pgo=auto explicitly (and only one main package).
  • Inlining testing?
    • mpratt@: With heavy inlining, something in the GC didn’t work and the compiler would hang. Maybe we should have a “heavyopt” builder just to stress the inliner (outside of PGO).
    • cherryyz@: We could introduce something like GOSSAHASH to do inline stressing. Useful for narrowing things down and debugging.
• Integration testing coverage (thanm@)
  • Fixed more bugs, did a little more cleanup. Writing documentation.
• Core project health (austin@)
  • Automated release process (relui)
  • Implementing new ports policy (iant@)
    • Just a couple of issues: Supporting building a cross-compile toolchain without using cgo (but that itself still defaults to using cgo). Add a list of broken ports to cmd/dist and refuse to build them by default.
    • cherryyz@: Timeline?
    • iant@: This release if possible, but not urgent.
  • Reduce builder maintenance toil (image management)
  • Test triage tooling (watchflakes)
  • Machine-readable all.bash output
  • Investigate alternate CI systems
  • [Deprioritized] Test artifact collection, submit queue
• Pacer changes (mknyszek@)

Attendees:

Cherry Mui David Chase Ian Lance Taylor Keith Randall Martin Möhrmann Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2022-11-08

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• David’s compiler GC hack landed
• big speedup in compile time, visible on performance tracker
• khr@: Would the same hack help the linker?
• mknyszek@: from looking at page trace, I think it might help a little, but not as much
• Do we have a geomean build time delta of master vs. 1.19 release across the benchmarks?
• https://perf.golang.org/search?q=upload%3A20221108.15+pkg%3Agolang.org%2Fx%2Fbenchmarks%2Fsweet%2Fbenchmarks%2Fgo-build+%7C+toolchain%3Abaseline+vs+toolchain%3Aexperiment
• Status
• Core project health (austin@)
  • Reduce builder maintenance toil (image management)
    • thanm@: Initial meeting with Jenny. Next step is to write a brainstorming/design doc.
  • Test triage tooling (watchflakes)
    • cherryyz@: Russ is running it somewhat continuously on his machine. CLs under review. Once those are in, Heschi wants to work with Russ on getting it running in the Cloud.
  • Machine-readable all.bash output
    • austin@: I’m pretty close to mailing out a big refactoring that should make this “easy”.
    • cherryyz@: watchflakes depends on the current output.
    • austin@: The existing dashboard endpoint will continue returning text output (translated from JSON stored in back-end).
  • Investigate alternate CI systems
    • mknyszek@: We’re moving forward with investigating LUCI more deeply. Gap analysis and prototype.
    • mpratt@: Working on moving Macs to AWS. We canceled MacStadium. We’re also talking to some google internal teams.
  • Deprioritized] Test artifact collection, submit queue
• Pacer changes (mknyszek@)
  • Landed today. It fixes a bug and simplifies the pacer, and the problems with it fixed themselves.
• Comparable: new proposal #56548
  • Already implemented behind a compiler flag
  • gri@: “Clear” proposal is likely to be accepted soon. The CL on the type-checker side is implemented. That could go in to 1.20 depending on how the proposal process goes.

Attendees:

Austin Clements Cherry Mui David Chase Eli Bendersky Ian Lance Taylor Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-01-03

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Happy New Year
• 1.20 Release blockers
• discussion of #54778 and #51550; still need more investigation here.
• Latest build time results (do we need to update release notes)?
• MichaelK: still trying to reproduce what we see on the dashboard on other machines
• problems with benchmarking on magna, but MichaelP was able to repro on workstation.
• Separate machine shows smaller (½) improvement than shown on dashboard
• David: new compiler may be using GOMAXPROCS, older compiler may be looking at ncpus(). This could account for diffs.
• MichaelK and David to collaborate on revised release notes wording
• VSCode HaTS responses on debugging
• many comments in open responses related to debugging
• not clear whether how much there is that C&R can help with, depending
• several mentions of calling functions from the debugger (assume this is about the limitations on calling functions getting in the way)
• a few mentions of better support for printing expressions, which might be about DWARF or might not.
• ThanM to discuss with delve team during checkin next week
• Cherry: there may be issues calling functions where an argument is escaped (debugger doesn’t know escapiness). We could add tags in the DWARF for this. Example: fmt.Printf. Could delve add special casing?
• David: can we come up with a helper function that would put something into the heap, so as to “heapify” things that are being passed to a func?
• Keith: may not be possible? What happens if called function wants to modify object pointed to by param?
• MichaelK: maybe allocate heap value, copy stack to heap, then copy heap back to stack on return? not perfect, but might be better than what we have now
• Cherry: interesting idea, but many potential pitfalls (especially if params are copied into globals, etc). maybe with a new special debugger mode (“unsafe call”)
• Keith: need to consider stack objects
• Keith: idea: delve already runs with flags to turn off optimization – could we turn off stack allocation entirely?
• Discussion of enterprise research survey
• Unified IR caused a regression in GoAWK: https://groups.google.com/g/golang-dev/c/8blU7CnuhZ4/m/d21xuN8hAQAJ
• Keith: threshold for “very large function” looks like the issue here; with unified the func in question is slightly bigger due to diffs in assignments for multi-return function calls. This results in lowering of the 'inlinable function' cost threshold, meaning that a number of key calls don't get inlined.
• may not need conversions in this specific case (might be something we could change in the compiler)
• proposal: bump up the magic number for large functions slightly to account for this case
• specific large function size number is probably not important
• Q: do we need an issue or bug here? A: Matthew will look into it, will file issue if needed
• David: RC2 is already “leaving the station”, might need an RC3 if it is decided this change needs to be included.

Attendees:

Cherry Mui David Chase Keith Randall Matthew Dempsky Michael Knyszek Robert Griesemer Than McIntosh

Comment From: thanm

2023-01-10

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Next "Public Go C&R office hours" session scheduled for Thursday, Jan 19 at 3 ET/12 PT
• discussion of whether/when we might need to implement a large data model (e.g. equivalent of GCC's "-mcmodel=large") for Go
• issue arises in some large Google-internal C/C++ programs that link in bits of Go code
• [Keith] For code it might not be that bad because we have trampolines on other archs. Data is still a problem.
• [Cherry] For C++ depending on Go, as long as Go (text) itself is < 2GB and we do access with GOT entries, we’re probably fine? Go code calling C is all function pointers, so maybe that’s also fine? There were a few issues with direct relocations, but we fixed those.
• 1.20 Release blockers
• We still have quite a few 1.20 non-release blockers
• Tree opening early for 1.21.
• Is there anything that needs to be submitted early?
• [Matthew]: Big stack for removing non-unified. Probably won’t conflict, so probably not urgent. Should we wait until we see the 1.20 release go out before removing that or just do it as soon as the tree opens?
• [Robert]: I have a stack I’d like to land
• discussion of shortened freeze (general outlook on it seems positive)
• [Matthew]: It seemed like we did a good job of getting the risky stuff in early and stabilizing the tree before the freeze rather than leaving stability work for the freeze.

Attendees:

Austin Clements Cherry Mui David Chase Ian Lance Taylor Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-01-17

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Discussion of team plans for first half of 2023, including items such as: dropping non-unified IR and removing associated GOEXPERIMENT, next steps for PGO, revamping the inliner, core health CI/CD tasks, batched write barriers, init ordering fixes, coverage trybots, long-term RAM efficiency efforts
• things are still in flux here, more work needed to produce a concrete plan

Attendees:

Austin Clements Cherry Mui David Chase Eli Bendersky Ian Lance Taylor Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-01-24

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Discussion about recent Google layoffs
• Discussion about whether to have the C&R team participate in the summer internship program
• [Robert]: We have a bunch of proposals (e.g., language changes like lightweight function literals) we’d like to play with/try out. An intern could write prototypes. We haven’t made much progress. If someone would implement those, maybe even as code rewriters, it would give us more insight into what it would look like in real code. And it might be useful for the community to see and drive decisions. It doesn’t require a particular outcome. It’s fun for an intern. And we’re not dependent on it. Requires some affinity to language stuff, and often/frequent communication.
• unsure whether this is going to happen however (schedule, etc)
• Discussion about dependencies in new Go features in 1.21-1.23
• we have a number of features with long dependency changes, e.g. in order for us to roll out X we need Y, and Y needs Z, etc.
• notable: issue #56986
• Main lasting impact on us: “Commit to always adding a GODEBUG setting for changes allowed by the compatibility guidelines but that nonetheless are likely to break a significant number of real programs.” and “Guarantee that GODEBUG settings last for at least 2 years (4 releases).”
• [Matthew] The current GODEBUGs are very specific things. Does this policy change that?
• [Austin] This is codifying that practice.
• [MichaelP] Do performance things count?
• [Austin] I’m not sure.
• [Cherry] regarding compatibility, how does this impact ares where we don't have the Go 1 compat guarantee (eg assembly code, odd things with "unsafe")?
• [Austin] don't think so
• [Cherry] What if old code doing weird things stops compiling? Is that okay? Maybe for assembly code?
• [Matthew] I think assembly is outside Go 1 compatibility.
• [Austin] “likely to break a significant number of real programs” is a judgment call
• [Ian] I agree it’s a judgment call. It’s intended for run-time changes where we change a package that makes it behave differently from how it did before. I would expect very few cases where the runtime package itself needs this. It’s not intended for performance. We could add one for performance, but it gives us more knobs to support.
• [Keith] If we’re doing this for k8s, we really need them to run the RCs and give us feedback. There are going to be things we change that we don’t realize they’re depending on.
• [Austin] I think they do run the RCs.
• [Matthew] They noticed issues with unified IR.
• proposal: extended forwards compatibility for Go #57001 is close to accepted
• At minimum, this will require the compiler to understand per-file language versions, not just per-package. (AFAIK, the details of whether the compiler or cmd/go figure out the versions aren’t fleshed out yet.)
• [Cherry] Do different versions of the language work together?
• [Robert] Say the loop variable capture change is in one file, and it gets inlined into another file. We have to track that.
• [Austin] We have to deal with that anyway for cross-package inlining.
• [Keith] There are (potential) changes we couldn’t do this way. Like, making int 64-bits everywhere.
• [Matthew] I have some similar concerns with per-file language, but I suspect it’ll work because we have to support per-package versions already. I’m not looking forward to the changes to go/types.
• [Ian] I don’t think it’ll be a big deal. It’ll mostly be “in order to use this new feature you have to use a language tag.”

Attendees:

Austin Clements Cherry Mui David Chase Eli Bendersky Ian Lance Taylor Keith Randall Matthew Dempsky Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-01-31

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• FYI
• Dropping non-unified IR looks like it improved build speed by another 1.5pp (these measurements are still relative to 1.19)
• 1.20 blog post is ready (thanks Robert!)
• go.dev/blog post sequence established for 1.20
• We now have a place for constants shared between the compiler and runtime: internal/abi
  • David and Austin are debating how to share types 🙂
  • [Matthew] I’ve been thinking of changing mkbuiltin to get definitions of runtime.
• discussion of schedule/logistsics for Go 1.21 first half of 2023
• discussion: redefining for loop variable semantics #56010
• proposal: cmd/compile: add GOEXPERIMENT=loopvar #57969
• For Go 1.21, we’re aiming to have the GOEXPERIMENT, which can have a whole-program effect. We don’t necessarily need to have the debugging integration (for finding code affected poorly by the change) ready until 1.22.
• [David]: I’m just chasing down final bugs and polishing at this point.
• discussion of plans for google-internal testing of this
• [David]: there is a concern about performance cost of not being selective in which loops are transformed -- a geomean application runtime slowdown of 5.8%.
• no slowdown if you only apply the change where it matters.
• Q: How much of this is that later optimizations just need to be aware of the new loops and how much is fundamental? (In the long run, can we drop the old loop semantics entirely?)
• [David]: The extra branchiness from 3-clause for loops interferes with BCE in prove. We could probably get rid of this.
• [Austin]: Last time I looked, induction variable detection was very pattern matchy and I could definitely see that breaking.
• [Keith]: I did recently make the detector better.
• discussion: user-defined iteration using range over func values #56413
• This is going to require somewhat fancy runtime integration and some help from the compiler. There are still some open questions on whether this is possible (and possible efficiently). Russ would like at least an implementation sketch in 1.21 if possible (can be during freeze).
• [Matthew]: I still have precise semantics concerns about push-based iterators. It puts users in the position of having to write runtime-y code. What sorts of assumptions can the compiler make about users actually writing code correctly? Also, the semantics of defer. The iterator call back opens up call/cc-type questions. What if users hold on to the closure and call it after they’re not supposed to? What if they call it from another goroutine?
• Also what do tracebacks look like?
• also panic propagation.
• [Matthew]: No concerns with pull-based iterators.
• security-related discussion

Attendees:

Austin Clements Cherry Mui David Chase Eli Bendersky Ian Lance Taylor Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-02-07

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Newly active proposals

• 56378

• Pragma has to assert something like “This C call cannot cause any data flow back into Go.”
• Is there any way to quantify how much this would actually let us not escape arguments to C functions?
• May become more important as we improve escape analysis.

• 58141

• Aligns with movement toward using wasm as an isolated plugin-like thing
• Current target is “WASI preview 1”, and the WASM group has already said preview 2 will break compatibility. But preview 2 is also years away. 🤷
• Does “preview 1” need to be in GOOS? Or a GOWASI environment?
• [Ian] GO$GOARCH things usually stack on each other. Is that true of GOOS?
• [Eli]: seems like a good proposal as long as someone else implements it. (Tiny Go supports wasi.)
• [MichaelP]: Once preview 2 comes out, how quickly are people going to switch? People will probably want both for a while.
• [Ian]: We do seem to switch quickly for FreeBSD.
• runtime.FuncForPC(runtime.Value(fn).Pointer()) woes
• People use this a lot for getting the name of a func that has not been called yet.
• Doesn’t work when the first instruction of a function is from an inlinee (Keith just sent fix for this)
• [Austin]: Should we just have a function that can give you the name of a function? runtime.FuncName?
• [Keith]: The reason to do that would be to deprecate FuncForPC. Do you think we can do that?
• [Austin]: I kind of hate all of our existing API that deals with raw PCs.
• [Keith]: This came up as a google-internal problem because the schedule change happened to put an inlined instruction at the beginning of a function. It seems to be used for metaprogramming. I fixed it by saying you can’t have an instruction from an inlinee as your first instruction (put a NOP if it happens).
• [Matthew]: FYI, for the inlining tree, there are still cases that get corrupted. We handle those today by pointing back at instruction 0. Until we fix #54625, we should probably prevent the first instruction from being an inlined function.
• Another option is FuncForPC could return the outermost function for the entry PC. That makes profiles be off.
• [Than]: Another problem is that people can get ABI wrappers from this and that makes them unhappy.
• Status
• Iterable proposals
  • [Ian]: Waiting for user “for range” loop stuff. Then rewrite an earlier proposal to use that syntax.
• Shallow/decoupled export design
  • [Matthew]: Writing up notes. Will need more feedback from cmd/go and x/tools.

Attendees:

Austin Clements David Chase Eli Bendersky Ian Lance Taylor Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-02-14

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Proposals
• proposal: cmd/compile: add GOEXPERIMENT=loopvar #57969 accepted
  • [Matthew]: Current version of implementation does a lot of IR rewriting, which is something that has traditionally been fragile. Fine for an experiment, but longer term there should be a better way to approach it.
  • [Ian]: The goal of the GOEXPERIMENT is to let people try it out on their own code.
  • [Matthew]: Do we want it to be sensitive to go.mod versions?
  • [Ian]: That would be fine, but is not a requirement.
  • [Matthew]: Current bisection happens after inlining, but I think it should be before inlining.
  • [Austin]: If the bisection is for us debugging the compiler, the extra context is useful. If it’s for users, it shouldn’t matter.
  • [Matthew]: When I’m minimizing test cases, it’s really annoying when that changes inlining decisions and that affects what I’m debugging.
  • [Keith]: It’ll find the buggy for loop either way.
  • [Matthew]: Answering “did my change fix it” is harder.
  • [David]: We can configure the bisection. Whatever we choose, it’s not hard to do.
  • [David]: Another question is whether the bisector should find just the first one, or all of them. If we had “all of them” we could use this to answer other questions about the compiler. E.g., detecting places we depend on overflow semantics.
• proposal: spec: define initialization order more precisely #57411 accepted
  • Keith has a 90% implementation. Doesn’t deal with weird build modes, but the main stuff is done.
• Deadlocked goroutine detection
• an enterprise user has been talking with Tim King about detecting deadlocked goroutines. They think they’re spending significant $ on memory held on to by deadlocked goroutines.
• Idea: Do a GC, but only treat running/runnable goroutines as roots (plus other usual roots). From there, trace to reachable concurrency objects and from there to goroutines those could unblock. Unmarked goroutines are deadlocked. (Austin’s thought: maybe this is just how the GC should work? ⇒ RAM efficiency + diagnostics)
• They are going to try to get hard data on how much this would actually save them. (Austin suggested prototyping using gocore)
• [David]: Does Go have the equivalent of wait and notify? If something is stuck on a notify, there’s no way to tell what will notify it.
• [Austin]: This is why this has to be integrated in the reachability.
• [Ian]: see https://go.dev/issue/19702
• [Keith]: If you GC goroutines, they’re not around for inspection later.
• [Austin]: The simplest threading-the-needle I can think of is you keep around the stack bytes, but don’t scan it. You can still traceback and look at locals.
• [MichaelK]: I think this works best as a gocore thing. You could imagine a fleetwide tool that takes core samples. A deadlocked goroutine is going to be deadlocked forever. You can run this off-the-shelf tool and get the information for very little overhead. I’m having a hard time believing there are millions in RAM held on by this. If so, maybe it makes sense to release memory. Otherwise, it seems like extra complexity that’s not worth it and gocore is perfect.
• [Martin]: The SRE in me doesn’t want to get this cleaned up so there’s more pressure for people to clean things up. If you make it easier to have wrong code, people will stay with the wrong code. Do we know if goroutines are “hard stuck”? E.g., they could make progress but the program logic just doesn’t allow it.
• [Ian]: If we actually implemented this, we could have a GODEBUG that says “any stuck goroutine panics”. That would be a quick way for people to find problems in their code and fix them.
• Status
• PGO GA: Scalable PGO builds
  • [MichaelP]: Started prototyping index file. Stuck on unrelated things.
• PGO GA: -pgo=auto by default
  • [Austin]: Russ thinks this should be easy and is happy to work with Cherry to do it.
• LUCI POC
  • [MichaelK]: We could try out structured all.bash. We’re planning on testing x/ repos with -json.
• Improved type inference
  • [Ian]: We have a proposal almost ready. Robert has implemented most of it. We’ll probably send out next week when he’s back.
• Inlining overhaul: Design
  • [Matthew]: Nothing new from me. Following up on release compiler bugs.
  • [Than]: Writing up a doc that describes the current state of the inliner. I’ll circulate that when it’s ready.
• Structured all.bash
  • [Austin]: Not ready yet. dmitshur@ has CLs to rewrite test/run.go as a Go test.
• Traceback iterator
  • [Austin]: I deleted gentraceback!

Attendees:

Austin Clements David Chase Ian Lance Taylor Keith Randall Martin Möhrmann Matthew Dempsky Michael Knyszek Michael Pratt Than McIntosh

Comment From: thanm

2023-02-21

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Discussion relating to shallow/decoupled export data to speed up tools (including google-internal tools)
• Go has ~8x more export data than other languages, relatively speaking. Makes analysis tools much heavier-weight.
• Gopls is switching to an independent tree of shallow export files
• [Matthew]: Still working on a doc. Tools probably want something like what gopls is switching to. x/tools packages to write out export data, which is what gopls is using (via internal/ APIs).
• [Austin]: Distributed builds with shallow export data?
• [Matthew]: bazel has some support for input pruning. Rule lists all possible inputs and can say after the fact what was actually used and that goes into rebuilds.
• [Austin] I think this can only avoid unnecessary rebuilds. I don’t think it can avoid shipping all of the inputs if it does have to rebuild?
• [Than]: Do we know which parts of the export data are "too big"? Or is the reader just taking too long to read them? What fraction is inline bodies vs types?
• [Matthew]: I think inline bodies are a big part of it, and they pull in more transitive type information. Also, the go/types APIs don’t support lazy loading. In the compiler, only the types that are needed get loaded into the type checker.
• Discussion of revisiting default link mode for cgo std packages.
• related bugs: #58619 and #58620
• Cherry: “... now if user doesn't have a C compiler, they will get non-cgo std packages; if they have a C compiler, they can get cgo-enabled std packages but they can use external linking anyway. So maybe we should default to external linking with cgo even for the std packages?”
• [Ian] making this switch could impact build speed. Right now if you import “net” on Linux, you’ll normally being using a cgo-compiled object, and the Go linker knows enough to link that without the host linker.
• [Austin] Russ thinks we should try doing external linking more of the time.
• [Ian]: It would be nice if we could combine that with the same fix for Linux that Russ did for Darwin where we don’t need to invoke the C compiler at all for the net package.
• [Cherry]: On Linux if you use C libraries at all, you have to work with pthread and that was complicated. On Darwin you just say “I need pthread_create from libSystem or whatever”. On Linux it’s something more complicated.
• [Cherry]: For build speed to be impacted, the user needs A) a reasonable amount of code and B) the only C code in the whole program is the net package, which you can argue doesn't happen that often?
• [Cherry]: I think there is some room to improve the linking speed for external linking, but it will always be slower because you have to shell out to another program.
• [Cherry]: MacOS -race isn’t a problem. It doesn’t import C at all, it’s all just references.
• [Than]: Did we consider using *.syso’s for net?
• [Ian]: We never had to because we always just built it with cgo.
• [Ian]: If you build a binary on Linux, it needs to do the library versioning thing.

Attendees:

Austin Clements Cherry Mui David Chase Ian Lance Taylor Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-02-28

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Using internal linking less
• discussion of whether/how to reduce use of internal linking for CGO
• internal linking is always a net win from link time perspective, and users want to continue to have short link time, but since moving away from shipping precompiled *.a files, we're running into more situations where user programs that import "net" or "os/user" trigger linker problems due to C compiler flags/features/constructs that the linker doesn't grok (examples: #58619, #58620)
• [Cherry]: We still need to use internal linking for syso files, which are not especially simpler. The problem we want to solve is that the linker only knows how to handle certain things, and people may pass weird C compiler flags or their compiler may do weird things. There are other ways to deal with that.
• [Than] Supporting internal linking leads to a steady drip of things we need to change in the linker as host C compilers evolve. It would be great to reduce that as much as we can. But it would be wonderful if we could do flag filtering or something to reduce that stream.
• [Keith]: Can’t our linker report that it sees something it can’t handle and then the Go command fires up the external linker?
• [Cherry]: We could do that. The linker itself can exec the external linker with cmd/go. The downside would be reading the external .o files twice, once to see if we can handle them, and then again to actually process them. Once we load them into the symbol table, it’s complicated to “unload” them.
• [Than]: May also be hard sometimes to tell the difference between "internal linking failed due to weird host object" and "internal linking failed due to Go linker bug"
• [Austin]: How reliably can the Go linker report that it can’t handle something?
• [Cherry]: I think it’s pretty good.
• [Cherry]: Do we want to make the linker do a pre-scan, or just fall back to external linking if we see flags we don’t understand?
• [Austin]: Do we look at flags today?
• [Cherry]: We don’t. There are so many ways to set flags. Maybe the cgo command can tell us.
• [Ian]: The go command does look at the compiler flags to only permit flags it thinks are safe (specifically, not compiler plugins).
• summary: internal linking is going to stay around, but hopefully we can come up with some way to handle weird host objects, e.g. make the linker better at dynamically detecting when it needs to externally link, either through flag scrubbing or pre-scanning
• team planning discussion for 2023 objectives/goals
• discussion of how much performance improvement we expect to deliver from upcoming projects such as PGO, overhaul from inliner, etc
• for PGO, we'd been planning that the immediate priorities are -pgo=auto by default, build scalability impact, and diagnostics, over more PGO-based optimizations, but maybe it's not enticing enough without more performance improvement. -pgo=auto by default is a hard requirement, but maybe the next priority should be getting PGO over 5%.
• [Keith]: I agree build speed isn’t that important if people are building with PGO.
• [Austin]: more worried about scalability issues
• [MichaelP]: in some corner cases it can triple or quadruple your build time; we don't have a lot of detailed data on the slowdowns yet
• [Austin]: The danger is people will try it in 1.21 and find the build speed is untenable and back off. But we can recover from that through clear communication.
• [David] Build speed is not what people care most about according to the recent surveys.
• [MichaelP]: If we GA -pgo=auto by default, more people will be exposed to PGO. Though it’s only for binaries, not libraries.
• [Austin]: I’m not too worried about that because you can just delete the profile if the impact is too high.
• [MichaelK]: I'm not sure users really care much about build scalability until something falls over, so I suspect it's harder to ask about.
• [David]: How much does PGO help the compiler itself?
• [Cherry]: about 4.5% at last measurement.

Attendees:

Austin Clements Carlos Amedee Cherry Mui David Chase Dmitri Shuraylov Eli Bendersky Ian Lance Taylor Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-03-07

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Go performance on arm64
  • Context: google-internal experimental study running workloads on arm64, points out some places where the Go compiler could do better
  • We’re really bad about writing things to the stack and then immediately reading them back (and then sometimes writing back to somewhere else on the stack) and it seems ARM machines are less forgiving of this.
    • [MichaelP]: I’ve been experimenting with marking regalloc “overhead” instructions. That might be useful here, too.
  • arm64 branch predictor apparently not as strong as amd64, so it’s more sensitive to block layout and we’re not great at putting hot blocks in fall-through order.
    • Maybe CL 418555 (improve basic block layout) would help for arm64? It didn’t help much on amd64, and cost ~2% in binary size.
  • [MichaelP]: Do they have specific benchmark targets?
  • [MichaelK]: would it help to spin up an ARM64 performance builder? In theory all of the benchmarks should work. The dashboard would need to learn architectures.
  • Also a non-ARM-specific inlining bug related to our heuristics for re-exporting inline bodies (which shallow export data would fix).
• Status
  • PGO GA: -pgo=auto by default
    • Multiple main packages work now. We just need to flip the default
  • PGO GA: 5% performance gain
    • [MichaelP]: Prototyping in regalloc. Uber is making progress on devirt, but it’s not clear how close they are.
  • LUCI POC
    • We keep adding functionality. So far things are looking “pretty good”. Pushing some functionality to after the go/no-go decision.
  • Iterable proposals
    • [Ian]: It doesn’t look like “for range” will settle until 1.22.
  • Improved type inference
    • [Ian]: “It’s much better.” We’ve agreed on our approach.
    • [Robert]: Code is much simpler and clearer and I fixed several bugs.
    • [Ian]: We don’t have a spec yet.
  • Structured all.bash
    • test/run.go is now a normal Go test
  • ARM64 assembler
    • [Cherry]: The CL is fine. The next step is for CL authors to write the code generator that turns their XML into the instruction table. Not blocked on us right now.
  • Traceback iterator
    • [Austin]: Rewrite is complete. Test coverage is actually pretty good (yay runtime coverage!). Dealing with performance regression that appears to be from bad code gen (#58905 and an issue with returning medium-sized structs)
    • [Cherry]: I tried an optimization that will remove some of the copies.
  • David's aligned/atomic slices/string/interface work:
    • Len/cap swap and 16-byte aligned slices, strings, and interfaces: space (RSS +2%, VM +1%, tile38p50 +2%, tile38p90 -1.7%, tile38p99 -4.9%) and time (geomean +1.5%)

Attendees:

Austin Clements Carlos Amedee Cherry Mui Eli Bendersky Ian Lance Taylor Keith Randall Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-03-14

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• First PGO result from a google-internal app yields -2.75% CPU 🎉
• used manually collected LBR profile converted to pprof
• PII in PGO profiles
• enterprise users possible concern about PII in profiles. Google doesn’t seem to think it’s a problem.
• [MichaelP]: Most of these concerns seemed to be coming from folks who hadn’t thought about it at all. Umbrella concern about bringing any data back from prod.
• [Austin]: It seems like the only solution to that is each company has to do their own privacy review.
• [MichaelP]: We could provide a tool to strip PII...? Maybe aggregation is enough?
• [Keith]: Would it help to tell people that Google does this all the time?
• [Austin]: considering reaching out to other google-internal folks on this, to find out how we arrived at our privacy position on continuous profiling
• [Cherry]: concerns seemed to be that they didn’t know what was in the profile. Maybe we just need to explain exactly what’s in there. And if google-internal uses of profiling for PGO went through privacy review, maybe we could use similar language.
• [Austin]: Such a doc would be useful if companies do need to do their own privacy review.
• [MichaelK]: just don’t see how you get PII into a profile. Everything going into it is just coming from the binary.
• [Austin]: You certainly can exfiltrate data in a profile if you try.
• [MichaelP]: Canonical example might be the presence (or relative hotness) of functions that give hints about what data is being processed. Example: “Render English/German/Spanish” functions. Now you can get frequency breakdown. I think it’s still a stretch.
• [MichaelP]: Several people on the EAB felt better when we communicated there’s no argument data in the profile.
• [Than]: Definitely emphasize to customers that we’re not putting anything special in the profile. And also that you can just look at the profile and see what’s in there.
• [Cherry]: Their concern isn’t just checking files into the build system, it’s extracting any data from prod. If we document what’s in the profile, and later want to extend what’s in the profile, that’s a hurdle.
• [MichaelK]: If they can’t get things back from prod, how do they debug things?
• [MichaelP]: At least one user told us they don’t profile in production just because they don’t let people connect to production and they don’t have continuous profiling.
• PGO ease of use
• [Austin]: We could make continuous profiling easier.
• [MichaelP]: +1. My impression is that the biggest challenge for continuous profiling is the remote collection of profiles, which feels like something we can’t do a lot about.
• Cgo, external linking, and weird flags
• rash of issues filed recently with common theme: building a Go program that depends on cgo-using stdlib packages (e.g. net, os/user), but with CGO_CFLAGS set to some unusual flag, results in link failure (internal linker doesn't understand resulting host objects due to flags)
• Where we are: do internal linking of std unless there are C flags we don’t support
• Are we happy with where we landed on inspecting the C compiler flags? CL 475375
  • [Than]: so far so good, ask again in a week
  • [Than]: There’s already been a request to back-port this [just switch to external linking if there are flags we don’t support] to 1.20. It’s a change to both the linker and cmd/go, so it’s not totally risk-free.
• Status
• PGO GA: -pgo=auto by default
• waiting on code review from tools folks
• [Cherry]: CL ran into some issues I don’t quite understand. Asking Bryan to help with debugging. Otherwise in good shape.
• PGO GA: 5% performance gain
  • [MichaelP]: Prototyping regalloc. Nothing too notable yet. Uber will in theory be sending their prototype for PGO devirt to us this week.
• Loop variable scoping GOEXP
• CL 472355 needs review
• Structured all.bash
• [Austin]: Going to return to this now that traceback iterator is in
• RAM efficiency prototyping
• Interest from David, Michael K (after wrapping up diagnostics)
• Traceback iterator
• [Austin]: Done! Fun follow-up: print bottom 50 frames of deep stacks
• Slice reorg/alignment work
• Status of 16-byte load/store?
• [Keith]: I have a CL for strings. It would be straightforward to also do for slices and interfaces.
• No meeting next week (Go quiet week)

Attendees:

Austin Clements Carlos Amedee Cherry Mui Eli Bendersky Ian Lance Taylor Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2023-03-28

• FYI
• proposal: all: add GOOS=wasip1 GOARCH=wasm port #58141 accepted
• proposal: use a zero for third digit for major release, such as 'go1.23.0' #57631 accepted
• Russ is starting to ask publicly if we should drop Plan 9
  • Making Plan 9 “out of tree” would be ideal, except we don’t really have a way to do that.
  • There are two amd64 versions of Plan 9, and the one we have a builder for is the less-maintained one.
• Optimization guide
  • Austin’s thoughts
    • Give a high level mental model of how Go code executes. Try to avoid details that are likely to be fragile, and be clear that this area is always evolving.
    • How data structures work. E.g., slices and maps are reference data structures, so passing them is O(1) and you don’t have to pass a pointer to a slice or a map.
    • How to use performance tools. Flow chart of performance evaluation (writing this might help us improve the tools, too 🙂). Don’t prematurely optimize, but keep the basic execution model in mind so don’t have an even layer of performance problems spread across your code.
    • Model of escape analysis to avoid allocations.
    • Export some of our philosophy, e.g., fast/slow path patterns for inlining
  • [MichaelK]: The GC guide takes a stab at this.
  • [MichaelK]: Should we merge the GC optimization guide into whatever new thing we make?
  • [MichaelK]: Should we use this opportunity to merge other scattered sources, like the Wiki pages?
    • https://github.com/golang/go/wiki/Performance (Go developer performance guide by Dmitry); out of date, but it’s a starting point.
    • https://github.com/golang/go/wiki/CompilerOptimizations
    • https://github.com/golang/go/wiki/SliceTricks (maybe?)
    • https://github.com/golang/go/wiki/BoundingResourceUse
    • https://go.dev/doc/diagnostics
  • [Ian]: Should we also be thinking about a debugging guide? We have a bunch of different docs, but nothing unified.
    • [Keith]: That depends a lot on your IDE
  • [MichaelK]: As we work on tracing/etc, I plan to have a guide on how to use those tools.
  • [MichaelK]: I got feedback on the GC guide that people really just want “performance tips”, not a “mental model.”
  • [MichaelP]: “My program is slow and I need to fix it before my deadline.” Talk about the tools a lot and how to use them. That gives people actionable things.
  • [Austin]: Flow chart.
  • [Keith]: Another thing that would be nice about having a guide is that there’s all kinds of misinformation/anecdotes out there. It’s not necessarily something people would read, but something we could point them to.
• Status
• PGO GA: -pgo=auto by default
  • Done!
• PGO GA: 5% performance gain
  • [MichaelP]: Working on some experiments. Nothing to send out yet. I found lots of interesting problems with regalloc, but fixing individual ones hasn’t made a big difference.
• Improved type inference
  • [Ian]: We have a proposal (incoming to committee). Robert has implemented it. It’s basically the same as the old type inference, but a new perspective on it. We’re also working on new forms of type inference, which will need a proposal: able to infer type arguments based on assignment.
• Inlining overhaul: Design
  • [Matthew]: Than and I had a meeting to discuss and start on a design doc.
• ARM64 assembler
  • [Cherry]: CL hasn’t been updated since last time.
• init ordering fix
  • issues with flags.Set and code that relies on specific order
  • [Keith]: work needed to clean up google-internal codebase here
  • [Austin]: Can a vet check or API change do anything about this?
    • [Keith]: Existing code will still break with an API change.

Attendees:

Austin Clements Carlos Amedee Cherry Mui Eli Bendersky Ian Lance Taylor Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Than McIntosh

Comment From: thanm

2023-04-04

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• FYI
• Friction fixit announced for April 17–21.
• Reminder: H1 team summit scheduled for April 25–27.
• Minor releases went out today!
• discussion of google-internal bugs relating to health-check failures for some large Go applications
• Status
• PGO GA: 5% performance gain
  • [MichaelP]: Still working on various prototypes of PGO stuff and just general performance. Have a CL to send out for PGO. Right now we increase the budget for inlining, but we don't limit the budget if the function is big. Oversight, we didn't intend this. Adding that limit back in gives us back 0.5%.
• Loop variable scoping GOEXP
  • [David]: GOEXPERIMENT is all in. Cleaned up a bunch of things, brought back an optimization. Improved the automated loop finder but we need to decide what to do with it for release. Currently just sitting there.
  • [Michael]: what needs to happen next?
  • [David]: The question is what the interface should be. Down to the CLI. How chatty should it be?
• Improved type inference
  • [Ian]: Proposal's in the review committee. Robert sent out another proposal for type inference. Probably for 1.21. Infers assignment of a generic function to a variable whose type is known. Useful for function calls. https://go.dev/issue/59338
• ARM64 assembler
  • [Cherry]: more CLs have been sent in, unclear what the plan is with the new stuff or how it relates to the refactoring. Will ask the ARM folks what they plan to do.
• watchflakes
  • [Cherry]: Made some improvements, works relatively well now. Not productionized yet.
• Init ordering fix
  • [Than]: blocked on some google-internal changes. Waiting on for google-internal team to give the all clear.

Attendees:

Carlos Amedee Cherry Mui David Chase Dmitri Shuraylov Ian Lance Taylor Matthew Dempsky Michael Knyszek Michael Pratt Than McIntosh

Comment From: thanm

2023-04-18

• FYI
• Accepted: all: add opt-in transparent telemetry to Go toolchain #58894
• Accepted: spec: a general approach to type inference #58650
  • [Ian]: It’s exactly the same as what we had before. Just a better way of thinking about it.
  • [Robert]: And a much cleaner implementation. Implementation complete and landed.
  • [Robert]: Another active proposal: inference of type arguments for functions you’re passing to another function, or assigning, or returning. Any time you’re assigning, you get “reverse” inference. Likely accept, and close to a complete implementation.
• Accepted: runtime: use WER for GOTRACEBACK=wer on Windows #57441
• all: add GOOS=wasip1 GOARCH=wasm port #58141 is kind of working already
• Newly active proposal: unsafe: allow conversion of uintptr to unsafe.Pointer when it points to non-Go memory #58625
• discussion of some performance profiles of the Go linker when linking google-internal programs (may be some speedup opportunities)
• Discussion thread
• ~1 month 'til the freeze.
• Active issues
  • problems with additional closure inlining
    • [Than] all.bash has been pretty inadequate for detecting problems in this; pattern lately has been builders+trybots to pass, but things still fail for google internal apps
  • [MichaelP] working on a google-internal problem that seems to be scheduler related. The task is getting stuck for a long time.
  • [MichaelP] also working another issue related to long GC pauses in another google-internal app. Maybe CPU throttling?
    • [MichaelK] The current theory is that a thread holding a sync.Mutex is getting throttled, causing contention metrics in lock profiles to rise.
  • [MichaelP] Keeping M with cgo threads is on its second revert now. The new problem is TSAN thinks there’s a race in runtime C code because it doesn’t see synchronization that happens in Go code. (I’m 90% sure there isn’t a real race.)
• Loop variable scoping GOEXPERIMENT #57969
  • Compiler status? Tooling/ecosystem status?
    • [David]: Compiler is done. But we’re not banging hard on the experiment. For the tooling (which can be done partly during the freeze), we have all the parts, but the packaging is up to snuff. We have hash searching. Some people worry this change will be bad for them, either in performance or semantics. We have a thing that matches compiler optimizer logging with performance data (we might need to tweak optimizer logging a bit).
    • [Austin]: Is this going to need IDE integration?
    • [David]: Not sure how bug finder would fit in
    • [Matthew]: Is the bug finder something IDEs could just integrate into however they normally run tests or user commands?
    • [David]: The hash search does work very much like a “go test” wrapper.
• PGO
  • Pprof proposal: add Discriminator field to Line message https://github.com/google/pprof/issues/768
  • Uber CL http://go.dev/cl/484838 to do PGO-based indirect call specialization (thanks mdempsky@ for making a pass)
    • [Matthew]: One limitation was that it looks like they’re trying to rewrite whole statements rather than reaching into expressions. I think we could do it in a cleaner, more general way.
  • Not a lot of progress on reaching 5% 🙁

Attendees:

Carlos Amedee Austin Clements Cherry Mui David Chase Dmitri Shuraylov Eli Bendersky Ian Lance Taylor Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-05-02

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• [Note: no meeting last week due to Go team internal summit]
• Active issues
• Additional closure inlining (original CL https://go.dev/cl/482356 , since rolled back a couple of times)
  • Is this worth fixing at this point if we’re going to rewrite the inliner?
  • [Than]: It’s making the inliner behave in a more rational way and it’s better to make the inliner less weird, even if we’re rewriting the inliner.
  • [Than]: current blocker is definitely a problem with escape analysis
  • Matthew and/or Cherry can help look
• issue #55160
  • mayMoreStack instrumentation is added in obj.
  • perhaps David can run a GOSSAHASH bisection.
• Status
• PGO 5%
  • [MichaelP] working through through Uber’s specialization CL. I’ve rewritten most of it at this point. It should apply a lot more now.
• Loop variable scoping
  • [David] Compiler work is done.
  • David and Russ working on user bisection tooling. Might need some improvements to compiler diagnostic output.
  • For 1.22: need to key off -lang version
  • [David]: already works with cross-package inlining (you can turn it on with a -gcflag)
• LUCI POC
  • We made the “go” decision on LUCI at the summit.
  • [MichaelK]: We’re focusing on pre-submit first.
• Improved type inference algorithm
  • [Robert]: Spec work needs to be done (probably during the freeze). Ian and I have some idea how to describe it. Still some work on implementation: Today we can’t pass a partially instantiated generic function to another function f(g[T]) where g is g[T,U] and U can be inferred, but I don’t think that’s a show-stopper.
• Inlining overhaul: Design
  • Than still working on closures inlining bug; Matthew has been busy with PGO and helping with type inference.
• Structured all.bash
  • [MichaelK]: The sooner we get this, the easier LUCI test sharding/merging will be. We’re already using -json for the subrepos.
• ARM64 assembler
  • [Cherry]: No updates from contributor, things may be stalled
• watchflakes improvements
  • [Austin] Given LUCI, what’s the future of watchflakes?
  • [Michael]: We should look at the gaps between LUCI Analysis and watchflakes. LUCI Analysis doesn’t integrate at all with GitHub issues, but maybe that doesn’t matter because it has its own UI? We might be able to add GitHub integration.
  • [Cherry]: There are a few things I still want to improve. E.g., subrepos.
• Pinner
  • [MichaelK]: CL looks good and just needs a lot more commenting. There are a lot of almost races that are okay if you do them in the right way. Seems on track to land for 1.21.

Attendees:

Carlos Amedee Austin Clements Cherry Mui David Chase Ian Lance Taylor Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-05-30

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• AIs from last week
• init ordering spec update
  • Robert to work on this
• compiler error URLs
  • Carlos + Robert: plan is to delay error URLs until 1.22
  • discussed with Russ, who feels that we should have one page per category of error (rather than for each really specific error)
  • code is in for 1.21 but just flagged off
• Reverse type inference
  • [Robert] spec change work for reverse type inference underway
  • [Robert] Also made another proposal for a separate inference enhancement (interface-common-methods). In proposal “active” now. Hopefully it will move to likely accept this week and then accept next week.
• Please write release notes!
• PGO and PGO-devirt underway
• needm change underway
• GOEXPERIMENT=loopvar and bisect command
  • Russ to write?
• various type inference changes (Robert to write)
• Discussion of SCCP, its utility and relation to the prove pass
• [Keith:] CL for it went in, there was a silly problem, new CL will go into 1.22.
• [Keith:] An example where SCCP helps where prove does not:
  • You allocate a constant-size, constant-cap slice of 0 bytes.
  • You append a bunch of constant-sized slices.
  • It eliminates the first growslice, then the phi on the cap, and then that lets it eliminate the next growslice, etc.
  • prove can do the first one, but not the rest because it doesn’t do dead code elimination while doing prove.
  • SCCP is somewhat redundant with prove, it has a niche where it’s useful.
  • also seems pretty cheap to run when it doesn’t find optimizations.
• [Cherry]: What does prove do that SCCP doesn’t?
  • [Keith]: Iteration variable in-range stuff. SCCP only does constants.
• Should we move runtime to internal/runtime so things like reflect and sync can just call functions in it rather than linkname’ing? This would propagate escape information and allow inlining.
• [David]: I think it would improve the type refactoring. There are places where I stopped because I would have had to add more linknames.
• [Keith] The runtime package would have trampolines into the internal APIs. That would require more inlining, but that’s fine.
• [Austin]: A lot of the exported API isn’t called by runtime itself, so it could stay in runtime just like it is now.
• [MichaelP]: There are very few exported APIs in runtime that are performance-sensitive.
• [Matthew]: A lot of external users will complain about linknames breaking.
• [MichaelP]: git rebase handles renames pretty well.
• [Austin]: This is the sort of thing we’d do during early tree open.
• [Austin]: We’d have to leave some symbol names alone. E.g., enter/exitsyscall are linknamed out to x/sys.
• [Austin]: It would affect symbol names in tracebacks. That might increase binary size.
• [Austin]: It’ll cause churn. Is it worth it?
  • [David]: I’m in favor
  • [Cherry]: I’m in favor. I can remove all the weird escape tags from reflect.
• PGO PPC compiler bug is still at large
• [David] this is not an easy bug to work on
• Closure symbol naming
• [Matthew]: I’m pretty confident we can just reuse the underlying closure definition. I’ve thought about the ways we could optimize them differently.
• [Austin]: out of time, let's talk more about this next meeting

Carlos Amedee Austin Clements Cherry Mui David Chase Keith Randall Matthew Dempsky Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-06-27

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Nice improvement to link time and RAM from Cherry’s recently landed changes (approx May 2). Numbers: Frontend Kubelet, similar numbers seen for google internal applications.
• Release items
• Review of release-blocking and non-release-blocking Go 1.21 issues.
• Review of pending 1.21 blog posts
  • Type inference improvements
  • Loop var semantics change experiment
  • slog
  • wasip1 target
  • PGO GA (can be a short announcement)
  • Backward/forward compatibility
• Discussion: should we submit CL 503795 for 1.21, the s==s optimization that helps generic string sort?
  • No. Target 1.22.
• [Robert] spec changes in the works.
• LUCI
• [Eli]: Heschi feels this isn’t moving along quickly enough. If people have cycles to contribute before EOY, that would help.
• ARM64 assembler
• [Cherry] They just sent a HUGE CL. So things are happening it looks like.
• watchflakes improvements
• [Cherry]: Basically done. Just “bugs” at this point.
• watchflakes: move to cloud
• [Cherry] future of this is unclear with LUCI
• Explore MacService integration
• [MichaelP]: They’re started on this.
• [MichaelK]: We may end up using ChromeLabs Macs.
• SwissTable
• [MichaelP]: Google3 may want to do some benchmarking on this. Maps are used heavily in google3. This may be of value to us.
• So this may be worth investing in.
• Planning H2 scratch
• Go Core planning 2023
  • Aim to accept iterator proposal in time for 1.22
    • [Ian]: We want to get user for range loops in first. If that goes in, we’ll do an updated iterator proposal.
  • Consider landing x/exp/slices (and maybe maps too?) in stdlib
    • Done in 1.21.
• PGO devirt follow-up
• min/max codegen optimization
• 5% performance improvement
• [MichaelK]: Some things just aren’t going to benefit as much from PGO.
• [MichaelP]: About half of Sweet benchmarks basically don’t use indirect calls, so devirt doesn’t help those.

Comment From: thanm

2023-10-24

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Go Team Summit (Google-internal) took place last week; lots of good information exchange
• we are now <1 month before freeze (freeze begins Nov. 21)
• Likely accepted proposal: spec: add range over int, range over func #61405
• Specifically, range-over-int for 1.22, and range-over-func behind GOEXPERIMENT=rangefunc for 1.22.
• proposal: testing: add Keep, to force evaluation in benchmarks #61179
• On hold pending a prototype implementation in the compiler.
• Keith: Anyone working on the prototype?
• MichaelK: it is on hold anyway so probably too late for 1.22. We have plenty of time for 1.23.
• Keith: it is possible to just add testing.Keep without any compiler changes. Downside is people may add testing.Keep in too many places.
• MichaelK: should it be two proposals? One for adding testing.Keep, one for auto-Keep. ?
• Keith(AI): post on the issue to clarify.
• Discussion of google-internal applications
• MichaelK: still working on tracer.
• Close to production ready, one issue with cgo.
• goal is to land in 1.22 behind a GOEXPERIMENT, maybe on by default.
• Already test against Sweet, works well.
• Do we want to look over “os: make use of pidfd for linux #62654”
• Michael Pratt will review CLs.
• There is a new Linux API to query the process status without race. The CLs are going to use that.
• Range-over-func tasks
• Change GOEXPERIMENT name to “rangefunc”
• Yield checking
• Named result details
  • Matthew: when a return statement updates named result values. There is a straightforward solution and we should do that.
• David: is Russ doing this, or is Russ busy?
• Cherry: how much of this needs to be in for 1.22?
• Matthew: I will handle the named result details.
• Q: range-over-int fully implemented?
• Matthew: believe it is done, will double check. go/types support is also done. Maybe go/ssa needs support.
• Matthew: currently behind GOEXPERIMENT=range. Will make it on by default.
• Keith: I have a CL to change GC work buffers from gray to white. Work buffer will mean "to be marked and scanned". The benefit will be save a lookup.
• David: will this cause more things in the work buffer?
• Keith: yes
• MichaelK: Austin tried something like this a while back and it is somewhat a wash?

Attendees:

Cherry Mui David Chase Eli Bendersky Matthew Dempsky Michael Knyszek Michael Pratt Than McIntosh

Comment From: thanm

2023-10-31

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Happy Halloween
• FYI
• Likely accepted proposal: unique: new package with unique.Handle #62483
• Likely accepted proposal: all: add GORISCV64 environment variable #61476
  • add GORISCV64=rva20u64,rva22u64,rva23u64, not emitting C instructions until dust settles
• Range-over-int and range-over-func
• proposal accepted
• Change GOEXPERIMENT name to “rangefunc”, bring range-over-int out of experiment (Cherry to look into this)
• Yield checking for range-over-func (David to look into this)
• Spec change of range-over-int (Robert to look into this)
• Status
• PGO
  • Michael Pratt: Prototype for function value devirt. Have it implemented, will send it out. Delayed by LUCI work but going fairly well.
  • Scalable builds: CL from Uber that adds a new command to do preprocessing for ingestion by the go command. Might not get around to landing integration of that for Go 1.22.
  • Method devirt CLs are already in, got 0.5% of performance gain.
  • No numbers yet for function value devirt. The prototype has a bunch of limitations.
• Loop scoping
  • David: Talked to Tim King, working on getting the SSA semantics right in the downstream ssa package. Should that happen before the freeze?
  • Cherry: Maybe doesn't need to be, but pending proposals for go/types and the new go/versions package.
  • Robert: go/types proposal expected to be accepted soon. Needs prose in the spec, I'll work on it.
• Inlining
  • Than McIntosh: Working on tuning the score adjustments to try and improve performance numbers.
  • Ran compilebench over the weekend with the new inliner. The compile time has gotten a good deal worse from new heuristics. Slowdown due to heavy use of ir.StaticValue in new heuristics. Looking at a more efficient replacement.
  • Cherry Mui: What does ir.StaticValue do?
  • Than McIntosh: detects cases where you assign a local variable "x := 1", then never re-assign "x". In such cases if the RHS is invariant, you can then substitute in the RHS where you see uses of the var.
  • Keith: There's probably a flag on variables on whether it has been reassigned. That might help to avoid recomputation.
  • Than McIntosh: concern for the flag is that it could get stale
  • Matthew: Main complexity we've had is that if we insert new IR concepts during inlining, we make changes that could affect StaticValue. So we do a failsafe that checks all the conditions again to make sure everything makes sense. It should be possible to track that more strictly to avoid the checks.
  • Any risk for finishing new inliner before Go 1.22? Are you considering downscoping?
  • Than McIntosh: Doesn't make sense to enable experiment in current state. Still needs work. Compile times are too high and the runtime improvement is too low. 1-2% improvement. Compile time is up 8-9%. For the compiler's SSA package it's 23% slower. The slowdown is mostly not due to additional inlines, but heuristic computation. Pessimistic that we'll ship anything for Go 1.22.
• Matthew Dempsky: If hypothetically StaticValue didn't have any overhead, would we be good to ship? We should be able to speed it up. If that's what's keeping us from landing a 1-2% improvement then maybe we can just fix it.
• Than McIntosh: We'll have to check.
• Matthew Dempsky: Working on inliner scheduling; should have CLs soon. Don't know what the performance impact of this will be. Filippo seems to believe it'll have a high impact.
• Tracer work
• Michael Knyszek: in good shape, last corner case is cgo callbacks. Getting Michael Pratt's review. Blocked on cmd/trace update, Felix from DataDog is working on cmd/trace integration. Michael Knyszek as a backup. On track for on by default in 1.22.
• Allocation headers CLs
• Michael Knyszek: support arenas now, behind a GOEXPERIMENT. Cherry Mui and Keith Randall are reviewing. A concern is that as the header is at the beginning of the allocation, shifting the allocated pointer by 8 bytes. So now allocation is not 16-byte aligned; unsure whether that is a concern or to what degree.

Attendees:

Carlos Amedee Cherry Mui David Chase Eli Bendersky Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-11-07

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Discussion of Keith's demo on faster type switches and asserts
• Keith considering about doing some version of the talk for Gophercon
• Than: did you use any other benchmarks?
• Keith: no. Other benchmarks don't use much type switches.
• FYI
• Likely accepted proposal: cmd/compile: create GOARCH=wasm32 #63131
  • this is adding a new GOARCH, not changing the current GOARCH=wasm
  • there is a 64-bit wasm VM, probably not widely used
  • this is proposed by the WASI folks
  • Matthew: sandboxing 32-bit programs may be easier
• Likely accepted proposal: sync/atomic: add Uint64Pair #61236
  • MichaelK: is this 16-byte aligned? e.g. "the compiler and toolchain will provide the necessary alignment automatically"
  • Matthew: pad the type size to at least 32 bytes?
  • MichaelK: the allocation headers will break it (16-byte aligned for object >= 32 bytes), unless it is noscan
  • Matthew: need type checker support. As we do more and more aligned types, it may be a good idea to revisit how we do alignments
  • Cherry: SGTM. also as we may do SIMD in the future
  • Keith: the stack is not aligned, so need to escape to the heap
  • MichaelK: we should consider to do the AlignedTo types, soon. Or user would do "_ [0]atomic.Uint64Pair". If there is already a way, may give user a better way to specify it.
  • Cherry: for only atomics, it may not matter much for stack locals, as long as the instruction doesn't fault
• 1.22 stuff
• Robert: a fun CL 539299, math/big: implement Rat.FloatPrec not urgent but want to get in for 1.22
  • Cherry will review
• execution tracer work:
  • MichaelK: everything put up for review is pretty close to landing
  • new tracer will land pretty soon, but enabling by default is blocked by cmd/trace support. cmd/trace code has no abstraction. Working on it. Need review.
  • What about a release exception, just in case? The freeze exception would include enabling new tracer by default.
  • MichaelP: happy to review cmd/trace CLs. Release exception sounds fine, but should be done soon.
  • MichaelK: Felix has a working implementation but not all features. Will have a good chance done by freeze.
  • Matthew: freeze exception is up to the release team. My impression is that they've been increasingly strict about this.
  • Matthew: could the cmd/trace development be done in a branch or a separate repo, so power users could pull it in?
  • MichaelK: if new tracer is not on by default, it will be a hurdle for people to use it.
• Inliner work
  • Than: CL reviews are a little stalled but will get them reviewed in the next two weeks
  • Matthew will review

Attendees:

Carlos Amedee Cherry Mui David Chase Eli Bendersky Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-11-14

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• One week before the release freeze(!)
• FYI
• Likely accepted proposal: go/types: API changes to support explicit Alias nodes #63223
  • go/types Alias API → alias with type parameter → iterators
  • [Robert]: code is already checked in
• Likely accepted proposal: runtime: software floating point for GOARM=6, 7 (not only GOARM=5) #61588
• Accepted proposal: cmd/go: add support for dealing with flaky tests #62244
• 1.22 status
• new inliner: should we enable GOEXPERIMENT=newinliner by default to turn on the new inlining heuristics in 1.22?
  • [Than] on positive side, provides some modest performance improvements, with acceptable compiler speed overhead, and google-internal testing runs have been clean, so risk appears low.
  • [Than]: inlining diagnostics messages change, needs to be communicated
  • [Than]: leaning towards enabling by default, with a more "toned down" announcement to moderate user expectations
  • [Matthew]: go ahead and ship it if there is an overall performance improvement. turn it on in RC. if there are many bugs we can turn it back off
  • [David]: need to decide how to handle any changes for the LSP JSON logging users. The plan is to keep the old words in the old version, enable the new words in new version
  • [Matthew]: what sort of stability guarantees are we promising for LSP users?
  • [David]: we are not supposed to surprise users. If we change something, we change the version number
  • [Matthew]: what exactly does "surprise" mean here
  • [David]: we intend to not change the words
  • [Cherry]: version number is specified by the tool?
  • [David]: yes. if/when we let them know and they can change version
  • [MichaelP]: how we keep the old words? "can inline" means inline everywhere, but that will not be true
  • [David/Than]: this is happening already for large functions (ex: for callee of size 79 we'll advertise is as inlinable but then not inline it in a big func) * [David] sounds like concensus is to leave JSON as is
  • [Eli]: TGP status for Matthew's CLs?
  • [Matthew]: not yet
• range over function check
  • [David]: once it gets reviewed it can go in. overhead is high in some cases, very small with very cheap iterators. Plan to have a thorough check, no optimization, but have a compiler debug flag to turn the checks off. Performance is generally not bad.
  • CLs are under review
  • semantics for named results
  • [Matthew]: fine for now for experiment, will clarify when turning it on by default
  • [Matthew]: will find test cases
  • [Cherry]: documenting the caveat
• allocation headers
  • [MichaelK]: allocation header is in and enabled. google-internal testing is clean. issue tracker is clean. not yet released into google-internal prod
  • [MichaelK]: tracer: a lot is in, may not need freeze exception

Attendees:

Carlos Amedee Cherry Mui David Chase Eli Bendersky Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-11-21

• Go 1.22 freeze today!
• performance comparison Go 1.20 vs tip+PGO
• -4.59% geomean on Sweet
• BiogoKrishna +20% regression
• [Matthew]: does Sweet run old/new configs interleaved
• [Michael]: yes, interleaved (but not randomized)
• [Michael]: BiogoKrishna is not a representative benchmarks. built with some nonpreemptible loops, a lot of bit arithmetics and table lookups. The reason we keep it is it is a good preemption benchmarks. It can be sensitive to code layout.
• [Michael]: cool debug trick on the dashboard
• Please write release notes #61422
• Go 1.22 issues
• 2024 topics
• KSLO cost reduction
• Go on future platforms (RAM efficiency. NUMA?)
• (maybe) Go-Python interop for AI-powered applications
• [David]: is it a good idea to use cgo for Go-Python interop?
• [Michael]: no. better with pipe or RPC (EDIT: I'm wrong about this. A conversation after the meeting clarified a misunderstanding I had about Go->Python calls specifically. Both Go->Python and Python->Go with cgo may very well be preferable to pipe/RPC in many circumstances. :))
• [Michael]: excited with RAM efficiency work. Not sure if NUMA is the right target. Austin's analysis shows memory bandwidth is going to be an issue. User survey: impact vs effort mapping graph of the potential optimizations?
• [Michael]: intended to do another session with Alice with user survey for 2024 priority. Austin has a good start for RAM efficiency things
• [discussions about project prioritization]
• [Michael]: go.dev/fast is under RAM efficiency?
• [Eli] documentation work is its own thing. Sounds important, but don't spend too much time. New tracing work is also in this direction.

Comment From: thanm

2023-11-28

• Go 1.22 RC1 is scheduled on Dec 12 (2 weeks from now)
• Please write release notes #61422
• [Keith] there was some discussion previously about revising and/or improving the process for putting together release notes -- has anything happened on this front?
• sounds like not for this cycle on the new process front
• Loop scoping (David or Russ to write relnotes)
• Range-over-int (David to write relnotes)
• Range-over-func under GOEXPERIMENT (David and/or Russ to write relnotes)
• go/types new APIs (Alias, FileVersion) (Robert Griesemer to write relnotes)
• New tracer (Michael Knyszek to write relnotes)
• Bump bootstrap to 1.20 (MichaelK)
• PGO devirtualization changes (Michael Pratt to write relnotes)
• Allocation headers (Michael Knyszek to write notes)
• CL 544195 runtime: profile contended lock calls (Michael Pratt or Rhys)
• CL 534161 runtime/metrics: add STW stopping and total time metrics (Michael Pratt)
• CL 537515 runtime/pprof: include labels for caller of goroutine profile (Michael Knyszek or Michael Pratt)
• CL 511475 cmd/link: allow deriving GNU build ID from Go build ID ID (Cherry Mui)
• CL 493136 cmd/link: rationalize -s and -w flags (Cherry Mui)
• Port specific changes that might require release notes
• CL 461697 default to PIE on darwin/amd64 (Cherry Mui)
• CL 514907 GOARM=softfloat/hardfloat (Keith Randall)
• CL 521790 enable register ABI on Loong64 (David Chase or Loong64 owners)
• CL 521778 enable plugin on Loong64
• [Than] Windows SEH stack unwind #57302? need to ping CL/issue
• Robert Griesemer: writing release notes is time consuming because the format is tedious
• Cherry Mui: there was some discussion about moving to markdown
• Michael Knyszek: this is actively being worked on
• Carlos Amedee: good to give feedback to Jonathan
• Matthew Dempsky: similar to api/next, we can do relnotes/next
• Carlos Amedee: this is the direction
• Go 1.22 issues
• Status
• discussion of range-over-func efficiency
• David Chase: Russ's CL is related
• Michael Knyszek: do need freeze exception for anything here?
• David Chase: iter package needs a separate GOEXPERIMENT
• Keith Randall: iter package should land in x/exp?
• Matthew Dempsky: need some coroutine stuff from runtime

Attendees:

Carlos Amedee Cherry Mui David Chase Eli Bendersky Joedian Reid Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-12-12

• Schedule
• go team fixit week (this week)
• go team "quiet" week (next week)
• Go 1.22 RC1 is rescheduled to next Tuesday, December 19
• Thank you for writing the release notes!
• topic: //go:linkname
• Than: do we need to start making a more concrete plan for disallowing “pull” style go:linknames of runtime/stdlib symbols?
• Than: there are a lot linknames in opensource code. If we plan to change this, maybe we start communicating.
• MichaelP: it is still unclear if we can and should change it. If we don't provide an alternative, I don't think we can just turn it off. If we delete entirely, users may resort to assembly.
• Matthew: assembly code is a good point, user can still call it from assembly code. Balancing that we want to stop user poke into runtime, while provide things they want to do
• Cherry: we can stop assembly code call them in the linker
• Keith: we can find the top users of it and try to fix it somehow. The problem is if we change the name of popular things, we can help them
• Than: if we leave things entirely unchanged, it would block future projects (e.g. renaming runtime to internal/runtime)
• Cherry: for the rename, we could provide forwarding linknames
• MichaelK: we can treat the list of existing linknames as a priority list and provide workarounds
  • rand (handled in 1.22)
  • nanotime
  • memhash
• MichaelK: fine to break programs that linkname to stoptheworld
• Matthew: maybe a good starting point is to start implement the logic in the linker and a vulncheck-style tool for why they might fail the build, to communicate with users, and get feedback from users which linknames are needed
• MichaelP: discourage linknames by providing a compiler flag to turn it back on. That will strongly discourage uses in libraries
• Robert: we should have a better idea for why users use them
• survey from Matthew, MichaelP shows 700 linknames for packages with 10+ imports
• Status
• compiler error URLs
  • Robert: Russ thinks we should be doing this with mnemonics, not numbers. Robert Griesemer will look into the mnemonics. Also need to write the documents. Russ vetoed autogenerated docs. The docs could be more explanatory. Carried over to 2024.
• Heap analysis improvements -- viewcore
  • MichaelK: want to work on it this week for fixit, for viewcode.
• PGO devirt
  • MichaelP: done, with minor issues, not clear we want to address them soon
• Traceback iterator: simplify defer
  • Matthew Dempsky: done. will check with Austin.

Attendees:

Carlos Amedee Cherry Mui David Chase Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2023-12-19

No meeting today (Go team "quiet" week)

Comment From: thanm

2024-01-02

• Allocation headers results
• still evaluating impact of GOEXPERIMENT=allocheaders change on google-internal applications. It is generally positive, but not clear to what degree.
• Go developer survey
• “The top requests for improving toolchain warnings and errors were to make the messages more comprehensible and actionable”
• Some of this is also about runtime errors
• mild surprises (at least to attendees):
  • 5% targeting wasm
  • 56% “use” ARM64 (!)
  • “However, Apple hardware isn’t the only factor driving ARM64 adoption: among respondents who don’t develop on macOS at all, 29% still say they develop for ARM64.”
  • rumor has it that ARM just laid off their whole Go team in China
• “improved expressivity [“creature comforts”] (12%), improved error handling (12%), and improved type safety or reliability (9%). Respondents had a variety of ideas for improving expressivity, with the general trend of this feedback being “Here’s a specific thing I write frequently, and I wish it were easier to express this in Go”. The issues with error handling continue to be complaints about the verbosity of this code today, while feedback about type safety most commonly touched on sum types.”
• [MichaelP]: 50% said they use protobufs (mostly via gRPC)
• 2024 plans
• Finishing in flight (done by end of Q1)
  • LUCI migration
  • Inlining: enable new heuristics
  • Inlining: scheduler
  • PGO: scalable builds
  • Runtime trace overhaul: cleanup (delete old tracer, old cmd/trace, moving old trace parser behind new API)
  • Runtime trace overhaul: reader API
  • go build -json
• 1.23
• Range-over-func GA
• /e/ URLs?
• Type parameters for type aliases?
  • [Eli]: I think this is very far along. Ask Robert next week.
• sync/atomic And/Or
• sync/atomic Uint64Pair?
• Cost reduction (RAM efficiency)
• Performance analysis
• [MichaelK]: CockroachDB is excited about contributing benchmarks to our suite.
• administrivia
• more of the work formerly done by the release team is being transferred over to the core (C+R) team

Attendees:

Austin Clements David Chase Dmitri Shuraylov Eli Bendersky Michael Knyszek Michael Pratt Than McIntosh

Comment From: randall77

2024-01-23

• Tree open! 🎉
• Upcoming 2024 plans
• MichaelK: Is the iter package going to land in 1.23?
• Cherry Mui: My tooling for cold path escapes could probably also be used to estimate up-stack escape analysis (by excluding returned values)
• Single bit reference counting
  • Matthew Dempsky: https://mdempsky.notion.site/Dynamic-escape-analysis-76bbeecd3ac4440c88d0cb2f722aaf75
  • Michael Knyszek: Unique pointer optimization and freegc
  • We should brainstorm about this.
• People are grumpy we dropped Windows 7 support (also without a good error message)
• Dmitri Shuralyov: We dropped support in a major release and updated our installer check
• The minor release change may have been that we now get a dynamic linking error instead of something nice.
• Michael Pratt: This seems to have come from a security fix.
• Michael Pratt: Considering a proposal for Windows 7 as a secondary port. Seems like a reasonable path.
• Dmitri Shuralyov: We’ve never done that before. This is WAI and went through the proposal process. Adding back support would have to be a new proposal.

Attendees:

Austin Clements Cherry Mui David Chase Dmitri Shuraylov Joedian Reid Keith Randall Michael Knyszek Michael Pratt Robert Griesemer

Comment From: thanm

No C&R meeting today (this is a Google Core "no meetings" quiet week).

Comment From: thanm

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2024-02-27

• Amazing out-of-tree SwissTable results from Peter Mattis (CockroachDB’s CTO)
• TL;DR: Iteration is ~60% faster, gets are ~20% faster (though there are some odd slowdowns with gets of non-existent elements on large maps), puts are ~30–45% faster (~20% faster if they grow the map), deletes are a mixed bag
• Austin’s benchmark analysis, benchstat, benchplots
• Uses extendible hashing to avoid resize latency of earlier implementation
• Missing some optimizations that would be fairly easy to do in a runtime implementation. Mostly because it’s using Go generics so can’t do the type specialization we do.
• Doesn’t currently even use SIMD, though again in the runtime it wouldn’t be hard to add that.
• The implementation is complex, but looks really clean.
• Peter is supportive of getting it into the runtime; it seems clear that we (Go C&R team) should work to make this happen.
• Keith Randall and Michael Pratt to work on bringing this in.
• Michael Pratt: Expecting a long tail of weird performance regressions for google-internal tests and such. Probably needs to be behind a GOEXPERIMENT.
• misc wasm discussions
• misc meeting-scheduling discussions

Attendees:

Austin Clements Carlos Amedee Cherry Mui David Chase Dmitri Shuralyov Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2024-03-12

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Lengthy discussion on iter.Pull and LockOSThread semantics
• Case: Both goroutines call LockOSThread
  • 1. G1 is on a locked OS thread
  • 1. G1 calls next, which switches to G2
  • 1. G2 locks its OS thread
  • 1. G2 calls yield
  • Option 1: Step 2 does a thread switch
  • Option 2: Step 2 “donates” the OS thread. Step 3 moves G2 to a new thread
  • Option 3: Step 3 panics
• Case: yield crosses goroutines
  • 1. G1 is on a locked OS thread
  • 1. G1 calls next, which switches to G2
  • 1. G2 passes yield to another goroutine, G3, and continues executing
  • 1. G3 calls yield, which switches to G1
  • If step 2 does a coroutine switch, then it has to “donate” the locked thread to G2. But then in step 4, you have both G1 and G2 that have to run on the same locked thread.
  • Option 1: Step 2 does a thread switch
  • Option 2: Step 4 interrupts G2 (which may take arbitrarily long) in order to run G1
  • Option 3: Step 4 panics because yield was called on another goroutine. (just iter.Pull or iter.Pull and range-over-func).
  • David Chase: G3 can do a lock OS thread, too.
  • Austin Clements: I’m not sure that matters for this case.
  • Michael Pratt: That could be a problem with the first case, where G2 calls lock OS thread, but G1 does not.
• Case: next crosses goroutines
• Michael Knyszek: Cgo callbacks are a pain because that thread is always locked.
• Matthew Dempsky: Deprecate LockOSThread and add RunOnLockedOSThread(f func())
  • Michael Knyszek: Maybe that’s what we should have done in the first place. A lot of UI libraries have a “take this function and run it on the main thread”.
  • Cherry Mui: go.dev/issue/64777
  • Ian Lance Taylor: go.dev/issue/64755
  • Austin Clements: Even if we deprecate LockOSThread, we have to deal with it forever (though the performance may be less of a concern).
  • Michael Pratt: Passing yield to a RunOnLockedOSThread goroutine, same trouble
• Ian Lance Taylor: What’s the downside of making the switch do a full goroutine switch if the thread is locked?
  • Austin Clements: Semantically that works out. Performance is an issue. You don’t necessarily control whether you’re locked, like in the cgo callback case.
  • Ian Lance Taylor: iter.Pull is not going to be that common
  • David Chase: I agree. We have a mechanism that works: goroutines. It’s unfortunate that many of these iterators could easily give you a pull, but we’re not exposing that.
  • Keith Randall: The issue I see is that you may use some code that uses iter.Pull internally. It feels like an abstraction break between the OS thread locking (maybe from a cgo callback) and the iter.Pull.
• Struct packing/reordering
• David Chase: Struct packing/reordering is a mechanical thing humans shouldn’t be doing. If we had been doing this with protobufs, we’d have huge savings. 3% RAM footprint, ~20% GC cache traffic. We may end up doing GopherPen and being able to reorder struct fields eliminates a lot of the RAM footprint expense.
• David Chase: I was figuring this would work for all structs, but Russ Cox said it should depend on the module language version. But you can do var x pkgA.T; (pkgB.U)(x), if T and U have the same underlying type, and if we laid out T and U differently, it’s not clear how we could implement this cast. If this is rare, maybe we can just break it.
  • Matthew Dempsky: A “fragile conversion” is a conversion form T to U where T and U’s underlying type literals appeared in source files from different Go modules.
• David Chase: Ran fragilecast ecosystem analysis, only 27 instances in the 21305 10-or-more imports projects. Classification of conversions.
  • David Chase: I’ve been trying to make it module-aware to reduce false positives, but having trouble. Presumably in this case there’s shared ownership, and a single go.mod language version.
• Ian Lance Taylor: What about the case of passing the address of a struct to C code?
  • David Chase: I don’t pick that up. I’m working on a proposal for a signal type that says “follow the platform rules.” Cgo would automatically add this.
• Robert Griesemer: What about per-file versions?
  • David Chase: I think this would ignore those and just use the module version.
• What does “work” mean? Is there a language change here?
  • Austin Clements: Old code keeps working, even if it has unsafe assumptions about struct layout.
  • David Chase: There is a small language change here if we disallow “fragile” casts.
• Matthew Dempsky: The language spec only has “conversion”, not “cast”.
• Matthew Dempsky: Type aliases have a disadvantage for documentation. E.g., if you alias an internal type, the exported type won’t necessarily have documentation.
  • Austin Clements: Russ and I have talked about fixing that in go doc.
• Robert Griesemer: Is reordering based on the structure of the type? Or profile-based? Could it be done in a way that results in the same reordering for the same underlying types?
  • David Chase: I can imagine someone would want to try profiling, but my assumption is that we would use a stable algorithm that worked the same way for structurally identical types. Partly because there’s unsafe code out there.
• Michael Knyszek: How are type aliases represented in documentation today? Should it copy not just the documentation but the definition?
  • Austin Clements: I think you would want to copy the definition (though don’t hide that it’s an alias).
• Matthew Dempsky: So two struct types that are identical would be reordered in the same way
• Keith Randall: Fighting concerns. We don’t want to break everyone’s unsafe code all at once, but we don’t want to disallow cross-module conversions.
• Austin Clements: That’s why David did the ecosystem analysis. These conversions are very rare.
• Keith Randall: What about plain struct conversions? Memcpy now, but across language versions, a reorder.
  • David Chase: My analysis doesn’t look for these right now.
  • Cherry Mui: There’s at least a way to compile this. The pointer case just can’t be fixed.

Attendees:

Austin Clements Carlos Amedee Cherry Mui David Chase Ian Lance Taylor Joedian Reid Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2024-03-19

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• FYI
• cmd/compile: add go:wasmexport directive #65199 accepted
• proposal: runtime/debug: add SetCrashHeader function #64590 declined
• proposal: spec: support int(bool) conversions #64825 declined
• runtime: CL 561635 changes relative PCs printed in tracebacks #65761
  • Still an open question. If we’re going to do structured tracebacks, it should probably be tied to the new debug.SetCrashOutput API, so we need to at least decide on the API this release.
• discussion about ways to automate Go best practices
• Matthew Dempsky: Tangential to that, Austin and I were discussing doing team screencasts. I can feel stuck with my development workflow from 20 years ago and being familiar with workflows other people are using could make us more productive and realize where things could still be improved.
• brainstorming ideas for AI-powered apps useful for Go team itself
• Solving our own problems through AI, to get us more familiar with AI applications.
• OSS project use cases
• Build-time use cases
• Austin is working on a Go GC efficiency downselection doc

Attendees:

Austin Clements Carlos Amedee Cherry Mui David Chase Dmitri Shuralyov Ian Lance Taylor Joedian Reid Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2024-03-26

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• upcoming inliner heuristics review during this Thursday’s Go breakout
• Project status updates
• Range-over-func iter.Pull and LockOSThread
  • David: We could always use goroutines.
  • Austin: Russ did have an inbetween version that used goroutines and channels, but with fused channel operations.
  • Michael Knyszek: That might be an easier fallback path and general channels.
  • Cherry: Did Russ’ fused channel operations work with locked OS threads?
  • Austin: I’m not sure.
  • Cherry: It might still be easier to implement the fallback for that with locked OS threads.
• Joedian: Are there things we’re worried about for 1.23?
  • Range-over-func has a lot of open tasks
  • David: Checking semantics will be fine. Worried about defer with named results. Performance probably okay. Worried about weird things for debugger integration because it’s not clear we can do exactly what they want.
  • Cleaning up old tracer
  • Austin: Does this have to happen in 1.23?
  • Michael Knyszek: It will break with things like iter.Pull, which aren’t supported in the old tracer.
  • Structured go build -json doesn’t have to happen for 1.23
  • SwissTables doesn’t have to happen for 1.23, but it would be good for hitting our 5% target.
  • Michael Pratt: I’m hoping to start this after returning from vacation.

Attendees:

Austin Clements Carlos Amedee Cherry Mui David Chase Dmitri Shuralyov Ian Lance Taylor Joedian Reid Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Robert Griesemer Than McIntosh

Comment From: thanm

2024-03-28

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• On Thursday 3/28 we held a design review looking at the new inlining heuristics framework being developed as part of the inlining overhaul effort (this was a separate session from the usual C&R meeting)
• Slides from the talk: https://docs.google.com/presentation/d/1Lf3WoRyCNicS1K3NCuVl_VnJFhvew_6nAQF_Wx--F54/edit#slide=id.p
• Notes from questions/discussion during the talk
• Litmus tests
  • Inline sort.Search with a (small) function literal
  • Fast path/slow path inlines the fast path
  • Singleton calls to non-exported functions
  • Or specifically closures. Comes up as a way to do “function literals”, and also to give more control over defers (though that will prevent inlining).
  • Russ gave some examples on the bug
  • A call site weight of 57 makes no sense. We should be able to significantly lower that.
• Parameter heuristics: constant feeds if/switch
  • Michael Pratt: If you could analyze the effect of propagating a constant, you could potentially significantly reduce the size. It would be nice to capture that in the score.
  • Than: We don’t currently look at the value of these constants. Tracking that could significantly bloat the export data.
• Sweet benchmark results
  • The GoBuild (non-Link) benchmarks are measuring the impact of doing more work on compile time, so it’s not directly comparable with other benchmarks. That’s fine, but means the overall geomean isn’t meaningful.
• Difficulties/obstacles
  • Michael Pratt: With PGO, we’ve noticed that about half of the performance effect comes from optimizing the runtime, in particular the garbage collector. We’ve never checked closely if that’s from making the GC faster or the application doing less allocation.
• Robert: Why don’t we let users say “inline this”?
  • Ian: GCC shows that people often get this wrong.
  • Russ: Overfitting to “right now”
  • Ian: OTOH, GCC experience shows that people usually use “don’t inline” correctly.
• Keith: To some extent we train our users to write code for the inliner. Like manual hot/cold splits today. It’s better if users don’t have to jump through hoops to get “the right thing.”
• Robert: If people write lots of small functions, you might get the large function in the end. If people write large functions, we can’t do anything. Maybe we should tell people to write smaller functions.
• Tim: Do we know how well these heuristics correlate with places of user angst?
  • Russ: Perhaps replace angst with “places where inlining actually helps”
  • Than: I think that happens with passing concrete values to interface arguments. People get grumpy when they have to contort their code around that.
• Ian: Heuristic that specifically targets removing escapes?
  • Than: Passing a concrete value to an interface helps, but that’s just one example.
  • Ian: Also feeds into type switch or type assertion. Maybe “likely” interface type at call site? Also unused parameters, though that helps more with interface method calls (e.g., caller does some work to compute a parameter that isn’t used).
• Notes from questions/discussion after the talk
• Austin: I would expect the common case to be a constructor function that returns a pointer, but the result doesn’t escape past the call site.
• Than: That’s hard to capture in a heuristic that’s not doing full escape analysis.
• Austin: Long ago, we talked about doing the data flow before inlining, then using that information to drive inlining, then producing final escape summaries.
• Than: That would definitely require an escape analysis expert.
• Russ: Seems like the strategy is to think about heuristics and try them and see what happens, which doesn’t feel very directed. Maybe, turn the inliner up really high, see what that gives you, and then figure out why. Hash bisection may be able to tell you this: write a function that says “is etcd still > 10% faster?” and run hash bisection to get the set of places where it really matters. Then ask what patterns get you those. Then worry about false positives that come with those.
• Than and others: idea from Russ sounds good
  • probably need to finish stack slot merging before we do this, or the costs of inlining may be too dominant to seek out the wins.
  • Than: bisection could be made more difficut due to noisy benchmarks
  • Than: For escape effects, we could measure the allocation count, which should be pretty stable.
• Tim: Range-over-funcs don’t exist in any code, but do you have a sense of how that will interact with these when that does start to exist?
  • David: It resolves things down to flat code pretty often right now. Though if something prevents inlining, the whole house of cards falls apart.
• Austin: “Calls cost 57” is a clear red flag. A call isn’t expensive. Right now this is our backstop against making lots of bad decisions, but it also prevents us from making a lot of good decisions.
• Austin: “Don’t inline here” heuristics, if they’re working right, should have almost no effect on performance, just reduce binary size. Should check binary size effects of those.

Comment From: thanm

2024-04-02

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• Discussion about how to help automate / and ease the introduction/rollout for Go "best" practices" that we use in the Go core team
• Ensure users are getting the benefit of the core team’s work. (For example, IDE integration is great for build-time things, but we don’t have great answers for deploy/run-time.)
  • PGO example: How do developers consume profiles today? Can we integrate with those? (Vendors like DataDog?)
  • How do people coordinate production builds today?
  • “GitOps”: CICD & triggers, Github Actions
  • should we partner more closely with other teams? If we did, what could we do better?
  • If we did partner, then what happens? A single integration only does so much, while building a partner relationship keeps on giving.
• Keith: It would be great if this problem didn’t exist. A lot of our performance optimizations just happen when you upgrade. Hopefully the places where we couldn’t just make it automatic are a minority of places.
• Matthew: Go could be missing more of an “application level framework.” Right now if you want to build applications with Go, you have to use a lot of external packages. Unless you’re writing a 1970’s CLI. (Ian Lance Taylor: Gophers on Rails.) Opinionated Go way.
  • Michael Knyszek: Service weaver?
  • Carlos: go-kit
  • Austin: I don’t know what’s stopping us.
  • Matthew: What’s stopping me is that I’ve never built an application in Go and it seems scary and keeps changing. Go simplicity for building applications that work nicely over time.
• Michael Knyszek: I think there’s room for improving, e.g., net/http/pprof. Gophers Slack was discussing how everyone exposes basic debugging endpoints. Everyone does it differently because net/http/pprof is a security hazard. Where we did try to provide convenience, we’re now, today, doing a bad job. Pprof should just be there, and secure, and working by default. That impedes PGO integration. Could we integrate into the new “hot thing”, OpenTelemetry?
• strings.Compare optimization
• Keith: Used for sorting. We have an old “Less” implementation, and strings.Compare builds a 3-way compare on two “Less”es. We’ve pushed back on optimizing strings.Compare, but now it’s the thing to use for sorting because “you should be using the built-in comparisons.”
  • Ian: Seen “if strings.Compare(a, b) < 0” many times because people don’t realize you can just directly compare strings.
• Compare the strings once instead of twice, using internal/bytealg
• CL 532195
• Austin: Can we do the same for cmp.Compare?
  • Ian: No because we can’t specialize it for string. (We could type switch on string, but not ~string. And it’s not clear if the compiler would specialize in that case anyway)
  • Austin: We could teach the compiler about this special case.
• Keith: The other option was to look for the three-way comparison code pattern and compile that specially. That would catch both strings.Compare and cmp.Compare. But it’s a tricky optimization.
  • Austin: It could be pretty specific to the pattern in strings.Compare and cmp.Compare.
• Way forward: just land this CL. We can undo it if we ever do the general optimization.
• Austin: LLVM MLIR uses “basic block arguments” instead of “phi functions” and it sounds like that makes it easier to do block graph manipulations. Have we considered doing that sort of thing?
• Matthew: That’s what I was suggesting with reorganizing the compiler around basic blocks that do tail calls instead of functions. This seems to be the popular SSA-like representation these days.
• Austin: It seems like we could do an 80/20 thing where we don’t have to restructure the whole compiler toward a sea of basic blocks. We could still have regular functions, and just make it easier to manipulate the BB graph.
• Austin: What’s the implication for, say, BB1 dominates BB2 but isn’t a direct predecessor, and BB2 uses a variable introduced in BB1. Does that mean that variable has to be threaded through the arguments to the intermediate BBs?
• Matthew: Example: Thorin IR (see Figure 4 on page 4 for syntax/semantics/typing). BB arguments directly correspond to phi functions and you’re allowed to do “implicit capture”. Results in a very concise semantics.

Attendees:

Austin Clements Carlos Amedee Cherry Mui David Chase Dmitri Shuralyov Ian Lance Taylor Joedian Reid Keith Randall Matthew Dempsky Michael Knyszek Michael Pratt Than McIntosh

Comment From: cherrymui

2024-08-06

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

• FYI
• hash/maphash: add func Comparable #54670 re-likely accepted
• Resume public meeting minutes at #43930
• Went over H2 plan
• Bump bootstrap to 1.22
• Bump minimum Linux to 3.17
• Switch built-in maps to SwissTables
• Range-over-func
  • Range-over-func: Fix addrtaken with inlining [DONE]
  • Range-over-func: Fix iter.Pull performance under cgo
• PGO: Discriminator support
• Type params on aliases
  • Export data support
  • Enable GOEXPERIMENT=aliastypeparams by default
• Structured all.bash: go build -json
• GC efficiency
• WASM
  • Implement go:wasmexport
  • Integrate structs.HostLayout into go:wasmexport and wasm32

Attendees:

Austin Clements Carlos Amedee Cherry Mui David Chase Dmitri Shuralyov Eli Bendersky Ian Lance Taylor Michael Knyszek Michael Pratt Robert Griesemer Tim King

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2024-08-13

• Go 1.23.0 is released today 🎉
• #68658 cmd/go: breaking change in 1.23rc2 with version constraints in GOPATH mode
• Decided not to include CL 603895 in 1.23.0
• Discussions on CL 603895
• Robert Griesemer: if the file local version is not correct (e.g. go1.21.4 is invalid), it is silently ignored, which may be surprising to user
  • #64127
  • Tim King: vet has a "likely match" build tag check that should catch this
  • Cherry Mui: is the file not being built by go command at all?
  • David Chase: is it syntactically invalid? What about //go:build !go1.21.4 ?
  • Michael Knyszek: is there a recorded talk about version upgrading/downgrading
  • Russ Cox has a blog post (and this)
• Continue discussion on the issue
• 1.24 cross-team features
• parameterized type alias, with tools team. Robert Griesemer and Tim King are already talking with them.
  • Tim King: would be very nice to get it in before the next x/tools version bump, which is September
  • It is not yet on by default. Tim King has a checklist https://github.com/golang/go/issues/68778
  • Keith Randall: the flip is prerequisite for x/tools change?
  • Tim King: yes, but need tools's export data in first before flipping
• Keith Randall: bump the bootstrap version. There is already a CL that wants to use 1.22 feature in the compiler
  • Dmitri Shuralyov: will get in this or next week

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2024-08-20

• Status
• Bootstrap bump
  • Dmitri Shuralyov: LUCI builders are all updated, done a minimal fix for legacy builders, just submitted first CL that requires new version at tip.
• Linux bump
  • Ian Lance Taylor: The actual version we’ll be requiring has not been finalized yet. Brad pointed out that 3.17 is a problem because there are a lot of old Synology boxes out there. It’ll probably be 3.2.
• SwissTables
  • Michael Pratt: I have a full working implementation with extendible hashing. A bunch of benchmarks are slower vs the existing maps. We’ll almost certainly need special paths like fast32/64. Mostly really small benchmarks, like small maps looking up the same key over and over.
  • Could we make the new map actually generic?
  • We don’t have anything that makes up instantiations like these in the compiler.
  • Problem: runtime.a isn’t always available today (we could fix that)
  • Problem: what types do we instantiate? Do we pre-instantiate common types in the runtime package?
    • Michael Pratt: We may want the “GC shape” of these to be defined somewhat differently than the usual.
  • Turning the equality call from an indirect call into a direct equality check would be much faster.
• Type parameters on type aliases
  • Tim King: Most of the hard bits are out for review. Need to turn on more builders. Need to copy various bits into x/tools.
  • Austin Clements: Could we ever fully decouple these?
  • Tim King: It would be wasteful. You could still have the compiler do type checking, but then call out to something that would write the data for vet.
  • Cherry Mui: The compiler export data has a lot more than what tools need and does a lot of non-type-checking work. If my cache is empty and I run go vet, it does a lot of unnecessary work recompiling everything.
  • Robert Griesemer: There is a source importer that’s existed for years. The API checker does more or less what Cherry said, but doesn’t cache the results. I don’t know how much x/tools depends on caching repeated work. There’s a lot of work in the unified importer to only import what you need. Not impossible, but quite a lot of work.
  • Cherry Mui: I’ve heard gopls has its own export data format (not positive). Presumably gopls is quite latency sensitive, so if they can do it, vet probably can, too.
  • David Chase: Do the tools get the same view of the module import graph as the compiler? (This came up because I’m looking at making go doc look at other packages.)
  • Tim King: I believe it all comes from “go list”, but it might depend on the tool.
  • Tim King: We also run vet from “go test”, so spawning a duplicate process to write duplicate type information seems wasteful, but it would definitely simplify everything for the two sides to use their own views of export data.
• WASM
  • Cherry Mui: wasmexport is pretty much done. WASIp1 is in. WASM JS is out for review. May want to add more tests.
• David Chase: Found loop alignment anomaly on ARM64. Goes different ways on M2/M3.

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2024-08-27

• cmd/go: breaking change in 1.23rc2 with version constraints in GOPATH mode #68658
• Michael Matloob proposed solution: max(1.21, fileVersion) independent of -lang (moduleVersion)
• We'll probably do this in 1.24 and 1.23.1
  • Robert Griesemer: 1.23.1 is scheduled next Wednesday, and Monday is U.S. Labor Day. If we want to do it in 1.23.1, it needs to be in soon.
  • Currently there is no backport issue.
  • Dmitri Shuralyov: Is it okay to be 1.23.2?
  • Cherry Mui: I think it's okay. It's not new in 1.23.0.
• Proposal: testing/synctest: new package for testing concurrent code #67434
• Michael Knyszek and Michael Pratt will review
• Elimination of core types from spec #63940
• Robert Griesemer: I have implemented 60-70%. Will see how it goes. Will need a proposal and get accepted. There will not be a huge change to users.
• Cherry Mui: Is the concept of Core type just in the spec and internal to the compiler? Is there any public API about core type?
• Robert Griesemer: will sync with the tools team
• Range-func/iterators performance
• David Chase: at least for a particular small loop, if the body includes a 4K boundary, it will run 2x fast on Apple M3, but 2x slow on Apple M2, no difference on GCP ARM64 VM
• David Chase: we are mostly happy with the performance (on sensible machines) after deadlocals. There is a case that the inliner could do better.
  • The inline budget calculation about OCLOSURE
  • Keith Randall: you want the cost to be proportional to the size of the code to create the closure object

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2024-09-03

• Status
• Range-over-func: Inliner improvement on handling closures
  • David Chase: https://go.dev/cl/609095 reduces call site penalty if callee is param. Seems to reduce binary size, helps some iter benchmarks, there is one regression in gonum, looking at that. Another approach decoupling OCLOSURE size from cost of containing function would help, but was not done correctly, so, not yet.
  • Keith Randall: this really only helps if the callee is a known function
• Parameterized type alias
  • Alan has a proposal to support only 2 recent versions or export data in x/tools #68898
  • Tim King: there is a backlog of go/types users that are not yet go 1.22. They should update to 1.23 or 1.24 to use parameterized type aliases. We should probably figure out a good way to advertise this to tool authors.
  • golang-dev, Slack, tools team may have some channels
• HostLayout
  • Keith Randall: Is it coming to 1.24?
  • David Chase: structs.HostLayout landed in 1.23. Working on adding it to syscall and cgo. Ian thinks we probably need to do something with unkeyed struct literals. Vet didn't flag them, as they are "local".
  • Cherry Mui: another possibility is to have the compiler special-case cgo structs without adding the field.
  • Ian's proposal is to rewrite it in-place in the cgo tool.
• Bump bootstrap to 1.22
• SwissTables maps
• Wasmexport
• Diagnostics

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2024-09-10

• FYI
• Likely accepted proposal: runtime: add AddCleanup and deprecate SetFinalizer #67535
• Likely accepted proposal: weak: new package providing weak pointers #67552
• [From Austin] Make wasmimport/wasmexport accept pointers to HostLayout structs?
• proposal: cmd/compile: relax wasm32 function import signature type constraints #66984 includes this but is pretty complex. Do we want to do this whole thing or just start with allowing pointers to HostLayout structs?
• Worried about letting the horse out of the barn with a wasmexport that only supports unsafe.Pointer.
• Cherry Mui: The proposal is in a good direction. GOARCH=wasm32 is still going and uncertain. What do we do with GOARCH=wasm? We could allow structs with HostLayout and only non-pointer fields?
• Michael Knyszek: Should we backport https://go.dev/cl/610738?
• Summary: unique.Make intends to clone almost all strings before storing them in the central map, but erroneously stores the original string as the map key.
• Pros:
  • Users of unique.Make don't need to defensively clone strings.
• Cons:
  • It's not really documented anywhere (yet) that we clone these strings. Ian suggested doing so a while ago and I never got around to it. So, this isn't going to break anybody, and there is a workaround.
• Ian Lance Taylor: I think we should backport. Eli Bendersky agrees.
• Discussed about runtime/compiler office hours and contributors sync.

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2024-09-17

• FYI
• Accepted proposal: runtime: add AddCleanup and deprecate SetFinalizer #67535
• Accepted proposal: weak: new package providing weak pointers #67552
  • Michael Knyszek: Getting it landed is trivial, just renaming the package and a method. Strongly feel getting both land is better. AddCleanup is the only thing that will take work, but not a lot.
  • Carlos Amedee will work on AddCleanup.
• Likely accepted proposal: cmd/compile: relax wasm/wasm32 function import signature type constraints #66984
• Likely accepted proposal: crypto/subtle: add WithDataIndependentTiming #66450
• Michael Knyszek: From Slack: can we make unique.Make(string(byteSlice)) not allocate?
• The byte slice will be cloned as a string if we store it, so semantically, it's safe to do this. But I don't know how difficult it would be to make this work in the compiler.
• Austin Clements: Is there a general inter-procedural optimization here? (cmd/compile: consider to add move-like optimization for some string\<->[]byte operations #50846)
  • Cherry Mui: Maybe related to David Chase's work about pure / read-only functions
  • Keith Randall: For F(string(slice)), can we use the escape information to know the string doesn't outlast the call? Have to make sure it also doesn’t escape to the result.
  • Keith Randall: Worried about synchronization.
  • Example: Goroutine 2 modifies slice then sends on a channel, F reads from the channel, then uses its string argument. Before this optimization, we’d copy at the call site and see the old data (racy), but after this optimization, we’d copy after the modification and see the new data.
  • Keith Randall: Bigger problem: F could have a reference to slice and modify it.
  • Austin Clements: Needs some guarantee of the uniqueness of that slice.

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2024-10-08

No meeting due to Go quiet week.

2024-10-15

No meeting due to internal team summit.

2024-10-22

• FYI
• Go 1.24 Release Freeze is in a month (Nov. 21)
• Handy reference to which wasm proposals are in what state and where they’re supported
  • Michael Knyszek: Austin proposed to use a similar mechanism to track GODEBUG. What values are set for each release.
• testing.B.Loop auto-Keep semantics
• https://github.com/golang/go/issues/61515#issuecomment-2407808624 mentioned "we would implicitly apply Keep to every function argument and result in the closure passed directly to Loop."
• Michael Pratt: We don't want to keep too many or too few things alive unexpectedly.
• Cherry Mui: Would like to have a mechanism that covers a large portion (80%?) and not keep alive too much. One can always manually keep things alive, but hard to undo.
• Junyang Shao: Current implementation keeps the result of the last assignment or function call alive.
• Michael Knyszek: Would it be fine to try something? I don't think it is so critical to get it perfectly right. One can always use b.N loop as a workaround, if they don't like the semantics. I realize there's some pressure to get it right the first time, though. Maybe we could do some ecosystem analysis?
• Cherry Mui: I'm thinking about doing some analysis, keep everything alive and see if it deoptimizes things unexpectedly.
• Michael Pratt: Would be nice to get it right when we release the feature. There are also some complexity in matching just the loop body. It may be simpler to keep everything alive in the function. Things outside of the loop are not important.
• Michael Pratt: We could also apply to b.N loop as well. May cause surprise in people's benchmarks. May slow things down, or fix bugs.
• Junyang Shao: Austin’s semantics of keep everything alive are pretty straightforward and clear to users.
• Michael Pratt: In favor of clear semantics.
• Sounds like we can try keeping all function args and results live and see.
• Junyang Shao: Can change the implementation to match b.N loop and see if it slows down anything.
• Junyang Shao: Do we plan to add interprocedural SSA passes? There is some issue about propagating discriminators for PGO basic block layout.
• Keith Randall: We don't have plan for interprocedural SSA for now. We have ideas, like code size for inlining, register clobber sets.
• David Chase: Is the problem with the PGO basic block CL is that we need to profile twice? One for regular PGO (inlining+devirt) and another round for basic block.
• Cherry Mui: We should use line number (and perhaps column number) first, and only use discriminators if the line/column numbers are the same.
• Michael Pratt: Normal PGO workflow (PGO on prod) would work because it is profiling PGO binaries. It is confusing that they get the optimal result on the second run.

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2024-10-29

• FYI
• Public office hour is scheduled on Nov. 4, 1pm PT/4pm ET
• Michael Pratt: Enable swissmaps by default?
• Michael Pratt: Plan to submit all CLs today or tomorrow, implementation is solid.
• Michael Pratt: Sweet geomean is 1-1.5% faster. Some microbenchmarks may be slower, e.g. mapaccess with 9-256 elements. Unclear how this maps to production use case. Very small maps have a special code path. After 256 it gets a lot better.
• 1.24 status
• range-over-func cgo performance
  • Probably not going to do this for 1.24.
• Type parameter for type alias
  • Done
• PGO discriminator support
  • Michael Pratt: We could submit the discriminator support, but less important to evaluating the actual uses.
  • David Chase: Hard to use.
  • Junyang Shao: The propagation of discriminators is lossy.
  • Cherry Mui: Using basic block ID seems not the right approach.
  • Michael Pratt: Some issues for column numbers: multiple blocks have the same column number, like some Values are moved to another block.
  • Keith Randall: Line and column numbers are meant for the debugger, not for optimization. The compiler keeps track and propagate them for the debugger.
  • David Chase: We could use the initial basic block ID when constructing SSA.
• Struct reordering
  • David Chase: Discussed with Tim King and Ian Lance Taylor, but there are concerns about gating this on module Go version. New plan is to change how we treat anon fields, will do an ecosystem analysis. Vet check not for 1.24.
  • David Chase: I will try a GOEXPERIMENT for Go 1.24.
• range-over-func general performance
  • David Chase: Some CLs went in that help. Related to closure inlining. Good enough for 1.24. I will keep looking for improvements, but I don't expect to find anything more.
• Eliminating core types
  • Robert Griesemer: Working on a proposal. I don't expect it to happen for 1.24.
• runtime.AddCleanup
  • Carlos Amedee: Working local version. Working on Stop. Need to get a CL going.
• maphash.Comparable
  • Keith Randall: It's done.

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2024-11-05

• GoLab is next week in Florence.
• Swissmaps is enabled by default 🎉
• Michael Pratt: There will be followup optimizations. Make use of compiler intrinsics.
• 1.24 status (cont.)
• testing.B.Loop
  • Junyang Shao: Implemented as noinlining in the b.Loop body. https://go.dev/cl/612043
• PGO discriminators
  • Junyang Shao: Using column number as discriminator seems to work pretty well. Plumbing is easier. Will split out and make it submittable.
• Diagnostics
• Flight recorder
  • Michael Knyszek: Updated proposal.
• GC efficiency: Microarchitectural optimizations

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2024-11-12

• Unable to integrate with the latest race.syso from LLVM tip #70283
• Bug in LLVM, fixed in LLVM already.
• Junyang Shao: Update on PGO block layout: simple algorithm improves 0.8% for CockroachDB, 0.2% for others. Gopher-lua is 2% regression.
• Keith Randall: Is it putting hot blocks together?
• Junyang Shao: Use edge frequency, put the hot successor next.
• 1.24 issues
• Please work on them, or bump to the next milestone
• sync/atomic: TestNilDeref flaky failure on windows-386 with runtime fatal error #70288
• Start failing yesterday, causing frequent trybot failures
• Michael Knyszek: We haven't touched Windows builders in a year. Given that it seems to die without saying anything, maybe it is bad dereference during a signal?
• Russ fixed it.

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2024-11-19

• FYI
• Go 1.24 freeze is this week (Nov 21 at 11:59 PM Eastern; docs)
• Likely accepted proposal: testing/synctest: experimental package for testing concurrent code #69687
  • This is adding testing/synctest behind a GOEXPERIMENT
  • Damien has CLs out, Michael +2'd, working on fixing nosplit overflow on OpenBSD
  • Michael Knyszek: Should we prioritize fixing the stack check?
  • Cherry Mui: Yes. Will file an issue about it.
• Austin landed CLs for go build -json
  • Followup work on the LUCI side to make use of it.
  • Dmitri Shuralyov: Need a small change (#70435). Currently the structured build failure is behind a GODEBUG and not yet enabled on our builders.
• Updated perf dashboard
• Michael Knyszek: Added geomean to the main page. This is comparing with Go 1.23.
• Numbers are good, -3% on 16-core amd64, -4% on 88-core amd64, -2% on arm64
• Michael Pratt: Showing comparison with older Go releases would be good
• Michael Knyszek: Have limited machine resources.
• Cherry Mui: Numbers should be composable?
• Michael Knyszek: Probably fine. We try to not compose numbers after the fact, as machine changes from time to time.
• Junyang Shao: Is it possible to merge PGO block layout?
• Michael Knyszek: There were some inconsistencies in the CockroachDB metrics reporting. Fixed by now. Looks like your result is using the updated metrics. The inconsistencies are worth looking into, but the numbers are probably still meaningful.
• Michael Pratt: The other thing we need to take into account is that we need to add column numbers to the binary. It increases the binary size by 8%, 5% in pclntab and 3% in DWARF.
• Michael Pratt: One idea is to add column numbers only in hot functions. Another idea is to add them only when multiple blocks have the same line.
• Junyang Shao: DWARF line table is delta encoded, can we do the same thing?
• Michael Pratt: Pclntab is similar. Also, it may not help much for column numbers.
• Time feels tight for getting it in for this cycle.
• Carlos Amedee: AddCleanup proposal included deprecating SetFinalizer. Ian Lance Taylor mentioned that there is no 1-1 mapping from SetFinalizer to AddCleanup. So we break up deprecating SetFinalizer to a separate issue, aiming for 1.25.
• Michael Pratt: Document that we prefer AddCleanup when possible
• Cherry Mui: Changing finalizer uses in the standard library to Cleanup?
• Carlos Amedee: Yes. Working on the os package.
• Michael Knyszek: That would help shake out bugs.
• Ian Lance Taylor: 42 calls of SetFinalizer in the standard library.
• Tim King: Moving issues on milestones. Some times manually, sometimes by gopherbot.
• Gopherbot push issues to the next milestone when the final release goes out.
• Dmitri Shuralyov: Would still be helpful to manually update
• runtime: improve scaling of lock2 #68578 by Rhys
• Michael Knyszek: For contended mutexes, many threads spin and hammer on it. Another issue is integrating runtime.mutex to mutex profile incorrectly. Rhys fixed it by allowing 1 thread to take ownership and spin on it. Has a high impact on microbenchmarks. Performance neutral for most of our benchmarks. Trust the implementation as Rhys model checked it. Enabled by default, with a GOEXPERIMENT for easily turning off.

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2024-11-26

• Michael Knyszek: gccheckmark has been broken for a long time. Would like to have it fixed before other GC works. It is behind a GODEBUG. Only visible changes are tests.
• We can still fix bugs in the freeze. The question is how invasive it is.
• Michael Knyszek: One risk is about user arenas. We need to put them on some list, which is only consumed by checkmark code.
• [Austin] Follow-up work
• For 1.24: testing.B.Loop needs more documentation.
  • Describe effect on benchmark timing and body keep-alive. Probably also flesh out the release note. Given that this is a new way to write benchmarks, maybe a major release note is warranted?
  • Michael Pratt: The big doc comment in the testing package should switch to recommending b.Loop everywhere instead of b.N
  • Junyang Shao will do, as well as the examples
  • Update package examples
  • (It looks like body keep-alive and internal ramp-up are done, and we’re checking that the fast path gets inlined. Thanks for wrapping those things up before the freeze!)
• For 1.25: Given our experience with testing.B.Loop, how are we feeling about testing.Keep?
  • Junyang Shao: Currently the auto-Keep is done through noinlining of calls inside b.Loop loop. testing.Keep would have a different semantic for arbitrary expressions.
  • David Chase: Would this confuse people? If they can get it by b.Loop, a different kind of Keep would confuse people.
  • Michael Knyszek: Agree. People might add testing.Keep everywhere unnecessarily
  • Cherry Mui: Seems like we don't need it for now. We can wait for more experience on b.Loop usage
• For 1.25: maphash.Comparable didn’t deal with the subtle escape issue with strings. Filed follow-up: hash/maphash: Comparable[string] causes unnecessary allocation #70560
  • Michael Knyszek: Is it important enough that warrants a freeze exception? The performance of Comparable seems important. (Specifically that we made kind of a big deal about this on the proposal issue.)
  • Cherry Mui: There is already hashmap.String. We get good performance for scalar types. We can still try to implement it and see.
  • Dmitri Shuralyov: This is a new feature in 1.24. Improvement/polish on new features is in the scope of the freeze.
• Contain new intra-std linknames
• Cherry Mui: For 1.24, we'll just add them to the linker's blocklist. For 1.25, I'll do linknamestd and replace the blocklist.
• Please help write release notes
• Dmitri Shuralyov is going through relnote todo output and updating tracking issues
• Michael Knyszek: For performance improvements, instead of breaking down to pieces, we just summarize as one number, along with calling out with Swissmaps

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2024-12-03

• The build dashboard is pretty red (mostly secondary ports)
• Persistent failures:
  • linux-mips: ICE (https://github.com/golang/go/issues/70248)
  • swissmaps bug
  • linux-mips64, linux-mips64le: TestRootDirFS (https://github.com/golang/go/issues/70659)
  • linux-riscv64: crypto/internal/fips140test:exe_external (https://github.com/golang/go/issues/70516)
  • linux-s390x: TestRFC6979 (crypto/ecdsa) (https://github.com/golang/go/issues/70660)
  • aix-ppc64: crash in getGCMaskOnDemand (https://github.com/golang/go/issues/70483)
  • android: synctest defer on systemstack (https://github.com/golang/go/issues/70661)
  • openbsd: mostly internal/trace flakes (Michael Knyszek, various issues)
  • Maybe not worth worrying about:
  • freebsd-arm64: cmd/go TestScript timeouts
  • netbsd-arm: timers (seems like it's been there a while)
  • Others seem like ports that never quite got finished.
• Flakes:
  • *-clang15: crypto/tls.TestFIPSCertAlgs (https://github.com/golang/go/issues/70618)
  • darwin-amd64: cmd/internal/testdir.Test/fixedbugs/issue46234.go (https://github.com/golang/go/issues/67558)
  • various linux-amd64: net/http.TestTransportIdleConnTimeout nil deref (https://github.com/golang/go/issues/67450, appears to have a fix out)
• [Austin] More follow-up work
• Using new TextAppender/BinaryAppender interfaces in other std packages (mostly encoding/json and encoding/xml).
• Keith Randall: Code bloat from breaking the runtime up into separate packages
• Methods that used to be unexported now need to be exported. That leads to those methods being caught up in the may-implement-an-interface check and kept. Even if they inline at all call sites.
• Keith Randall: Maybe we can do something for internal? Like, auto-nointerface on them?
• Michael Knyszek: Would it make sense to make nointerface explicit?
• Robert Griesemer: These functions are relatively small, but there are a lot of them
• Keith Randall will file an issue with concrete cases, and we can decide if we do anything for 1.24
• Michael Knyszek: Tip vs. 1.23, bent binary sizes have 5% increase

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2024-12-10

• FYI
• Go 1.24 RC1 is scheduled this Thursday (2024-12-12)
• Release blockers
• all: increased toolchain binary sizes #70699
  • Michael Pratt: How much do we care about toolchain binary sizes vs. user binary sizes. For toolchain it looks reasonable to me
  • Michael Knyszek: The bent benchmarks also get bigger. Small binaries got 5-10% bigger.
  • Keith Randall: #70670 is not a big contributor
  • https://perf.golang.org/dashboard/?benchmark=Ajstarks_deck_generate\&platform=linux%2Famd64\&unit=pclntab-bytes
  • One jump is due to FIPS
  • Michael Knyszek: All regressed seem to follow the same pattern.
  • Ian Lance Taylor: Do we want to have a nofips build tag?
  • Keith Randall: Would be nice to verify that helloworld with fmt doesn't import fips, math/rand doesn't import fips. Make sure we don't include fips by accident.
  • Tim King: Could math/rand/v2 import fips?
  • Verified. They don't include fips.
  • Tim King: If we care about the distribution size, it increases 8%
  • Michael Pratt: https://logs.chromium.org/logs/golang/buildbucket/cr-buildbucket/8728996672309418097/+/u/log/0 most increases are small binaries. So it is a fixed-size increase, not a percentage.
  • Removed release blocker
• Dmitri Shuralyov: API audit status?
• Carlos Amedee: This blocks RC1.
• debug/elf: add SHT_GNU_VERDEF section parsing #63952
  • Ian Lance Taylor: Probably need to revamp
  • Dmitri Shuralyov: We can break out this one for after RC1?
  • Ian Lance Taylor: We can also roll back the change and do it in 1.25
• encoding: add AppendText and AppendBinary #62384
  • Ian Lance Taylor: This is just some comment changes

2024-12-17

• FYI
• Next two weeks (Dec 23–Jan 3) are Go quiet weeks
• Go 1.24 RC1 was released last Friday 🎉🎉🎉
• Secondary port breakage
• ppc64 and s390x are newly broken due to FIPS
• Dmitri Shuralyov: We applied broken port policy to windows/arm, as it's been broken for a long time
• For ports that just have a few tests failing, we don't need to declare them broken
• Android/iOS builders
• Corellium builders are missing for a long time
• Run on emulators? Roland made good progress on iOS emulator
• Dmitri Shuralyov: There are still more work to do, got deprioritized. Maybe have the interrupt person prioritize this work. This is more than one week of work.
• Cherry Mui: Would be good to have the emulator work going.
• Cherry Mui: The Android x86 ports are emulators. Can we do the same for arm64?
• Dmitri Shuralyov: They need to be port to LUCI. Need to do some work to start the emulator before all.bash. Wasm builders are much simpler.
• Carlos Amedee: There is some hope as Chrome testing on those
• Dmitri Shuralyov will put info on tracking issues
• Happy holidays! See you next year

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2025-01-07

• Austin Clements: cmd/compile: closure func name changes when inlining #60324
• Closure symbol names are getting incredibly and super-linearly long in the presence of deep nesting, which is much more likely to occur now with range-over-func.
• Alessandro’s proposed fix: go.dev/cl/639515
• Do we want to do RC2? When?
• Dmitri Shuralyov: yes. Many changes, plus some security work. Tuesday or Wednesday next week?
• Michael Pratt: I have hacked up Alan’s stacks tool to extract cmd/compile ICEs from telemetry and file bugs (I filed from the last 30d of telemetry).
• 31 bugs filed, see compiler/telemetry-wins label.
• Lots of them seem related to decoding export data and I suspect are the same, but I was not confident enough to dedup. Summary posted here.
• Remainder are mostly in various parts of SSA.
• These are all in 1.23, not 1.24rc1.
• Ian Lance Taylor: medium priority, not for 1.24. Could be bad code, too.
• Keith Randall: would be nice to know if the code passed type-checking, e.g. Or maybe try running gofmt on the bug input to see if it is vaguely correct Go code.
• Dmitri Shuralyov: note that export data is often involved; perhaps it is stale or out of sync.
• Release notes? Release blockers (#71155)

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2025-01-14

• RC2 status
• Michael Knyszek: Ready to go. To be released on Thursday.
• David Chase: Do we have the write barrier bug fixed?
• Michael Knyszek: No. The branch has already frozen.
• Dmitri Shuralyov: We have the option to rebuild, if we want.
• Write barrier bug #71228
• Fixed now.
• Keith Randall: This can cause weird zombie objects. This may be a possible cause of other weird bugs that we don't understand. I can help look at the code to tell if it is that.
• Better debug mode for write barrier bugs?
• Compiler telemetry wins (cont.)
• Thanks Michael Pratt!
• Unify with watchflakes?
  • Watchflakes running continuously on GCP. Stacks tool currently runs manually.
  • Michael Pratt: Would like to look into it.
• https://github.com/golang/go/issues/70399#issuecomment-2589049515 related to the crashes?
  • Tim King: Looks like watchflakes and stacks report the same bug?

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2025-01-21

• RC3 schedule: tentatively planned on Feb 4 (Tue)
• Tree reopening: tentatively planned on Jan 28 (Tue)
• Michael Pratt: Once the tree reopens, CLs that are for 1.24 need to be cherry-picked to the release branch
• Any early-in-cycle changes to land? (Tracking issue go.dev/issue/70525.)
  • Michael Pratt: Did we update the early-in-cycle process? Probably don't matter much as we don't have many
  • Dmitri Shuralyov: If something can be submitted later in cycle and not cause merge conflict, it is always an option to submit later
  • David Chase: DWARF 5 probably won't cause much conflict. Also not caught up on review
• Tim King: The noder CLs need a new owner/investigation https://github.com/golang/go/issues/71253 . can help the rest of the week.

2025-01-28

• Tree reopening
• Carlos Amedee: The tree Reopens on Wednesday 2025-01-29 (after release blockers land).
• runtime: jsoniter stack corruption with 32-bit arches, potential GC issues with 64-bit arches #71408
• Michael Pratt: Reflect2 defines its own mapiter type that passes to mapiter* runtime functions.
• Michael Pratt: Have the linknamed functions store a real map iter pointer to their mapiter type. Linkname functions are just wrappers. Users other than linkname don't get performance overhead. One CL is submitted, the other ready to land.
• Michael Pratt: This could also be good pattern to other linknames.
• Michael Pratt: Reflect2 is unmaintained, jsoniter is also unmaintained, but widely used. K8s wanted to move out of jsoniter, but stalled.
• Ian Lance Taylor: There are some activities on json/v2. Hopefully it will land in 1.25.
• io: Copy to a pipe prevents process exit (Go 1.24rc2 on Linux regression) #71375
• Michael Pratt: os.File has an optimization that uses copy_file_range syscall, but it doesn't work in some cases. A workaround is to use sendfile. Kernel has a bug for sendfile on pipes, which locks the pipe and prevents closing the pipe.
• Revert (https://go.dev/cl/644895) or limit to regular files (https://go.dev/cl/644935)?
• Fix-forward fixes the pipe bug. Unsure if there is any other bug.
• Is using sendfile (only) as a fallback even worth doing?
• Revert is preferred
• Robert Griesemer: What is the status of the release notes?
• Carlos Amedee: Complete. Just needs to remove the "draft".
• Public office hours
• Previous one was early Nov. Next would be Feb.
• Robert Griesemer: Do it after the release? Or after tree open?
• Keith Randall: After tree open is good.
• Cherry Mui: Find a time next week.
• Carlos Amedee: The gomote access approval process has changed.

2025-02-04

• FYI
• Go 1.25 tree is open
• Public office hours scheduled on this Thursday Feb 6, 12:30 PT/3:30pm ET
• 1.24 RC3 is planned to be released tomorrow
• 1.24.0 is planned to be released next week
• Robert Griesemer: For removing core types, I did another change of the spec (https://go.dev/cl/645716), removing the notion of core types, but doesn't change anything else. Just spell out the restrictions that used to refer to core types. We can land this without changing tools. Going forward, if we want to generalize e.g. range, slice, we can open small specific proposals.
• Keith Randall: need tooling changes. Worried that it might take longer for the specific ones than this big one. For each of these future changes, we still need tooling changes. Worried that it might take longer for the specific ones than this big one.
• Keith Randall: The build dashboard does not look great. Most arm64 builders fail with bzr failures.
• Dmitri Shuralyov: LUCI change: Python 3.8 is being replaced with Python 3.11 on all Buildbot builders.
• Dmitri Shuralyov: We can send a test skip for now.

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2025-04-01

• FYI
• Likely accepted proposal: hash: standardize the hash function #70471
• Likely accepted proposal: testing: structured output for test attributes #43936
• Related active proposal: testing: store test artifacts #71287
  • Dmitri Shuralyov: It would be great for us to use them on LUCI
  • Michael Knyszek: Enable core dumps for binary crashes is one use case. Execution tracing and pprof tests currently exporting "artifacts" as text. It would be helpful to use artifacts for them.
  • Michael Knyszek: Ideally if all tests use Outputdir for things locally, LUCI can get it
• Go 1.24.2 and Go 1.23.8 are released today.
• Status updates

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2025-04-15

• [Dmitri Shuralyov] Windows, macOS, Linux support check-in for Go 1.25
• Windows support timeline
  • Anything to pre-announce in 1.25 release notes? Carlos Amedee found that https://www.microsoft.com/en-us/windows/end-of-support has an Oct 2025 date, but there are likely various other longer support windows (some until 2032). (context)
  • Probably want to wait for multi-project alignment (similarly to 7/8.1); unlikely that support costs or lack of users would happen before then.
• Minimum Linux kernel
  • Staying with the 3.2 minimum that was recently bumped in Go 1.24, unless there is significant new information.
• FYI: macOS 12 becomes new minimum in 1.25 (doc/go1.25#darwin)
• [Keith Randall] Should darwin/amd64 still be a first-class port?
• [Michael Pratt] Rudimentary data of cmd/compile reports
  • 818 darwin/amd64
  • 5932 darwin/arm64
  • 1 linux/386
  • 2731 linux/amd64
  • 2 linux/arm
  • 26 linux/arm64
  • 21 windows/386
  • 2123 windows/amd64
  • 2 windows/arm64
• It still looks fairly popular. It is unclear when Apple will drop AMD64 for macOS.
• Cherry Mui: If we demote it, unclear to me what actions we'll do. Who will maintain it? Do we remove it if it is broken?
• Dmitri Shuralyov: If we demote, we'll remove installation instructions, and we can ship release with a broken port. Sounds like we don't want to do it for darwin/amd64 for now.
• Michael Pratt: Even when Apple drop AMD64 for macOS, we'll probably get user request to keep the port.
• [Austin Clements] hash: standardize the hash function #70471 accepted.
• How are we going to address the escape performance issue this will cause: cmd/compile: generic function argument causes escape to heap #48849?
• Keith Randall: Plan to look at it. Probably not for 1.25.
• #70471 is establishing a convention
• Robert Griesemer: Would like to use it for the type checker. Not a rush, though.
• [Keith Randall] How many bits of tag are we comfortable with in our lock-free linked list?
• 57-bit address on amd64 is coming
• https://github.com/golang/go/issues/49405
• One solution is to drop bits of tag from 19 to 10. Some other ports have already done that.
• A collision on tag bits would be really bad (could lead to mark work buffers being lost).
• Michael Knyszek: We could start using double-word CAS if one wants to use 57-bit.
• Keith Randall: Some other platforms already use smaller tags, RISCV and S390X,
• Michael Pratt: Linux supports 57-bit VA as well, but needs to opt-in. FreeBSD is on by default.
• Keith Randall: For 1.25, we can tell FreeBSD to not use 57-bit VA. For the future, we may use double-word CAS.
• Michael Knyszek: If we go down the double-word CAS route, we need to do 16-byte alignment. Should be easily doable.

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2025-05-06

• FYI
• 2 weeks until the freeze.
• proposal: all: add bare metal support #73608
  • New attempt for a GOOS=none proposal
  • They have a package in Go that provides things the runtime need
  • Michael Pratt: They need to write code at runtime start, without allocation. They need a "stable" set of the language to do that. It is weird that a port doesn't have compatibility.
  • Michael Knyszek: It seems okay we change this API from release to release. It is sort of a framework for adding ports. We can "support" and document the API, but we can also change it as needed. They should be testing against tip, for out of tree ports. It is similar to debug call.
  • Michael Knyszek: Any code they have without an M? Do they also depend on nowritebarrier, nosplit, etc.
  • Filippo mentions that this is testable with QEMU
• Active proposal: runtime: CPU limit-aware GOMAXPROCS default #73193
• Green Tea GC: Code is all in. Off by default behind a GOEXPERIMENT.

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2025-05-13

• FYI
• 1 week until the freeze (next Wednesday 11:59pm ET)
• Likely accepted proposal: testing/synctest: new package for testing concurrent code #67434
  • func Test(t *testing.T, f func(*testing.T))
• 1.25 release
• cmd/compile: slow escape analysis in large package in the typescript compiler #72815
  • Hope to get this addressed in Go 1.25. Is there anything we need to do besides CL 657179?
• Keith Randall: Stack allocation for slices: one more CL to get in
• Michael Knyszek: Land the fix for freeIndexForScan? There is one case that we could omit zeroing the memory. That CL spawns the discussion about the safety of freeIndexForScan. For the omit zeroing CL there is an atomic elsewhere, for the large object case.
  • Keith Randall: Happy to land.
  • Michael Knyszek: Not seeing any crashes for now. The worst case is that the GC sees uninitialized memory for a new object. Won't cause memory corruption. The GC might crash.
  • Michael Knyszek: Loading freeIndexForScan is not a dependent load, because the pointer to be scanned comes from nowhere. Keith Randall and I thought about making freeIndexForScan atomic, and incrementing it works as a memory barrier. Might be able to use a weaker barrier, but that is subtle.
  • Michael Knyszek: Should we backport omit zeroing? This causes some services use 25% more memory and OOM
  • Keith Randall: Not a correct issue, just omitted optimization.
  • Cherry Mui: We could consider backporting after waiting some time
• Junyang Shao: cmd/compile: memcombine doesn't combine simple chain #72832: one CL to land

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2025-05-20

• Review build dashboard
  • Power8: Dmitri Shuralyov: Its git version may be too old
  • Perf builder: Michael Knyszek: perfdata being DoS'd, believed to be AI crawlers
  • Windows/arm64: cmd/link.TestIssue33979 failing. Cherry Mui will take a look
  • ASAN/MSAN/race/noopt builders need fix, for an allocation test
    • Keith Randall: The noopt detection not working correctly for some tests. Have a fix.
• Status
• Review release blockers
• Carlos Amedee: Flight recorder is in flight. Pretty safe to land close to the freeze.
  • Michael Knyszek: Yes, mostly new API, barely touching existing code.
• Want to get CL 657179 in. David Chase has a followup CL.

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2025-05-27

• 1.25 status
• runtime: autogenerated frames not being skipped in CallersFrames #73747
  • Keith Randall: We inline the tail call itself, but not a function that contains a tail call
  • Cherry Mui will take a look at the CL
• Flight recorder is in
• synctest is in, pending bug fixes/improvements
• Please help write release notes #71661
• https://tip.golang.org/doc/go1.25
• Public office hours. The last one is in Feb. Plan for one next week.
• Review performance dashboard
• ParseBigBytes-88 (linux/amd64)
  • Michael Pratt: Most commits are related to math/big. This is a Gonum benchmark that uses math/big.
• ParallelizeUntil/pieces:1000,workers:10,chunkSize:1-88 (linux/amd64)
  • Apparent regression from CL 674515
• Didn't finish, will continue next week.

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2025-06-03

• FYI
  • Public office hours: this Thursday June 5, 1pm PT/4pm ET
• 1.25 status
  • RC1 is scheduled next week, we'll start prebuild later this week
  • Release notes
    • spec: remove notion of core types [Robert Griesemer]
    • cmd/link/internal/ld: introduce -funcalign=N option [Cherry Mui]
  • Release blockers
    • 73932 and 73931 can be after RC1
  • Compiler/runtime issues
    • Fix or punt
• runtime: autogenerated frames not being skipped in CallersFrames #73747
  • Cherry Mui: Got down to a rabbit hole of issues with defer/recover/wrapper behaviors, #73916, #73917, #73920. Three similar bugs introduced in Go 1.18, 1.20, and 1.22. CL 650455 (happens to) fix 73920, but (one of) the proposed fix of 73747, CL 675916, reintroduced it. CL 677675 is a new attempt.
    • Options for 1.25
      • 1. Continue getting CL 677675 submitted
      • 2. Revert CL 650455
      • 3. Submit CL 675916, which fixes 73747 but reintroduces 73920
    • Keith Randall: Reverting CL 650455 is the safest.
    • Cherry Mui: Maybe revisit/redesign how defer/recover works with wrappers entirely. Not for 1.25.
• Keith Randall: getting rid of Duff devices? CL 678175
  • golang-dev thread
  • Seems generally positive, except possibly with some of the large copies
  • The CL can be even better
  • This makes things simpler, and fixes the frame pointer issue
• Review performance dashboard (cont.)
  • Michael Knyszek did offline

Comment From: cherrymui

These compiler and runtime meeting minutes are a snapshot of what was discussed in an internal Google meeting. Notes on agenda items that address Google specific needs are elided. Any comments on this issue will be removed, and discussion about topics raised should be taken to the appropriate mailing list. Additionally, any feedback or suggestions for additions to the notes should be handled there as well.

2025-06-10

• FYI
• Go 1.25 RC1 is to be released today, or tomorrow. Pending some issues in API audit.
  • Robert Griesemer: It is okay to not do EmbeddedFieldKind in 1.25. We can do it later.
• Status updates
• Memory regions
• Cherry Mui: synctest, regions, and crypto random reader all have some bubble-ish feature.
• Michael Knyszek: Sharing a region with multiple goroutines is hard. Not sure how to do it with low overhead. You'd also need a mechanism like synctest.Wait to synchronize the group of goroutines. We might be able to do it in a way that is compatible with the current region API.
• Cherry Mui: Iterator coroutines could be a use case for sharing regions