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

 focus on

"The Script House

” , with millions of developers

Reprinted with the authorization of the original official account

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 ^[1] ".

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 atomicity, not any of the looser forms found in other languages.

Also with 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.
• Records 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", which 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 ^[2]》
• " Programming Language Memory Models ^[3] "
• 《Updating the Go Memory Model ^[4]》

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 ^{[5] .}

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 Go 1.19, build constraints unix are now recognized in the //go:build line , which can act as matching constraints.

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 and became 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 has been released to v3 and will be available in 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 table ^[6] 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 GOARCH=amd64and GOARCH=arm64changes.

Runtime

heap memory limit

New versions of Go have added runtime.SetMemoryLimitfunctions and GOMEMLIMITenvironment variables.

Note that runtime.SetMemoryLimitfunctions provide 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 ), the soft memory limit will be respected.

With the memory soft limit, in general scenarios, it can effectively prevent the Go process from being KILLed beyond the maximum amount of 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 ^[7] ", which involves making a scope of type parameters in method declarations. Very small 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 as a small version, with some small "pits" filled in, and the answers to individual domestic interview questions will also be changed accordingly.

References