Go 1.1 Release Candidate 2 released

[Andrew Gerrand]

Hi Go nuts,

We have just released go1.1rc2, a release candidate for Go 1.1.

This release candidate should be stable and production-ready, but please exercise caution when deploying it to critical systems.

Please help us by testing your Go programs with the new tool chain and libraries, and report any problems using the issue tracker:
    http://golang.org/issue/new

You can download binary and source distributions from the usual place:

    https://code.google.com/p/go/downloads/list?q=go1.1rc2

To compile from source, update to the go1.1rc2 tag with "hg update go1.1rc2" and build as usual.

To find out what has changed, read the release notes for Go 1.1:
    http://tip.golang.org/doc/go1.1.html

Documentation for Go 1.1 is available at http://tip.golang.org/

Thanks to everyone who has contributed to the release so far.

Andrew

[Keith Rarick]

Congrats everyone! So close.

I just updated the Heroku Go buildpack's go1.1 branch
to pull go1.1rc2 by default. As a reminder, if you're
already using this branch, you don't have to do anything;
your next push will use RC2.

For more information, see the Go buildpack's readme at:
https://github.com/kr/heroku-buildpack-go

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Aaron France]

Really good job to all

On Tue, May 7, 2013 at 3:18 PM, <luz...@gmail.com> wrote:

On Tuesday, May 7, 2013 2:34:48 PM UTC+2, jo...@citessentials.com wrote:

What are the changes from RC1 to RC2?

The commits from May 1 till today: https://code.google.com/p/go/source/list 

[Dave Cheney]

With thanks to adg who lent me a copy of his release notes formatting
script, here are the changes between rc1 and rc2

* C: add Jeremiah Harmsen (Google CLA).
* cmd/cgo: correct pragma name in comment.
* cmd/ld: add .note.GNU-stack section for external linking (thanks Shenghou Ma),
fix SDYNIMPORT symbol test (thanks Alex Brainman),
fix another unsigned value causing bugs on Plan 9,
fix syms that are both cgo_import_static & cgo_import_dynamic.
* database/sql: remove an unused field from Rows.
* doc: add FAQ entry about language changes,
fix formatting in effective go code snippet,
link to Go 1.1 release notes,
only U+FEFF is a byte-order mark; U+FFFE is not.
* go/build: document GOOS.go also has implicit GOOS build constraint
(thanks Shenghou Ma).
* go/doc/example: Fix bug causing false negatives for Example playability.
* image/png: fix error message to not return width twice.
* libmach: fix build on Plan 9 (thanks David du Colombier).
* net: do not call syscall.Bind twice on windows (thanks Alex Brainman).
* regexp: doc fix.
* runtime/cgo: export symbols in both internal and external link mode.
* runtime: fix crash in badsignal(),
reduce max arena size on windows/amd64 to 32 GiB (thanks Shenghou Ma).
* syscall: fix prototype of Fchflags (API change) (thanks Shenghou Ma).
* text/template: comment fix.

[Andrew Gerrand]

On 7 May 2013 09:16, <tr...@wireover.com> wrote:

When is issue 909 (https://code.google.com/p/go/issues/detail?id=909) going to be addressed?

It should be mostly addressed by improvements to the garbage collector in 1.1.

If you've experienced the issues, please try Go 1.1 and see if the problem persists, and update the issue with your results.

Andrew

 

[steve wang]

It's said that the GC pause in Go1.1 takes more time than in Go1.0.3.

Is there a plan for improvement? 

[Dave Cheney]

> It's said that the GC pause in Go1.1 takes more time than in Go1.0.3.
> Is there a plan for improvement?

Can you please provide supporting evidence for this statement. I
suggest posting the output of running a sample program compiled with
1.0.3 and 1.1rc and the GOGCTRACE=1 environment setting.

[Andrew Gerrand]

On 7 May 2013 09:32, steve wang <steve....@gmail.com> wrote:

It's said that the GC pause in Go1.1 takes more time than in Go1.0.3.

Is there a plan for improvement? 

This is a very vague statement. The benchmarks we have indicate significant overall performance improvements. 

[steve wang]

Well, I heard it from the guy whose orignal post can be reached at https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/S9goEGuoMRM

I will try to bring him back here and ask him to explain more.

[Ian Lance Taylor]

On Tue, May 7, 2013 at 9:46 AM, steve wang <steve....@gmail.com> wrote:
> Well, I heard it from the guy whose orignal post can be reached at
> https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/S9goEGuoMRM
> I will try to bring him back here and ask him to explain more.

The garbage collector has changed significantly since November 2012.
Is this based on a more recent version of Go, such as the Go 1.1
release candidate?

Ian

> On Wednesday, May 8, 2013 12:34:14 AM UTC+8, Andrew Gerrand wrote:
>>
>>
>> On 7 May 2013 09:32, steve wang <steve....@gmail.com> wrote:
>>>
>>> It's said that the GC pause in Go1.1 takes more time than in Go1.0.3.
>>> Is there a plan for improvement?
>>
>>
>> This is a very vague statement. The benchmarks we have indicate
>> significant overall performance improvements.
>>

[steve wang]

On Wednesday, May 8, 2013 1:11:37 AM UTC+8, Ian Lance Taylor wrote:

On Tue, May 7, 2013 at 9:46 AM, steve wang <steve....@gmail.com> wrote:
> Well, I heard it from the guy whose orignal post can be reached at
> https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/S9goEGuoMRM
> I will try to bring him back here and ask him to explain more.

The garbage collector has changed significantly since November 2012.
Is this based on a more recent version of Go, such as the Go 1.1
release candidate?

Ian

He complained on weibo, the Chinese version of twitter, that Go1.1beta2 did not help with his issue and even performed worse.

He has agreed to show some data here tomorrow.

[Dan Kortschak]

Is there a catch-all go1.0 hg tag to make go get pull a specific
revision of a repo when the client is go1.0.*? Or should I just tag the
desired revision with all the go1.0 tags?

[Andrew Gerrand]

There's no catch-all tag. You'll have to use all the tags.

[Dan Kortschak]

On Tue, 2013-05-07 at 18:06 -0700, Andrew Gerrand wrote:
> There's no catch-all tag. You'll have to use all the tags.

Thanks.

[Jingcheng Zhang]

I'm the poster.

We tried Go 1.1beta2 and a revision in Nov 2012 in our cluster, each built with different version, and running the same codes.

The results are:

Nov 2012

--------------

Load: 0.81, 0.79, 0.70

Mem: 26.1GB VIRT, 15GB RES

GC Stop: 5~6 seconds

Go 1.1beta2

------------------

Load 1.33, 1.49, 1.34

Mem: 120GB VIRT, 30GB RES

GC Stop: 10~11 seconds

The cluster load is balanced, so the results reflect the performance regression.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Best regards,
Jingcheng Zhang
Beijing, P.R.China

[Andrew Gerrand]

On 7 May 2013 20:21, Jingcheng Zhang <dio...@gmail.com> wrote:

Nov 2012

--------------

Load: 0.81, 0.79, 0.70

Mem: 26.1GB VIRT, 15GB RES

GC Stop: 5~6 seconds

Go 1.1beta2

------------------

Load 1.33, 1.49, 1.34

Mem: 120GB VIRT, 30GB RES

GC Stop: 10~11 seconds

Your heap is twice as big and the GC pause is twice as long. This is what I would expect, and doesn't seem to be evidence of a regression.

How can you be sure that the load is identical?

Andrew

[Jan Mercl]

On Tue, May 7, 2013 at 5:21 AM, Andrew Gerrand <a...@google.com> wrote:
> Please help us by testing your Go programs with the new tool chain and
> libraries, and report any problems using the issue tracker:
> http://golang.org/issue/new

Before using the tracker I'd first like to ask if I'm missing something or not:

(12:09) jnml@fsc-r550:~/src/github.com/cznic/js$ rm -rf ~/pkg
(12:09) jnml@fsc-r550:~/src/github.com/cznic/js$ go test
... <snip> ...
PASS
ok github.com/cznic/js 1.220s
(12:09) jnml@fsc-r550:~/src/github.com/cznic/js$ rm -rf ~/pkg
(12:09) jnml@fsc-r550:~/src/github.com/cznic/js$ go test -race
... <snip> ...
# github.com/cznic/js
./parse_statement.go:149: label .inlret000247 already defined at
./parse_statement.go:149
./parse_statement.go:149: too many errors
FAIL github.com/cznic/js [build failed]
(12:10) jnml@fsc-r550:~/src/github.com/cznic/js$ go version
go version go1.1rc2 linux/amd64
(12:10) jnml@fsc-r550:~/src/github.com/cznic/js$

IOW, it seems like the -race instrumentation can sometimes break the
compiler. (?)

-j

[Rémy Oudompheng]

Yes, please report an issue. I suppose the race instrumentation is not
as throughly tested as the ordinary compilation path.

Rémy.

[Jan Mercl]

On Wed, May 8, 2013 at 12:22 PM, Rémy Oudompheng
<remyoud...@gmail.com> wrote:
> Yes, please report an issue. I suppose the race instrumentation is not
> as throughly tested as the ordinary compilation path.

https://code.google.com/p/go/issues/detail?id=5431

-j