Opening the Go 1.8 dev tree

[Brad Fitzpatrick]

Go 1.7 is nearly out (due Mon the 15th, rc6 out today), so it's time to discuss opening the Go 1.8 dev tree.

Many people are eager for things to open, but let's first figure out which dev.* branches are merging first, in which order.

Keith, do you want to merge dev.ssa into master first, perhap on Monday the 15th?

Rick, Austin, do you have a GC branch to merge already? Or will that be later in the cycle?

Others: feel free to start mailing & reviewing Go 1.8 CLs now, but please don't submit anything to master until we've given the all clear.

[Jessica Frazelle]

YAYYYYYYYYYYYYYYYYY!

​

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

--

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu

[Keith Randall]

Yes, I will get dev.ssa back into master ASAP when we declare open.  Monday sounds fine.

[Austin Clements]

On Mon, Aug 8, 2016 at 5:35 PM, Brad Fitzpatrick <brad...@golang.org> wrote:

Rick, Austin, do you have a GC branch to merge already? Or will that be later in the cycle?

Nope. We'll merge dev.garbage later in the cycle.

[raphael....@gmail.com]

This is Christmas before Christmas.

Huge thanks to all for delivering us such fine pieces of engineering.

The productivity savings and fun each release of Golang brings cannot be overstated.

We are about to get 1.7 and 1.8 is already being discussed. We cannot ask for more.

[Keith Randall]

This would be a good point to ask people what they intend on working on for 1.8.  No commitment required, but we'd like to get a feel for what is coming and make sure we plan for code reviews and such in support of those efforts.

Please include only things you might actually work on, not just something you want someone else to do.  That can be a separate thread :)

I'll start: I plan on getting all other architectures using the SSA backend for 1.8.  A lot of this work is already in progress by various contributors in the dev.ssa branch (which will merge back to master as soon as the tree opens up).

[Austin Clements]

Rick and I are planning to work on the ROC GC algorithm (formerly known as TOC), defer/cgo performance, eliminating STW stack re-scanning (which is the last known thing that can drive up STW GC time), and on general mutator availability/latency issues caused by the runtime (GC or otherwise).

[Michael Hudson-Doyle]

On 10 August 2016 at 08:36, 'Keith Randall' via golang-dev

<golan...@googlegroups.com> wrote:
> This would be a good point to ask people what they intend on working on for
> 1.8. No commitment required, but we'd like to get a feel for what is coming
> and make sure we plan for code reviews and such in support of those efforts.

I'd like to continue on the "make cmd/link look more like a regular Go
program" project and hope I'll get time to at least hack up a first
cut at https://github.com/golang/go/issues/15752 ("cmd/go: only
rebuild dependent packages when export data has changed").

Cheers,
mwh

[Dan Peterson]

I'd like to continue working on DNS-related things, such as:

* https://github.com/golang/go/issues/16345

* https://github.com/golang/go/issues/12524

* https://github.com/golang/go/issues/16218

[David Crawshaw]

I hope to finish removing relocations from program type data, add some
features to reflect, and keep working on binary size.

>> email to golang-dev+...@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+...@googlegroups.com.

[Dave Cheney]

Make compilation speed great again.

[Andrew Gerrand]

Surely you want to diminish the speed?

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

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

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

[Brad Fitzpatrick]

Keith,

Do you want to delete the old backends in 1.8 too or will they remain an option with the flag?

(I'm in favor of deleting)

[Nigel Tao]

On Aug 10, 2016 8:17 AM, "Andrew Gerrand" <a...@golang.org> wrote:
> Surely you want to diminish the speed?

Speed, not times.

[Andrew Gerrand]

Oh yeah, I'm an idiot.

[Keith Randall]

I'm in favor of deleting as well.  There is the option of waiting until 1.9 to delete, in case there are problems with the SSA backends new to 1.8 that passing a -gcflags=-ssa=0 option would help debug.

[Brad Fitzpatrick]

But keeping an ssa=0 flag precludes some optimizations in the front-end, perhaps? At least without flag-controlled fallback paths there too?

[Aram Hăvărneanu]

For 1.8 I want to submit the sparc64 port I have been working on, and
finish arm64 ssa conversion.

--
Aram Hăvărneanu

[Keith Randall]

Possibly.  If we keep the old backend through 1.8 it would preclude those optimizations until 1.9.  I don't know of any plans for such optimizations offhand.

[Josh Bleecher Snyder]

> This would be a good point to ask people what they intend on working on for
> 1.8.

I have mostly completed work I plan to mail. Non-trivial things include:

* cmd/compile: recognize int runs in switch statements, recognize
static interface data, improve generated code for some assertions and
equality checks, lots of little stuff
* build: run vet on std cmd
* cmd/go: add tracing

If I have extra time (looks unlikely), I plan to work on:

* toolchain speed, particularly making regalloc and stackalloc faster
and removing BlockCall and friends
* general compiled code improvements
* fine-tuning codegen for GC and core runtime routines
* the RISC-V port

There's an outside chance that the RISC-V port might be ready for 1.8,
but I think it is unlikely.

> Do you want to delete the old backends in 1.8 too or will they remain an option with the flag?

I'm in favor of deleting. We can compare to 1.7 as needed, the SSA
infrastructure will have been stable for a release, and not having two
backends to maintain will offer lots of opportunities for immediate
improvement and simplification.

-josh

[mart...@uos.de]

I plan to work on:

fmt/strconv: finish changes that i started in 1.7 with a few leftover patches as well as making use of the new combined div/mod where it improves performance
- https://github.com/golang/go/issues/16015 "fmt: formatting of reflect.Value items inconsistent with documentation"

image: complete improvements for color conversion code:
- https://github.com/golang/go/issues/15260 "image/color, image/draw: speed up color conversions with bit twiddling"

also will generally try to contribute some cleanup/performance patches for compiler/runtime and will assist in the ssa transition where i can:
- https://github.com/golang/go/issues/15357 "runtime: decide what type len and cap params should have in runtime calls"

[Jaana Burcu Dogan]

Very few left but I want to close all of the Brillo issues related to android/arm, android/arm64 and android/386 ports.

Also, their current toolchain is entirely ABI compatible with Android. The work left is more like making all.bash pass on Brillo.

[C Cirello]

I plan to keep working on improve the documentation with examples. Occasionally I might bug some people to have extra validation of the proposed example. 

More info at https://github.com/golang/go/issues/16360

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

[frank.s...@gmail.com]

I plan to work on https://github.com/golang/go/issues/16066 unless someone tells me not to.

[Brad Fitzpatrick]

Go 1.7 is out.

Keith, feel free to merge https://golang.org/cl/27050

Once Keith submits the SSA merge (just that one CL), consider the tree open.

On Mon, Aug 8, 2016 at 2:35 PM, Brad Fitzpatrick <brad...@golang.org> wrote:

[Keith Randall]

SSA merge is in.  Go wild.

[brainman]

My CL 26670 is not listed here https://dev.golang.org/cl. Why?

Thank you.

Alex

[Quentin Smith]

That's my fault, sorry. The logic for deciding which Go release is "current" is faulty; the dashboard still thinks Go1.7 is current. I'll fix it momentarily.

--Quentin

--

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.

[brainman]

On Wednesday, 17 August 2016 00:46:36 UTC+10, Quentin Smith wrote:
> I'll fix it momentarily.

Thank you for quick fix. I can see my CL now.

Another issue. The fix (CL 26670) is listed on https://dev.golang.org/cl under misc/cgo/test. But the CL is about fixing cmd/link and cmd/go. The misc/cgo/test contains new test. Perhaps (I did not look at the source) dashboard looks at the files in CL and somehow decides where CL belongs by source file paths. Maybe you should use CL subject line instead.

Alex

[Quentin Smith]

I looked into your sample CL (26670). What's happening is that the dashboard is taking the first directory in your CL description ("cmd/link") and not finding any modified files in that directory, so it falls back to the directory with the most changed files, which in this case is misc/cgo/test.

Had your CL description started with "cmd/go", or started with "cmd/link/internal/ld", those would have been preferred to the file-based heuristic. I'm not sure there's much to tweak here, although perhaps we should recognize cmd/link as a parent directory of cmd/link/internal/ld.

--Quentin

--

[brainman]

On Saturday, 20 August 2016 03:56:28 UTC+10, Quentin Smith wrote:

I looked into your sample CL (26670). What's happening ...

Fair enough. Thank you for explaining.

Alex