Go1.19 Those things: How much do you know about new features such as domestic chips and memory models?

Hello everyone, I am fried fish.

I feel that time has passed quickly, Go1.18 has not been released for a long time, and generics are still in full swing. Looking at the last voting results, most of the students have not yet applied generics in the production environment.

No, Go1.19 Beta1 has been officially released. Today, Jianyu and everyone will be watching some interesting features in " Go 1.19 Release Notes ".

memory model

Go's memory model has been revised to align Go with the memory model used by C, C++, Java, JavaScript, Rust, and Swift. Go only provides sequentially consistent atomics, not any of the looser forms found in other languages.

In addition to the memory model update, Go1.19 introduced new types in the sync/atomic package to make it easier to use atomic values, such as atomic.Int64 and atomic.Pointer[T].

The document has made the following specific changes:

• Documents Go's overall memory model description.
• Log multiword races that cause crashes.
• Document the happens-before of runtime.SetFinalizer.
• Log (or chain) before more sync types occur.
• Record when synchronization/atoms occur, matching sequentially consistent atoms in C++ (and Java, JavaScript, Rust, Swift, C...).
• Document disallowed compiler optimizations.

This is just a "revision" that changes the documentation and definitions, and does not involve code changes to the memory model.

To this end, Russ Cox wrote three articles on the Go Memory Model as a series of instructions:

• 《 Hardware Memory Models 》
• " Programming Language Memory Models "
• 《 Updating the Go Memory Model 》

Interested students can read.

document specification

Russ Cox added support for links, lists, and clearer headings in doc comments in the proposal Proposal: go/doc: headings, lists, and links in Go doc comments .

The Go 1.19 documentation has changed. as follows:

Comparison of old (left) and new (right).

Manually paste the link to jump:

Manual branching becomes an unordered list distinction:

This is a big upgrade for Go documentation from ancient times to the new Markdown.

build constraints

As of Go1.19, build constraint unix can now be recognized in line //go:build , which can act as a matching constraint.

The format is as follows:

 //go:build unix

It should be noted that in version 1.19, if GOOS is one of aix, android, darwin, dragonfly, freebsd, hurd, illumos, ios, linux, netbsd, openbsd or solaris, it also satisfies the unix constraint.

Godson architecture

Loongson is a series of various chips (including general-purpose central processing units, SoCs, microcontrollers, chipsets, etc.) designed by the Institute of Computing Technology of the Chinese Academy of Sciences, Loongson Zhongke, Shenzhou Loongson and other institutions and companies.

Support for the Loongson 64-bit architecture on Linux was added in Go 1.19 (GOOS=linux, GOARCH=loong64).

Some time ago, I also saw that Godson Zhongke was listed on the Science and Technology Innovation Board, becoming the first domestic CPU stock. The introduction of domestic chips into the Go language should also be promoted by the Chinese people, too strong!

race detection

Go's race detector (race detector) has been released to the v3 version and will be available for production along with Go1.19.

Compared to the v2 version, the new version of the race detector is 1.5x to 2x faster in performance, uses half the memory, and supports an unlimited number of goroutines.

Note: windows/amd64 and openbsd/amd64 are not supported yet.

Switch performance improved

The Go compiler now uses jump tables to implement swicth statements for large integer and string types. Performance improvements for switch statements vary, but can be around 20% faster.

Note: This time only involves the changes of GOARCH=amd64 and GOARCH=arm64 .

Runtime

heap memory limit

The new version of Go adds runtime.SetMemoryLimit functions and GOMEMLIMIT environment variables.

Note that the runtime.SetMemoryLimit function provides a soft limit on memory for the runtime.

The function signature is:

 func SetMemoryLimit(limit int64) int64

With this soft memory limit, the Go runtime will honor this memory limit by adjusting the frequency of garbage collections, returning memory to the underlying system more aggressively, etc. to maintain this soft memory limit.

In addition, even if GOGC=off (or the SetGCPercent(-1) function is executed), the soft memory limit will be obeyed.

With the memory soft limit, in general scenarios, it can effectively prevent the Go process from being KILLed beyond the maximum system memory resources due to excessive heap memory allocation.

A fish that slips through the net is unstoppable. That is, it does not include: space used by the Go binary and memory outside of Go, eg: memory managed by the underlying system on behalf of the process, or memory managed by non-Go code in the same process (CGO).

Goroutine stack

In the new version, the Go runtime will allocate the initial goroutine stack based on the goroutine's historical average stack usage (fog, too bad, the answer to the Go interview question has to be changed again...).

It can effectively avoid some unnecessary stack growth and copying, and in the case of lower than average, it can save up to 2 times the space waste.

This is a more detailed optimization point.

Generic improvements

Go1.19 is still on the way to improve generics. This change comes from the specification " spec: adjust scope of type parameters declared by method receivers ", which involves making a very small scope of type parameters in method declarations Correction.

Original description:

The scope of an identifier denoting a type parameter of a function or declared by a method receiver is the function body and all parameter lists of the function.

Revision description:

The scope of an identifier denoting a type parameter of a function or declared by a method receiver starts after the function name and ends at the end of the function body.

In Go 1.18, the following generic code will throw an error:

 type T[T any] struct {}

func (T[T]) m() {} // error: T is not a generic type

In the new version (1.19 onwards) it will be supported correctly without compilation errors.

In terms of other generic progress, it is still tinkering:

It remains to be seen.

Summarize

In this new version update of Go1.19, there are relatively few new features. The main reason is that the work of generics has brought a lot of workload to the Go team.

This year, some big guys have left one after another, so the overall time available for other new features is relatively small.

This version can be considered a small version, with some small "pits" filled in, and the answers to individual domestic interview questions will also be changed accordingly.

The article is continuously updated, you can read it on WeChat by searching [Brain Fried Fish]. This article has been included in GitHub github.com/eddycjy/blog . To learn Go language, you can see the Go learning map and route . Welcome to Star to urge you to update.

Go Book Series

• Introduction to the Go language series: a preliminary exploration of the actual combat of the Go project
• Go Programming Journey: Deep Dive into Go Projects
• Go Language Design Philosophy: Understanding Go Why and Design Thinking
• Go Language Advanced Tour: Go deeper into the Go source code