Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Planning the 1.4 release

7,529 views
Skip to first unread message

Rob Pike

unread,
Jun 3, 2014, 6:44:53 PM6/3/14
to golan...@googlegroups.com
Go 1.3 is on the exit ramp. We're in the quiet period now, and we hope
to ship the release within a couple of weeks.

The 1.3 release is the second one we've run within this new, regular
schedule[1]. Our ship date slipped a little, for a number of minor
reasons, but not by much. We expect 1.4 to happen, as normal, on
December 1, 2014.

So now it's time to plan what's next. What will be in 1.4?

The biggest component will be entirely under the covers, as the
toolchain and runtime move from C towards Go [2]. It's unlikely all C
code will be gone by 1.4, but much of it will, including - and most
exciting - the compiler. Compiler development in the C version is
likely to be dialed back, to free up more resources for the
transition. (Note that "rsc" appears nicely distributed in
"resources".) Similar conditions apply to the runtime.

Once the 1.3 release is live, we'll be open to new CLs but want to
concentrate on these fundamental changes, even scheduling them so the
code can move gracefully without introducing merge conflicts and other
complexities. If anyone else has other wide-ranging, core work like
this that would make sense for 1.4, please say so now so it can be
scheduled as well.

Over the next few weeks we'll work with you to sketch out the
large-scale priorities for 1.4 and pencil in the sequence of changes
to satisfy them.

Please remember that the open source community is vital to the Go
ecosystem. We can't thank you enough for your contributions.

-rob, for the Go team

[1] http://golang.org/s/releasesched
[2] http://golang.org/s/go13compiler

Nathan Youngman

unread,
Jun 4, 2014, 12:34:25 AM6/4/14
to golan...@googlegroups.com

I hope to see os/fsnotify in Go 1.4.

There is still a fair bit of experimentation needed before we settle on the API. 

~

As well, I'd like to reopen the "locking down vanity import paths" conversation:
https://groups.google.com/forum/#!msg/golang-dev/RgHGBXROeAw/yCD6bpGq4R8J

Improving search results on GoDoc.org may be able to make use of a "canonical import path" of sorts:
https://github.com/golang/gddo/issues/172

- nathan

Elias Naur

unread,
Jun 4, 2014, 1:24:43 AM6/4/14
to golan...@googlegroups.com
I'd like to bring android Dalvik and iOS to the table again, as well as cgo shared libraries (perhaps using https://docs.google.com/document/d/1tU_yNmwu1raKZm9atHJ8THiQizkYTKykdWraIb15TSE/edit?usp=docslist_api as a starting point)

- elias

Dave Cheney

unread,
Jun 4, 2014, 6:40:23 AM6/4/14
to Elias Naur, golang-dev
I would like to have a discussion about additional build tags for the
various arm variants now that instruction selection is handled at
compile time.

https://groups.google.com/d/topic/golang-dev/1EERkkWgbrM/discussion

The people who also want to do something similar for SSE2/3/4/AVX may
want to chime in.

Cheers

Dave

On Wed, Jun 4, 2014 at 3:24 PM, Elias Naur <elias...@gmail.com> wrote:
> I'd like to bring android Dalvik and iOS to the table again, as well as cgo shared libraries (perhaps using https://docs.google.com/document/d/1tU_yNmwu1raKZm9atHJ8THiQizkYTKykdWraIb15TSE/edit?usp=docslist_api as a starting point)
>
> - elias
>
> --
> 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.

Aram Hăvărneanu

unread,
Jun 4, 2014, 8:01:16 AM6/4/14
to Dave Cheney, Elias Naur, golang-dev
My main priority this cycle is writing 7g, the arm64 compiler. I
hope to get it working in time to get it in 1.4. The first target
is plan9/arm64 and the principal target (but done second) is
linux/arm64. This is solitary work, I expect no clash with other
work, so it doesn't require any special scheduling.

There are other things I want to do, for which I might or I might
not have time to do. The first would be plan9/amd64 support. It
took me a single day to get to a semi-working go tool, so I expect
to finish that (mostly because I use the amd64 Plan 9 kernel these
days). plan9/arm is also on the table but rather unlikely for this
cycle.

Another thing I want to do is better DTrace support for Go. This
is not so much work, although I might wait until we have the linker
written in Go.

Another thing I will most certainly do very soon is cgo support for
the solaris/amd64 port (I've actually done it a few months ago and
it's working perfectly, 95% of the time).

I expect most of these things not to clash with other people's work,
even if some of thsese things are large. Or if there's a clash, it
would be minimal.

--
Aram Hăvărneanu

Yukinari Toyota

unread,
Jun 4, 2014, 1:07:50 PM6/4/14
to golan...@googlegroups.com
In my personal matter, I want to build generic runtime poller API like [Issue 6222: runtime: poller should be used for file system operations]
 but not for filesystem/AIO, just for file descriptors those support poll to enhance some device driver/device file operation supports.

2014年6月4日水曜日 7時44分53秒 UTC+9 Rob Pike:

tracey....@gmail.com

unread,
Jun 4, 2014, 8:27:59 PM6/4/14
to golan...@googlegroups.com
It would be a huge boon to the numerical community to have support for multi-dimensional slices (issue 6282). I think my proposal (linked in the issue) integrates well within the language. It would be useful to have some input on the proposal from the lead developers; so far there as only been one Go contributor that has commented on the proposal (aside from the proposal authors). It is my opinion that this set of changes, along with Dan’s suggested range syntax, constitutes a sufficient set of changes to make Go an excellent language for numeric computing.

I understand that even if the proposal is accepted a full implementation may add too much complexity for 1.4. In that case, a partial implementation (type definition, access, assignment, and slicing) would be of great help as we build a standard library for numeric/scientific computing in Go.

Mikio Hara

unread,
Jun 4, 2014, 11:19:38 PM6/4/14
to Rob Pike, golang-dev
On Wed, Jun 4, 2014 at 7:44 AM, Rob Pike <r...@golang.org> wrote:

> So now it's time to plan what's next. What will be in 1.4?

I'd like to see netio or similar package that exposes both Poller and
Mutex primitives of the runtime-integrated network poller. A simple
motivation: we'll be able to implement featured network connection
endpoints which satisfy net.Conn interface without churning out the
runtime and net packages if we get some fancy network attachment that
implements some programmable protocol offload engine or net package
unsupported address families.

The replumbing work would not be tough; simply from runtime<-net to
runtime<-netio<-net (https://codereview.appspot.com/99510043/).

Mikio Hara

unread,
Jun 5, 2014, 12:12:41 AM6/5/14
to Nathan Youngman, golang-dev
On Wed, Jun 4, 2014 at 1:34 PM, Nathan Youngman <n...@nathany.com> wrote:

> I hope to see os/fsnotify in Go 1.4.
> https://code.google.com/p/go-wiki/wiki/DesignDocuments

Hope so too. After it lands, net package uses os/fsnotify for
capturing local configuration file changes.

Taru Karttunen

unread,
Jun 5, 2014, 3:37:09 AM6/5/14
to Dave Cheney, Elias Naur, golang-dev
On 04.06 20:40, Dave Cheney wrote:
> I would like to have a discussion about additional build tags for the
> various arm variants now that instruction selection is handled at
> compile time.
>
> https://groups.google.com/d/topic/golang-dev/1EERkkWgbrM/discussion

I would like to get the armv4 code in, which requires a solution to
this (the code contains a separate patch which implements build flags
armv4/armv5/armv6/armv7).

- Taru Karttunen

Dave Cheney

unread,
Jun 5, 2014, 3:54:16 AM6/5/14
to Taru Karttunen, Elias Naur, golang-dev
I would prefer not to see that. I've looked into arm4t boards and none
of them would be capable of running a builder so don't qualify as a
port.

chen...@126.com

unread,
Jun 5, 2014, 5:14:27 AM6/5/14
to golan...@googlegroups.com
Can map support upper_bound like c++?

在 2014年6月4日星期三UTC+8上午6时44分53秒,Rob Pike写道:

Lucio De Re

unread,
Jun 5, 2014, 8:27:35 AM6/5/14
to Dave Cheney, Taru Karttunen, Elias Naur, golang-dev
But by the same criterion, nor does NaCl, right?

Aram Hăvărneanu

unread,
Jun 5, 2014, 8:29:15 AM6/5/14
to Lucio De Re, Dave Cheney, Taru Karttunen, Elias Naur, golang-dev
> But by the same criterion, nor does NaCl, right?

No, NaCl has a builder (actually two), which is active and mostly
passes: http://build.golang.org.

--
Aram Hăvărneanu

Brad Fitzpatrick

unread,
Jun 5, 2014, 8:31:01 AM6/5/14
to Aram Hăvărneanu, golan...@googlegroups.com, Elias Naur, Taru Karttunen, Lucio De Re, Dave Cheney

Mostly? It actually passes. And when it breaks we've fix it. (See recent case)

Builders: they work.

Aram Hăvărneanu

unread,
Jun 5, 2014, 8:32:31 AM6/5/14
to Brad Fitzpatrick, golang-dev, Elias Naur, Taru Karttunen, Lucio De Re, Dave Cheney
> Mostly? It actually passes. And when it breaks we've fix it. (See recent
> case)

Yes, the builder always passes, 90% of the time.

--
Aram Hăvărneanu

Dmitry Vyukov

unread,
Jun 5, 2014, 8:36:45 AM6/5/14
to Aram Hăvărneanu, Brad Fitzpatrick, golang-dev, Elias Naur, Taru Karttunen, Lucio De Re, Dave Cheney
It makes no sense.

Ian Lance Taylor

unread,
Jun 5, 2014, 10:00:34 AM6/5/14
to chen...@126.com, golang-dev
On Thu, Jun 5, 2014 at 2:14 AM, <chen...@126.com> wrote:
>
> Can map support upper_bound like c++?

Not really, maps in Go are not sorted. They are like the C++
std::unordered_map, not the C++ std::map.

Ian

Lucio De Re

unread,
Jun 5, 2014, 12:12:14 PM6/5/14
to Aram Hăvărneanu, Dave Cheney, Taru Karttunen, Elias Naur, golang-dev
OK, but the issue was that there is no hardware to run arm<7 and I
presume that the NaCl builder runs as a VM, so I assumed that one
could run arm builders on emulators, like for NaCl?

Maybe a bad assumption?

Brad Fitzpatrick

unread,
Jun 5, 2014, 12:13:39 PM6/5/14
to Lucio De Re, golan...@googlegroups.com, Elias Naur, Taru Karttunen, Aram Hăvărneanu, Dave Cheney

Nacl doesn't require a VM. I mean, it IS one. But runs on any OS on that native arch.

Aram Hăvărneanu

unread,
Jun 5, 2014, 12:17:41 PM6/5/14
to Lucio De Re, Dave Cheney, Taru Karttunen, Elias Naur, golang-dev
> OK, but the issue was that there is no hardware to run arm<7 and I
> presume that the NaCl builder runs as a VM, so I assumed that one
> could run arm builders on emulators, like for NaCl?

There is a lot of armv4 hardware. The alleged problem is that is bad
(not enough memory?). Emulating it would only make it slower and
worse.

--
Aram Hăvărneanu

Dave Cheney

unread,
Jun 5, 2014, 5:06:56 PM6/5/14
to Aram Hăvărneanu, Lucio De Re, Taru Karttunen, Elias Naur, golang-dev
We have real arm hardware builders for arm v5, v6 and v7. The build
requires more than 256mb of ram to run to completion, and it was
difficult to find an arm v5 device that could fit those requirements.

In my research the largest armv4t device has a 400mhz cpu and a 64mb
of ram, they simply aren't capable of hosting a builder. Emulation may
be faster in that case if someone is prepared to host and maintain a
qemu builder.

I don't see the cost of supporting armv4t devices as worthwhile. There
are other devices that Go does not support, like the Intel Galileo,
and that's just the way it turned out.

Dave Cheney

unread,
Jun 5, 2014, 5:30:47 PM6/5/14
to golang-dev
On a different note I would like to have a discussion about how to
make the cmd/go tool available to platforms that don't/can't use the
gc toolchain.

The goal would be to support passing the contents of cmd/go to gccgo
unmodified and getting a linkable result. Right now that involves some
modification of the cmd/go sources to work with gccgo's 1.2 spec
standard library[1]. In theory this would be solvable with some build
tags.

Thoughts ?

1. http://go-talks.appspot.com/github.com/davecheney/gosyd/gccgo.slide#1

Ian Lance Taylor

unread,
Jun 5, 2014, 5:30:52 PM6/5/14
to Dave Cheney, Aram Hăvărneanu, Lucio De Re, Taru Karttunen, Elias Naur, golang-dev
On Thu, Jun 5, 2014 at 2:06 PM, Dave Cheney <da...@cheney.net> wrote:
>
> I don't see the cost of supporting armv4t devices as worthwhile. There
> are other devices that Go does not support, like the Intel Galileo,
> and that's just the way it turned out.

For oddball processors there is always the gccgo compiler.

Ian

Ian Lance Taylor

unread,
Jun 5, 2014, 5:47:18 PM6/5/14
to Dave Cheney, golang-dev
On Thu, Jun 5, 2014 at 2:30 PM, Dave Cheney <da...@cheney.net> wrote:
>
> On a different note I would like to have a discussion about how to
> make the cmd/go tool available to platforms that don't/can't use the
> gc toolchain.
>
> The goal would be to support passing the contents of cmd/go to gccgo
> unmodified and getting a linkable result. Right now that involves some
> modification of the cmd/go sources to work with gccgo's 1.2 spec
> standard library[1]. In theory this would be solvable with some build
> tags.

I would like to have gccgo build the go tool itself. This is mostly a
matter of getting the configury right. The go tool needs to be built
using a build-x-host Go compiler, but I only have build-x-target Go
compiler. (To be clear in a normal default build of gccgo these are
the same compiler, but GCC and hence gccgo are routinely built both as
and using cross-compilers.) If I can get that done that will address
your problem. But I don't know when I will work on it. But somebody
else could do it--patches welcome!

Also, I am currently in the process of updating gccgo's runtime
library to the 1.3 library.

All that aside, yes, I think that any general modifications needed to
make the go tool build and work with gccgo should be committed.

But I'm not entirely sure whether we want to worry about making the go
tool in the master tree buildable with older versions of gccgo. That
seems like a bit of a struggle. If that is desirable I think we
should make a fork of the go tool hosted elsewhere.

Ian

Michael Hudson-Doyle

unread,
Jun 5, 2014, 10:42:05 PM6/5/14
to Aram Hăvărneanu, Dave Cheney, Elias Naur, golang-dev
Aram Hăvărneanu <ara...@mgk.ro> writes:

> My main priority this cycle is writing 7g, the arm64 compiler. I
> hope to get it working in time to get it in 1.4. The first target
> is plan9/arm64 and the principal target (but done second) is
> linux/arm64. This is solitary work, I expect no clash with other
> work, so it doesn't require any special scheduling.

Awesome! Let me know if Linaro can help in any way.

Cheers,
mwh

Michael Hudson-Doyle

unread,
Jun 5, 2014, 10:48:08 PM6/5/14
to Dave Cheney, golang-dev
Dave Cheney <da...@cheney.net> writes:

> On a different note I would like to have a discussion about how to
> make the cmd/go tool available to platforms that don't/can't use the
> gc toolchain.
>
> The goal would be to support passing the contents of cmd/go to gccgo
> unmodified and getting a linkable result. Right now that involves some
> modification of the cmd/go sources to work with gccgo's 1.2 spec
> standard library[1]. In theory this would be solvable with some build
> tags.

There is also that hard coded list of std libary package paths in the
gccgo-go source; I think that could/should be replaced with searching
gccgo's linker path for .gox files (gccgoimporter has code for this). I
think anyway! It's been a while since I thought about this.

Cheers,
mwh

Taru Karttunen

unread,
Jun 6, 2014, 4:31:54 AM6/6/14
to Dave Cheney, Aram Hăvărneanu, Lucio De Re, Elias Naur, golang-dev
On 06.06 07:06, Dave Cheney wrote:
> We have real arm hardware builders for arm v5, v6 and v7. The build
> requires more than 256mb of ram to run to completion, and it was
> difficult to find an arm v5 device that could fit those requirements.
>
> In my research the largest armv4t device has a 400mhz cpu and a 64mb
> of ram, they simply aren't capable of hosting a builder. Emulation may
> be faster in that case if someone is prepared to host and maintain a
> qemu builder.
>
> I don't see the cost of supporting armv4t devices as worthwhile. There
> are other devices that Go does not support, like the Intel Galileo,
> and that's just the way it turned out.

Is this a general direction that it is not worthwhile to support e.g.
embedded systems in future if they are not usable as builders?

Typically when using a low end ARM system with Go the easiest way is
to use a higher-end ARM machine with an explicit GOARM setting and do
judicious testing on the target device.

What specs would you require for a builder (virtual) machine?

Is there a general good practice for maintaining out-of-tree ports?

- Taru Karttunen

Aram Hăvărneanu

unread,
Jun 6, 2014, 5:27:13 AM6/6/14
to Taru Karttunen, Dave Cheney, Lucio De Re, Elias Naur, golang-dev
FWIW I run Go on "small" machines, and I would be happy if I could run
it on even smaller machines. We can test ARMv4 code on newer ARM
machines; that's no guarantee it will run on ARMv4, but we don't use a
Pentium 2 to test GO386=387 either, so it's neither better or worse.

We can also reduce the scope of the tests for that platform, is native
testing is required.

Where there's a will, there's a way.

--
Aram Hăvărneanu

Gustavo Niemeyer

unread,
Jun 6, 2014, 9:10:25 AM6/6/14
to Rob Pike, golang-dev
On Tue, Jun 3, 2014 at 7:44 PM, Rob Pike <r...@golang.org> wrote:
> The biggest component will be entirely under the covers, as the
> toolchain and runtime move from C towards Go [2]. It's unlikely all C
> code will be gone by 1.4, but much of it will, including - and most
> exciting - the compiler. Compiler development in the C version is
> likely to be dialed back, to free up more resources for the
> transition. (Note that "rsc" appears nicely distributed in
> "resources".) Similar conditions apply to the runtime.

We discussed the idea of having shared libraries of Go code a few
times over the last few months, to enable Linux distributions to
upgrade parts of Go applications across the whole system when there
are security incidents. Over a casual conversation with Russ at
GopherCon, we talked a bit about the potential granularity of that,
possibly having "bundles" of packages together in a single shared
object.

Given the comments above, I'm wondering if there's any chance this
might see some preliminary attention.


gustavo @ http://niemeyer.net

John Waycott

unread,
Jun 6, 2014, 10:06:30 AM6/6/14
to golan...@googlegroups.com, da...@cheney.net, ara...@mgk.ro, lucio...@gmail.com, tar...@taruti.net, elias...@gmail.com
Has there been any discussion or interest in other specialized processors? My interest is the Tilera Gx which seems would be a good fit with Go since it is aimed at Go original server/system market space.

snes...@gmail.com

unread,
Jun 8, 2014, 3:56:30 PM6/8/14
to golan...@googlegroups.com
Support methods written in assembly.
Support all SIMD x86 instructions in 6a and 8a, if possible also other current non-SIMD instructions.

Dave Cheney

unread,
Jun 9, 2014, 9:27:28 PM6/9/14
to Erwin Driessens, golang-dev
On Mon, Jun 9, 2014 at 5:56 AM, <snes...@gmail.com> wrote:
Support methods written in assembly.
Support all SIMD x86 instructions in 6a and 8a, if possible also other current non-SIMD instructions.

This has been requested before. Can you please make sure an issue detailing the instructions that you would like to see added is filed.

Dmitry Vyukov

unread,
Jun 10, 2014, 3:29:03 PM6/10/14
to Rob Pike, golang-dev
On Wed, Jun 4, 2014 at 2:44 AM, Rob Pike <r...@golang.org> wrote:
> Go 1.3 is on the exit ramp. We're in the quiet period now, and we hope
> to ship the release within a couple of weeks.
>
> The 1.3 release is the second one we've run within this new, regular
> schedule[1]. Our ship date slipped a little, for a number of minor
> reasons, but not by much. We expect 1.4 to happen, as normal, on
> December 1, 2014.
>
> So now it's time to plan what's next. What will be in 1.4?
>
> The biggest component will be entirely under the covers, as the
> toolchain and runtime move from C towards Go [2]. It's unlikely all C
> code will be gone by 1.4, but much of it will, including - and most
> exciting - the compiler. Compiler development in the C version is
> likely to be dialed back, to free up more resources for the
> transition. (Note that "rsc" appears nicely distributed in
> "resources".) Similar conditions apply to the runtime.
>
> Once the 1.3 release is live, we'll be open to new CLs but want to
> concentrate on these fundamental changes, even scheduling them so the
> code can move gracefully without introducing merge conflicts and other
> complexities. If anyone else has other wide-ranging, core work like
> this that would make sense for 1.4, please say so now so it can be
> scheduled as well.
>
> Over the next few weeks we'll work with you to sketch out the
> large-scale priorities for 1.4 and pencil in the sequence of changes
> to satisfy them.
>
> Please remember that the open source community is vital to the Go
> ecosystem. We can't thank you enough for your contributions.

Hi!

My plans are:
- faster/better GC/malloc, mainly based on
https://docs.google.com/document/d/1HCPu3WKyCX3ZRYxmIMKTk0Ik1dePxKW1p02k3uhcft4/edit
but to be discussed (not sure if I will be able to do it all, but it
would be great)

- faster buffered channels
(https://docs.google.com/document/d/1yIAYmbvL3JxOKOjuCyon7JhW4cSv1wy5hC0ApeGMV9s/edit#heading=h.h23m1dwm0wep)
this must synchronize with Keith C->Go chan.goc transformation

- faster unbuffered channels [stretch]

- faster timers [stretch^2]

- better race detector (this should not conflict with other work, as
most changes will be in the race runtime):
- update to tip runtime
- output heap block allocation stack
- detect races between atomic and non-atomic accesses
- describe mutexes hold around racy accesses
- detect deadlocks [stretch]

Erwin

unread,
Jun 10, 2014, 8:05:55 PM6/10/14
to Dave Cheney, golang-dev
On 10 June 2014 03:27, Dave Cheney <da...@cheney.net> wrote:



On Mon, Jun 9, 2014 at 5:56 AM, <snes...@gmail.com> wrote:
Support methods written in assembly.
Support all SIMD x86 instructions in 6a and 8a, if possible also other current non-SIMD instructions.

This has been requested before. Can you please make sure an issue detailing the instructions that you would like to see added is filed.

 
Issue 4978 is about methods in assembly.
I could not find specific issues about the lack of some SSE instructions in 6a and 8a.

Ed Swierk

unread,
Jun 11, 2014, 10:33:29 AM6/11/14
to golan...@googlegroups.com, da...@cheney.net
On Thursday, June 5, 2014 2:47:18 PM UTC-7, Ian Lance Taylor wrote:
All that aside, yes, I think that any general modifications needed to
make the go tool build and work with gccgo should be committed.

I'd like to be able to use a single instance of the go tool with both gc and gccgo backends, rather than needing a specially-built go tool just for gccgo. I posted patches a few weeks ago:


--Ed

Ian Lance Taylor

unread,
Jun 11, 2014, 10:39:57 AM6/11/14
to Ed Swierk, golang-dev, Dave Cheney
To contribute patches, please follow the process described at
http://golang.org/doc/contribute.html . Thanks.

Ian

Michael Jones

unread,
Jun 11, 2014, 5:35:42 PM6/11/14
to Erwin, Dave Cheney, golang-dev
I use methods in assembly all the time. The patch is tiny and well understood. The only holdup last time was Rob being cautious about committing publicly to the method calling sequence and stack expectations. If things have settled a bit then maybe it is time...


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



--
Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

minux

unread,
Jun 11, 2014, 5:55:01 PM6/11/14
to Michael Jones, Erwin, Dave Cheney, golang-dev
On Wed, Jun 11, 2014 at 5:35 PM, 'Michael Jones' via golang-dev <golan...@googlegroups.com> wrote:
I use methods in assembly all the time. The patch is tiny and well understood. The only holdup last time was Rob being cautious about committing publicly to the method calling sequence and stack expectations. If things have settled a bit then maybe it is time...
I think what we really need is the ability to inline assembly functions. 

Ingo Oeser

unread,
Jun 11, 2014, 6:08:34 PM6/11/14