Go 1.11 planning

[Brad Fitzpatrick]

We plan to open the tree for new development soon. (details later)

But it's time to do this regular planning thread.

What do people plan to do this cycle for Go 1.11? (you have less than three months of development time before the freeze ~May 1st)

The usual reminder: this is for what YOU are going to do, not what you want others to do.

If there are big pending CLs or branches ready to merge we want to coordinate the order they land in to minimize merge pain. Speak up if you have something that should get merged earlier.

Thanks!

-- Brad (on behalf of the Go team)

[Audrius Butkevicius]

I still want to get the ListenControl and net.Dialer.Control hooks done, yet this is very small and insignificant on the grand scheme of things.

[Keith Randall]

- Changing the way system calls happen in Darwin, issue 17490.  Call into libSystem instead of doing raw system calls (similar to the Solaris port).

- A fix for issue 22350, which involves having "objects" on the stack which get scanned like the heap does.

- Some better aggregation of rewrite rules, which will make using complicated addressing modes easier (mostly benefitting non-RISC architectures). See CL 86595.

- Still trying to figure out how to handle large structs and arrays better in SSA.

None of these need to go in early.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sangjin Lee]

I'd like to lobby for the pluggable http client connection pool (issue 22537). There hasn't been much movement, but this would address a number of requests for the http client.

Sangjin

[Brad Fitzpatrick]

Again, this isn't a thread for asking other people to do stuff. This thread is specifically about what people are already planning on doing for the next cycle.

[Austin Clements]

I plan to merge the series to add NOFRAME to all LR architectures early, since it touches a lot of assembly: golang.org/cl/92035

Other series I plan to merge, but don't have to be right away (most of these are under review right now):

* Support for sparse heaps (eliminates heap size limit and flakes from address space conflicts in mixed binaries, simplifies a bunch of bug-prone code): golang.org/cl/85887

* Support for the buffered write barrier on all arches: golang.org/cl/92696

* Modifications to make the branch elimination "prove" pass use unsatisfiability (makes it simpler and more powerful): golang.org/cl/87478

I'm planning to work on support for safe-points everywhere. This lays the groundwork for zero-cost non-cooperative preemption as well as support for limited function calls from debuggers (e.g., calling String methods to print a value from a debugger). If that goes particularly well, I might get to non-cooperative preemption in the 1.11 time frame, but I expect that to have a long bug tail, so it may not be lit up until 1.12. I have a proposal/design document for this that I'll send out early in the cycle.

I'm hoping to submit a runtime/debug.SetMaxHeap API for handling heap limits: golang.org/cl/46751. The code's ready, but we're working on getting feedback from production use to make sure it's a good solution to the problem before we commit to the API.

Things I hope to get to, but we'll see:

* sync.Pool improvements (golang.org/issue/22950)

* Better memory scavenging (golang.org/issue/16930)

​

[Devon H. O'Dell]

I'm hoping that the x/tools/godoc change to list Go versions for
functions/methods/types can be added: golang.org/cl/85396 -- perhaps
we can figure out how to constants and variables as well during this
cycle.

2018-02-08 14:17 GMT-08:00 'Austin Clements' via golang-dev
<golan...@googlegroups.com>:

> --
> 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.

[matthe...@gmail.com]

If time allows (it may not) I’ll look at writing new unit tests for the standard library and related to types+concurrency+GC.

Matt

[Carlos Eduardo Seo]

Right now, I have in my list:

 

• Implement better atomics for ppc64x
• Additional fixes for the ppc64x assembler
• Performance optimizations using POWER9 instructions
• Make the race detector work on ppc64x

--

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.
For more options, visit https://groups.google.com/d/optout.

[David Chase]

Debugging:

Improving line number assignment for debugging (plumb is_stmt through DWARF, then figure out best settings for it).

Whatever additional work is needed for location lists (Heschi has been working on this, I think he wants to be rid of it) and scopes in optimized code.

Performance/compiler:

Decouple block order from register allocator order (old CL, https://go-review.googlesource.com/c/go/+/47314 ).

Be sure Ilya Tocar's CL is finished and in.  It reduces cost of the check-based loop-preemption change (https://go-review.googlesource.com/c/go/+/84055 )

Possibly work with Austin to add some targeted pattern-matching to his improvements to prove.

Possibly revisit loop-invariant code motion (it needs tuning, even on risc architectures)

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe@googlegroups.com.

[Russ Cox]

Go command:
I need to add support in 'go list' for tools to find out information about go packages they want to analyze, including being able to ask for cgo-generated output sources and the location of up-to-date package objects. Then we will need to make tools use this information. Once tools can be relied upon to use this information, we can stop writing package objects to $GOPATH/pkg in most builds. (As usual, shared libraries and other build modes are exceptions to this.) Probably Go 1.11 will still write package objects to $GOPATH/pkg, but maybe we can stop that in Go 1.12. I will also try to teach the go command a little about package versions.

[lab...@gmail.com]

I hope to finish up these issues:
#23731
#22496
#21348

Determine whether #14935 is worthwhile or close it.

Possibly add improved implementation for math.Round, Float32bits, Float32frombits, and some math/bits.
Watching with interest other changes in the community that should help ppc64le: mid-stack inlining, register-based argument passing, loop optimizations. Do some investigation to verify they are helping as expected for ppc64le.

[mrosier.qdt]

My team and I plan to continue contributing ARM64 enhancements and optimizations.  Here are a few of our patches that are currently outstanding:

[CL88355] cmd/compile/internal/ssa: add patterns for arm64 bitfield opcodes

[CL88295] cmd/compile: make math.Abs/Ceil/Floor/Round/Trunc instrinsics on arm64

[CL88915] benchstat: add support for sorting benchstat output.

[CL91415] cmd/compile: remove nil checks based on offsets from known non-nil pointers

[CL92617] testing: add option for running benchmarks a fixed number of iterations.

[CL92715] cmd/compile: generate tbz/tbnz when comparing against zero on arm64

[CL82055] runtime: improve arm64 memclr implementation.

[CL90835] cmd/compile: arm64 intrinsics for math/bits.OnesCount

 

Cherry, Wei and others have provided lots of great feedback (we very much appreciate your efforts!!), but most of these still need formal approval for acceptance into the 1.11 release.  We have a few more patches in the works and will post them once they’re in reasonable shape.  One of the major deliverables we’d like to see get into the 1.11 release is a pass that generates more ldp/stp instructions for ARM64.  We have a working patch, but Geoff is still analyzing the performance results.  Lastly, we noticed the following patch authored by David Chase: [CL28832] cmd/compile: prototype/experiment for register args and results.  We would be interested in seeing this work land and would be very willing to review and assist with the development/testing of this patch.

 

Regards,

  Chad

[moeh...@google.com]

None of these needs to be merged before go1.11 tree is generally open.

For go1.11 I like to work on:

• optimizations and specialisations of runtime make and grow routines (makemap, makeslice, growslice, ...)
  
• for performance and binary size as well as better checking of overflow conditions
• part of this will likely involve adding some runtime math intrinsics that return if overflow occurred for a math operation (in development cl/91755)
  
  
• improving processor capability detection
• merge/unify the runtime and internal/cpu processor capability detection
• add an environment variable to disable cpu capabilities used by Go during runtime (could be used for testing and benchmarking) #15403
  
  
• these Github issues:
• #21639 runtime: apply strength reduction optimizations to generic map routines
• #21266 cmd/compile: detect and optimize slice-extending idiom append(a, make([]T, n)...)
  
• #20138 cmd/compile: recognize map-clearing range idiom
  
• #12518 strconv: strconv.ParseFloat should accept 'p' notation for binary exponents
  
  
• generally performance/size improvements to std lib, runtime and compiler where I find hot code paths/oppertunities

[Kunpei Sakai]

For go-1.11, I've been working on the following CLs:

- cmd/compile: make slice of runes accept to be converted from defined type derived from string  (Issue23298, CL87695)

- cmd/compile: avoid unexpected changing untyped bool by evconst (Issue23414, CL91316)

- testing: don't overwrite error unless parent of subtest is finished (Issue22882, CL87835)

Also, if possible, I'd like to decide the conclusion on what to do as an API design at the next issue. I can implement that if it's decided.

Issue19917

Also, although there is no direct relationship with go-1.11, I'm planning to fix the implementation of x /net/html which deviated greatly from the specification of w3c html-5.

First Step: CL83075

Thanks.

2018年2月9日金曜日 4時49分37秒 UTC+9 Brad Fitzpatrick:

[Daniel Martí]

I'd like to give some love to text/template in this cycle. For example:

https://golang.org/issue/10608
https://golang.org/issue/21171
https://golang.org/issue/18716

I also have a few vet tickets/CLs open (had more, but some were merged
in for 1.10):

https://golang.org/cl/79536
https://golang.org/issue/22851
https://golang.org/issue/23539

I'd also like to help with the compiler, but for now only picked up
https://golang.org/issue/22822. Suggestions welcome.

Lastly, since stringer now generates code using strconv instead of
fmt (https://golang.org/cls/+/77473), it is now possible to use it in
more packages in the standard library such as html/template and
debug/dwarf. The first such CL is https://golang.org/cl/77253.

[Wei....@arm.com]

For engineers from Arm, we have at least following list:

1. arm64 performance optimisation (Qualcomm team also works on it)

2. arm64 Go assembly instruction manual 

3. tools (memory sanitizer, race detector) enabling on arm64

4. linker improvement on arm64

5. finish other outstanding patches such as CL61511 and CL81877

Thanks

Wei Xiao

[Lee Rick]

could you support map output orderly by key or value or filed of value.for example type s struct{a string, b int};  m := map[int]s; m[1] = s{"aa", 1}; m[2] = s{"bb",2}; need a slice sli, sli = [{"aa",1},{"bb",2}], make m call some inner function directory to be sli sli = [{"aa",1},{"bb",2}] instead map to a slice, and sort the slice.

在 2018年2月9日星期五 UTC+8上午3:49:37，Brad Fitzpatrick写道：

[Brad Fitzpatrick]

Lee,

See the first email in this thread, which says: "The usual reminder: this is for what YOU are going to do, not what you want others to do.".

--

[Brad Fitzpatrick]

On Sun, Feb 25, 2018 at 6:50 PM, <Wei....@arm.com> wrote:

For engineers from Arm, we have at least following list:

1. arm64 performance optimisation (Qualcomm team also works on it)

2. arm64 Go assembly instruction manual 

3. tools (memory sanitizer, race detector) enabling on arm64

4. linker improvement on arm64

5. finish other outstanding patches such as CL61511 and CL81877

Wei, do you feel like you have enough attention from the Go team reviewing things?

I suspect Cherry is the main reviewer?

Please ping aggressively on CLs if you feel they're being neglected. We don't want your arm64 stuff to slip past Go 1.11.

[Benny Siegert]

I would like to upstream the patches for NetBSD-ARM that we have in pkgsrc and (hopefully) provide an ARM builder.

--

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.

[ron minnich]

I'll be working on go in firmware environments, trying to fix the small nits I keep hitting. And trying to get a builder up, since companies are getting ready to ship firmware that uses u-root we need to keep on top of what minimal config variables are needed to keep things working.

one question: the signature for syscall.Reboot(int) is really not right. It should be uint32. Some of the reboot constants have the high bit set so on arm if you do a simple

syscall.Reboot(sycalls.LINUX_REBOOT_CMD_HALT)

you get a compiler error. It seems a little silly to have to cast in that code; but if we change it would that be considered breaking some compatibility promise?

thanks

ron

[Tobias Klauser]

On Wednesday, 28 February 2018 22:43:10 UTC+1, ron minnich wrote:

I'll be working on go in firmware environments, trying to fix the small nits I keep hitting. And trying to get a builder up, since companies are getting ready to ship firmware that uses u-root we need to keep on top of what minimal config variables are needed to keep things working.

one question: the signature for syscall.Reboot(int) is really not right. It should be uint32. Some of the reboot constants have the high bit set so on arm if you do a simple

syscall.Reboot(sycalls.LINUX_REBOOT_CMD_HALT)

you get a compiler error. It seems a little silly to have to cast in that code; but if we change it would that be considered breaking some compatibility promise?

I'm not sure whether we can change it in the syscall package. As I read https://golang.org/doc/go1compat#operating_systems we might be able to change it. Brad or Ian will know for sure though :)

However, we can certainly change Reboot in golang.org/x/sys/unix which is what should anyway be used by code outside of the standard Go repository. Please see the NOTE in src/syscall/syscall.go (https://github.com/golang/go/blob/master/src/syscall/syscall.go#L21-L28) and https://golang.org/s/go1.4-syscall

Thanks

Tobias

[Brad Fitzpatrick]

On Thu, Mar 1, 2018 at 2:26 AM, Tobias Klauser <tobias....@gmail.com> wrote:

On Wednesday, 28 February 2018 22:43:10 UTC+1, ron minnich wrote:

I'll be working on go in firmware environments, trying to fix the small nits I keep hitting. And trying to get a builder up, since companies are getting ready to ship firmware that uses u-root we need to keep on top of what minimal config variables are needed to keep things working.

one question: the signature for syscall.Reboot(int) is really not right. It should be uint32. Some of the reboot constants have the high bit set so on arm if you do a simple

syscall.Reboot(sycalls.LINUX_REBOOT_CMD_HALT)

you get a compiler error. It seems a little silly to have to cast in that code; but if we change it would that be considered breaking some compatibility promise?

I'm not sure whether we can change it in the syscall package. As I read https://golang.org/doc/go1compat#operating_systems we might be able to change it. Brad or Ian will know for sure though :)

We _could_ change it and not violate go1compat, but if this API failing motivates more people to use golang.org/x/sys/unix instead of syscall, that's a nice side effect. :)

 

However, we can certainly change Reboot in golang.org/x/sys/unix which is what should anyway be used by code outside of the standard Go repository. Please see the NOTE in src/syscall/syscall.go (https://github.com/golang/go/blob/master/src/syscall/syscall.go#L21-L28) and https://golang.org/s/go1.4-syscall

Thanks

Tobias

--

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+unsubscribe@googlegroups.com.