Go 1.9 planning & kick-off week

9674 views
Skip to first unread message

Brad Fitzpatrick

unread,
Jan 24, 2017, 2:28:25 PM1/24/17
to golang-dev
The Go 1.8 release is looking good and looks to be released approximately on time.

Regardless of the exact release date of Go 1.8, the plan is to unfreeze the master branch for Go 1.9 development starting Wednesday, Feb 1st. We'll announce that day when it's open.

Now's the time to discuss what everybody plans to do during the Go 1.9 cycle. (what you plan to do yourself, NOT what you want others to do)

So, what's coming?

I know there's a "dev.inline" compiler branch underway.

There's also a GC branch at some state of readiness.

Which of those is ready to merge, and in which order?

Also, we're trying something new this cycle:

A bunch of the Google employees who normally only work on Google-internal libraries will be spending a week (Mon Feb 6th - Fri Feb 10th) working in the open source world, working on bugs/features/performance or whatever else that scratches their itch or they find entertaining. So you'll probably all see some new names. Please help out newcomers if they're confused about the process or tooling. Of course, this isn't an event exclusive to Googlers. If you or your organization also wants to concentrate their attention on bugs & the Go libraries that week, the more the merrier! More docs on that process later.

Here's to looking forward to a fun Go 1.9 cycle!


-- Brad (on behalf of the Go team)





Kevin Burke

unread,
Jan 24, 2017, 2:45:56 PM1/24/17
to golang-dev
I've been working on improvements to dev.golang.org.

So far I've gotten tests passing on (most of) the golang.org/x/build tree, and thanks to Quentin Smith and Austin Clements, resolved a problem where the x/build tree was depending on code that existed only in a pull request.

This changeset fixes the build for x/build/devapp, adds x/build/cmd/devapp so we can run dev.golang.org as a standalone binary, removes dev.golang.org's dependency on App Engine and puts all of the App Engine code behind a build flag. The alternative implementation fetches all data from Github and Gerrit and stores it all in memory. https://go-review.googlesource.com/#/c/34928/

This changeset compiles the existing templates into the binary so it's a little less dependent on the working directory https://go-review.googlesource.com/#/c/34980/

This changeset fetches Gerrit and Github CL's/issues in parallel, which reduces the startup time by about 10 seconds. https://go-review.googlesource.com/#/c/35551/

I'd also like to work on making more of `os/user` work when you cross compile Go for a Unix target. Specifically, if cgo/getgrnam and friends are not available, try to use a pure Go implementation to parse /etc/group and /etc/passwd to get user information, instead of immediately bailing with an error.

Keith Randall

unread,
Jan 24, 2017, 2:54:33 PM1/24/17
to Kevin Burke, golang-dev
I have a bunch of compiler changes ready to go or in progress.  Mostly optimizations - better spill decisions, better type conversions, etc.  I plan on doing some more of these as well as working on making the compiler itself faster.


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

Russ Cox

unread,
Jan 24, 2017, 3:00:50 PM1/24/17
to Keith Randall, Kevin Burke, golang-dev
We'd like to get the typealias and inline branches merged at the start of Go 1.9, in that order, before any other work in the tree. 

Similarly, I have some refactoring of the go command that I'd like to merge before any work in the go command.

Russ

Josh Bleecher Snyder

unread,
Jan 24, 2017, 3:17:47 PM1/24/17
to Keith Randall, Kevin Burke, golang-dev
I hope to work on making much of the SSA backend compilation
concurrent. This would involve some significant refactoring, so I
would wait for the typealias and inline branches to get merged. That
*might* also include adding tracing to go commands (issue 15736, in
part out of concern about issue 17969), which would wait for Russ's
cmd/go work. Russ, will you give an all-clear here when that work is
completed?

I also have a handful of minor compiler optimizations
(performance+toolspeed) queued. Keith, I'm happy to get your batch of
changes landed before mine. Please let me know when your CL backlog is
cleared.

Keith, which areas of compiler toolspeed do you plan to look at? In
the unlikely event that I have extra time, I hope to look at
regalloc/liveness performance and moving common sources of dead blocks
from walk to ssa (e.g. switch statements).

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

Keith Randall

unread,
Jan 24, 2017, 3:19:53 PM1/24/17
to Josh Bleecher Snyder, Kevin Burke, golang-dev
On Tue, Jan 24, 2017 at 12:17 PM, Josh Bleecher Snyder <josh...@gmail.com> wrote:
I hope to work on making much of the SSA backend compilation
concurrent. This would involve some significant refactoring, so I
would wait for the typealias and inline branches to get merged. That
*might* also include adding tracing to go commands (issue 15736, in
part out of concern about issue 17969), which would wait for Russ's
cmd/go work. Russ, will you give an all-clear here when that work is
completed?

I also have a handful of minor compiler optimizations
(performance+toolspeed) queued. Keith, I'm happy to get your batch of
changes landed before mine. Please let me know when your CL backlog is
cleared.

Keith, which areas of compiler toolspeed do you plan to look at? In
the unlikely event that I have extra time, I hope to look at
regalloc/liveness performance and moving common sources of dead blocks
from walk to ssa (e.g. switch statements).


I was thinking about looking at regalloc/liveness performance also.  I'm happy to leave it to you.
 
-josh

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

Josh Bleecher Snyder

unread,
Jan 24, 2017, 3:22:16 PM1/24/17
to Keith Randall, Kevin Burke, golang-dev
>> I hope to work on making much of the SSA backend compilation
>> concurrent. This would involve some significant refactoring, so I
>> would wait for the typealias and inline branches to get merged. That
>> *might* also include adding tracing to go commands (issue 15736, in
>> part out of concern about issue 17969), which would wait for Russ's
>> cmd/go work. Russ, will you give an all-clear here when that work is
>> completed?
>>
>> I also have a handful of minor compiler optimizations
>> (performance+toolspeed) queued. Keith, I'm happy to get your batch of
>> changes landed before mine. Please let me know when your CL backlog is
>> cleared.
>>
>> Keith, which areas of compiler toolspeed do you plan to look at? In
>> the unlikely event that I have extra time, I hope to look at
>> regalloc/liveness performance and moving common sources of dead blocks
>> from walk to ssa (e.g. switch statements).
>>
>
> I was thinking about looking at regalloc/liveness performance also. I'm
> happy to leave it to you.

And I'm happy to leave it to you. :) Let's just discuss if/when either
of us starts on it in earnest.

-josh

Joe Tsai

unread,
Jan 24, 2017, 3:32:21 PM1/24/17
to golang-dev, k...@google.com, k...@inburke.com
I would like to:
  • finish addressing all open issues for archive/tar and archive/zip
  • optimize hot standard library functions based on production data
  • (possible) submit my compress/flate decoder optimization (1.5x to 2x faster)
  • (unlikely) submit my compress/bzip2 encoder implementation
JT

C Cirello

unread,
Jan 24, 2017, 4:09:59 PM1/24/17
to golang-dev
I see the opportunity to work still on examples in few packages. I hope to get something closer to full coverage by Go1.9 cycle.

Unfortunately I do not remember the person's name by heart. But I remember vividly this person also contributed with many examples, so o hope to not be alone this time.

I should like also to get from the current team some feedback on how to approach package owners/main contributors. As the coverage improves, it also gets more complicated to create meaningful examples that doesn't just repeat somehow what is one the tests (for the obvious reason that I do not know everything).

Any suggestion is welcome. And I shall try hard to disturb as few people as necessary with questions about developing examples.

Aram Hăvărneanu

unread,
Jan 24, 2017, 4:53:31 PM1/24/17
to C Cirello, golang-dev
After type alias and inline merge, I want to merge the SPARC64 port.

--
Aram Hăvărneanu

brainman

unread,
Jan 24, 2017, 5:54:41 PM1/24/17
to golang-dev
I want to implement PE DWARF info generation during external linking (issue 10776).

Alex

Daniel Theophanes

unread,
Jan 24, 2017, 7:02:09 PM1/24/17
to golang-dev
I'd like to continue working on database/sql. In order of priority:

 * Merge in proper statement support for transactions https://go-review.googlesource.com/c/35476/
 * Ensure custom type are well supported and documented for query arguments and query result values.
 * Allow drivers to support OUTPUT parameters.
 * Look into the general structure of the database connection pool and determine if there is a cleaner alternate internal design for it.
 * Look into grabbing a single connection outside of a Tx.
 * Look into supporting either Savepoints or nested Transactions.
 * Look into supporting some sort of query trace API. (I'd like to start exploring designs, but realistically an implementation won't happen until go1.10.)

I hope to keep API additions minimal for go1.9. I don't plan an endless stream of additions to the sql package; these should be the last additions. After these most of the work will be done outside the std lib or internal sql performance improvements.


Jaana Burcu Dogan

unread,
Jan 25, 2017, 5:07:52 PM1/25/17
to golang-dev
I (and the other devexp people) will be working on docs and API reviews.

- Guide on tools as requested by feedback
- Installation experience, sorting out the requirements for official packages
- Addressing all issue with API or tooling UX changes
- Reviewing all new standard library APIs
- More references, filling points that require examples


On Tuesday, January 24, 2017 at 11:28:25 AM UTC-8, Brad Fitzpatrick wrote:

Lynn Boger

unread,
Jan 30, 2017, 10:32:40 AM1/30/17
to golang-dev
We are working on mostly performance improvements for ppc64x (some only ppc64le, some apply to both):

- Some minor updates to the rules file to add or improve optimizations.  There are some implemented and tested but not officially submitted; there are other problem areas identified but not yet implemented.
- Enhanced asm implementations of some package functions including crypto, hash/crc32, IndexByte, math, math/big.  (More detail on crypto and math/big changes will have to come from the team working on it if you'd like.)
- Implementation of the atomic functions as intrinsics.
- Further investigation and analysis of the argument passing proposal as well as more inlining.
- Updates to the asm opcodes to include more power8 and in some cases power9 instructions.

We will be opening issues for these with more detail.

More analysis and work to be identified once these are submitted and upstream.

Any existing open issues for Go 1.9 on ppc64x will also be addressed.

- Lynn

David Chase

unread,
Jan 30, 2017, 4:00:59 PM1/30/17
to golang-dev
Attempting to get register-use for passing arguments to and results from function/method calls, may not make it for 1.9.

Further investigation/improvement of inserted rescheduling checks on loop back edges for GC-start latency reduction.

Smaller optimizations -- loop unrolling (helpful to loop rescheduling) and loop invariant code motion.

Help out with debugger stuff, as needed/able.

Michel Lespinasse

unread,
Feb 1, 2017, 8:34:28 AM2/1/17
to Brad Fitzpatrick, golang-dev
Only a small contribution, but I'd like to get the http client socks5 proxy changes unstuck.
(https://go-review.googlesource.com/#/c/35488/ and associated patches in the series)

Brad Fitzpatrick

unread,
Feb 6, 2017, 11:44:08 AM2/6/17
to golang-dev
On Tue, Jan 24, 2017 at 11:28 AM, Brad Fitzpatrick <brad...@golang.org> wrote:
...

Also, we're trying something new this cycle:

A bunch of the Google employees who normally only work on Google-internal libraries will be spending a week (Mon Feb 6th - Fri Feb 10th) working in the open source world, working on bugs/features/performance or whatever else that scratches their itch or they find entertaining. So you'll probably all see some new names. Please help out newcomers if they're confused about the process or tooling. Of course, this isn't an event exclusive to Googlers. If you or your organization also wants to concentrate their attention on bugs & the Go libraries that week, the more the merrier! More docs on that process later.

FYI: this begins now. 

If you don't have a project in mind, you might find stuff to do here:
https://golang.org/issues

Or here:


Wei....@arm.com

unread,
Feb 22, 2017, 8:50:55 PM2/22/17
to golang-dev
We are developing the Go disassembler for ARM64 and expect to finish it before this July. Is the timescale fit to Go1.9 release cycle?

Brad Fitzpatrick

unread,
Feb 22, 2017, 8:53:13 PM2/22/17
to Wei....@arm.com, golang-dev
The three new-code development months for Go 1.9 are February, March, and April. The 3 stabilization months are May, June, July.

If "before July" means "before May", that would be ideal.

But considering that the arm64 disassembler doesn't really affect much else, it might be acceptable a bit later than normal.



Wei Xiao

unread,
Feb 22, 2017, 9:21:06 PM2/22/17
to Brad Fitzpatrick, golang-dev

ARM64 disassembler for supporting basic instructions (I mean all instructions supported by current Go assembler) can be ready before May. We can submit the basic support first to align to your development cycle.

After that, we will continue improving the disassembler for supporting ARM64 advanced SIMD instructions so that we can make optimizations based on these vector instructions later.

 

Thanks

Wei Xiao

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.

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Dmitri Shuralyov

unread,
Mar 7, 2017, 11:14:47 PM3/7/17
to golang-dev, brad...@golang.org
I'm aiming to do more during (the rest of) Go 1.9 cycle than previous cycles.

Right now my highest priority issue that I think is most important/impactful is #18892. I'm watching it closely. However, it seems to be blocked/waiting on some external factors, and I'm looking for any tasks I can take on to help it make progress. I know the entire task is really large scope and complex, but I'm still hoping there's something I can do to aid with making it a reality. I have free cycles and motivation to work on it.

Aside from that, I have a couple smaller bugs/issues that I personally care about resolving (e.g., some of these ones), I plan on reporting them and hopefully fixing them soon.

After that, I'll be looking around for what else I can do.

Wei Xiao

unread,
Apr 20, 2017, 10:53:20 PM4/20/17
to Brad Fitzpatrick, golang-dev

I’d like to update ARM64 decoder development progress: we have finished the decoder table (1210 items) for all ARM64 instructions and all base instructions have pass the GNU syntax test which compares output with external objdump.

But we encounter a new problem: Go assembly is not well defined for ARM64 and I have started a new thread about the topic: https://groups.google.com/forum/#!topic/golang-dev/rWgDxCrL4GU

Since our final aim is to use decoder to verify ARM64 assembler, I’d like to make some changes to assembler for better supporting ARM64 before finishing the remaining work of decoder, especially GoSyntax (plan9x.go).

We expect to finish ARM64 decoder before the end of May.

 

From: Brad Fitzpatrick [mailto:brad...@golang.org]
Sent: Thursday, February 23, 2017 9:53 AM
To: Wei Xiao
Cc: golang-dev
Subject: Re: [golang-dev] Re: Go 1.9 planning & kick-off week

 

The three new-code development months for Go 1.9 are February, March, and April. The 3 stabilization months are May, June, July.

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.

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Brad Fitzpatrick

unread,
Apr 20, 2017, 11:48:32 PM4/20/17
to Wei Xiao, golang-dev
The Go 1.9 new-code development phase ends in about 10 days.

May will already be into freeze time.

I think it might be okay to let the arm64 dissembler land during the freeze since it doesn't affect anything else, but touching the arm64 assembler that late in the cycle is more questionable, especially if you plan to change any syntax on people. Adding new syntax only might be okay later in the cycle.

In any case, I encourage you to send stuff early & often if possible and don't wait until the very end to send a pile of code.

I'll let others give their opinions.


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.

cherry

unread,
Apr 21, 2017, 6:19:49 PM4/21/17
to Brad Fitzpatrick, Wei Xiao, golang-dev
The disassembler will first land in x/arch, right? Then it should be fine during the freeze.

The assembler and the disassembler don't need to be changed together. You can add support of instructions to the disassembler that the current assembler doesn't support, then add them to the assembler later.

Wei....@arm.com

unread,
Apr 23, 2017, 10:24:11 PM4/23/17
to golang-dev, brad...@golang.org, Wei....@arm.com
Yes, i will push ARM64 disassembler to x/arch.
I plan to add some changes and bug fixings to the assembler this week and left the remaining refinement work later.
Btw, when will the window open again for accepting changes to assembler after April?

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.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

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

Brad Fitzpatrick

unread,
Apr 24, 2017, 6:44:02 PM4/24/17
to Wei Xiao, golang-dev
On Sun, Apr 23, 2017 at 7:24 PM, <Wei....@arm.com> wrote:
Yes, i will push ARM64 disassembler to x/arch.
I plan to add some changes and bug fixings to the assembler this week and left the remaining refinement work later.
Btw, when will the window open again for accepting changes to assembler after April?

Probably first week of August.


Brad Fitzpatrick

unread,
Jun 7, 2017, 4:25:22 PM6/7/17
to Wei Xiao, golang-dev
Wei,

What's the status here?



On Sun, Apr 23, 2017 at 7:24 PM, <Wei....@arm.com> wrote:

Wei Xiao

unread,
Jun 7, 2017, 9:37:06 PM6/7/17
to Brad Fitzpatrick, golang-dev

Brad,

 

 I submitted the patch (https://go-review.googlesource.com/c/43651/) three weeks ago but get no feedbacks so far.

Reply all
Reply to author
Forward
0 new messages