Tree status for the Go 1.24 release and Go 1.25 development

[Carlos Amedee]

Hi Gophers,
Go 1.24 will soon be scheduled for release (🎉!) and as described on https://go.dev/s/release, it's time to plan for Go 1.25 development. Tentatively, we expect a soft reopening (for fixes only, not new features yet) later this week, and a full general tree reopening shortly thereafter. Please see the tracking issue 70525 for the latest tree status.

Please use this thread to discuss your own plans for the 1.25 development cycle and to coordinate submission.

(Reminder, this thread is for things you *PLAN TO DO YOURSELF*, not things you want other people to do.)

If you plan on working on potentially risky changes, please follow our guide in the wiki.

Thanks,
Carlos for the Go team

[Michael Pratt]

For 1.25, I plan to look at follow-up map performance improvements, most notably maps in cold cache (https://go.dev/issue/70835). This may also involve reevaluating whether we should change the key/value layout back, which would impact https://go.dev/issue/71368.

I also plan to look at Go application scalability (large machines/high GOMAXPROCS) more generally, looking at runtime/application contention, NUMA effects, etc. Some specific priorities include pushing container-aware GOMAXPROCS (https://go.dev/issue/33803) forward and fixing runtime scalability issues like the epoll scalability issue (https://go.dev/issue/65064).

It's minor, but as a follow-up to https://go.dev/issue/71395, I'd like to see if we can eliminate asancall/msancall/racecall and simply replace them with asmcgocall for better maintainability.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-dev/CAD7Aq3QcMEYZJ4mN1smevO2f0tbOcW%3D5JxooW5CxmsQFff6Otw%40mail.gmail.com.

[Alan Donovan]

For go1.25 I plan to make the go/ast tree record comments in the tree instead of a side table (https://go.dev/issue/20744). (I realize I've been saying this for so long that it is becoming comical.)

Most of my other work will be in x/tools and not coupled to Go releases.

[Nick Ripley]

For Go 1.25, I have two frame pointer vet check improvements ready to land as part of go.dev/issue/69838: basic arm64 support (go.dev/cl/635338), and checking past conditional branches (go.dev/cl/640075). Cherry also suggests trying to make the check work on package runtime (currently the check hard-codes skipping runtime). I'll give that a shot as well.

[Damien Neil]

For 1.25, I plan to add the remaining os.Root methods that didn't make it into 1.24 (https://go.dev/issue/67002). I also want to look into taking advantage of platform-specific APIs such as Linux's opanat2 or Darwin/FreeBSD's O_NOFOLLOW_ANY where possible to improve os.Root performance.

I also plan to work on the testing/synctest experiment (https://go.dev/issue/67434). I expect there will be some relatively minor changes to behavior (see my last update on #67434), and we'll evaluate where to go next mid-cycle when (hopefully) we have more feedback.

Time permitting, it'd be nice to finally bring x/net/http2 into std.

- Damien

[Robert Griesemer]

For Go 1.25 I hope to remove the notion of core types from the spec (issue #70128), initially probably by just replacing the concept in the spec with explicit prose, and w/o making any actual language changes. The rest will be mostly maintenance and tools work.

--

[Michael Knyszek]

For Go 1.25, I plan to work primarily on garbage collector performance, specifically in the mark/scan area. Our goals are better CPU scalability, better locality, and better use of CPU hardware. (Based on experiments and a design by Austin last year, more details to follow once it takes shape.)

I also hope to make progress on a value sharding API (in the vein of the discussion at https://github.com/golang/go/issues/18802).

As for smaller things, I've got some changes out for review to clean up the execution tracer and its parser to make it easier to use (for runtime hacking), and I'd also like to make some tweaks to the trace parsing API (https://github.com/golang/go/issues/62627) to get it in better shape for stabilization.

If I have time, I may also take some steps toward a prototype of memory regions (https://github.com/golang/go/discussions/70257).

--

[Than McIntosh]

For 1.25, I plan to upgrade the Go compiler+linker to generate DWARF version 5 (as opposed to the current scheme of V2 for .debug_line and V4 for .debug_info). Work in progress stack at https://go-review.googlesource.com/q/topic:%22dwarf5%22 .

- Than

On Wednesday, January 29, 2025 at 4:02:06 PM UTC-5 Carlos Amedee wrote:

[Alessandro Arzilli]

I was hoping to solve the problems with closure naming and inlines
(http://go.dev/issue/60324) either with https://go.dev/cl/639515 which
separates symbol names from the names shown to users or with something along
the same lines but less ambitious.

On Wed, Jan 29, 2025 at 04:01:38PM -0500, Carlos Amedee wrote:
> Hi Gophers,
> Go 1.24 will soon be scheduled for release (🎉!) and as described on
> https://go.dev/s/release, it's time to plan for Go 1.25 development.
> Tentatively, we expect a soft reopening (for fixes only, not new features
> yet) later this week, and a full general tree reopening shortly thereafter.

> Please see the tracking issue 70525 <https://go.dev/issue/70525> for the

> latest tree status.
>
> Please use this thread to discuss your own plans for the 1.25 development
> cycle and to coordinate submission.
>
> (Reminder, this thread is for things you *PLAN TO DO YOURSELF*, not things
> you want other people to do.)
>
> If you plan on working on potentially risky changes, please follow our

> guide in the wiki <https://go.dev/wiki/RiskyChanges>.

>
> Thanks,
> Carlos for the Go team
>

[Cherry Mui]

Hi Gophers,

The tree is now open for general development of Go 1.25. It will remain open until the freeze begins on May 21st at 11:59 PM Eastern time. As you submit your changes, please keep an eye on the build dashboard (https://ci.chromium.org/p/golang/g/go-gotip/console or build.golang.org) and consider waiting if there's a widespread test failure.

Any CLs that land after CL 646155 ("internal/goversion: update Version to 1.25") but target go1.24.0 must be cherry-picked to release-branch.go1.24. Cherry-pick CLs can be created following the same steps as usual but do not need a backport issue or approval from the release team. Please continue to use your judgment about what should be included this late in the Go 1.24 release cycle.

Thank you, and happy development!

Cherry for the Go team