2012-09-24 18:57:01 -06:00
<!-- {
"Title": "Go 1.1 Release Notes",
2012-09-26 09:49:36 -06:00
"Path": "/doc/go1.1",
2012-09-24 18:57:01 -06:00
"Template": true
}-->
< h2 id = "introduction" > Introduction to Go 1.1< / h2 >
TODO
- overview
- link back to Go 1 and also Go 1 Compatibility docs.
< h2 id = "language" > Changes to the language< / h2 >
TODO
< h2 id = "impl" > Changes to the implementations and tools< / h2 >
TODO: more
< h3 id = "int" > Size of int on 64-bit platforms< / h3 >
< p >
The language allows the implementation to choose whether the < code > int< / code > type and < code > uint< / code > types are 32 or 64 bits. Previous Go implementations made < code > int< / code > and < code > uint< / code > 32 bits on all systems. Both the gc and gccgo implementations (TODO: check that gccgo does) < a href = "http://golang.org/issue/2188" > now make < code > int< / code > and < code > uint< / code > 64 bits on 64-bit platforms such as AMD64/x86-64< / a > .
Among other things, this enables the allocation of slices with
more than 2 billion elements on 64-bit platforms.
< / p >
< p >
< em > Updating< / em > :
Most programs will be unaffected by this change.
Because Go does not allow implicit conversions between distinct
< a href = "/ref/spec#Numeric_types" > numeric types< / a > ,
no programs will stop compiling due to this change.
However, programs that contain implicit assumptions
that < code > int< / code > is only 32 bits may change behavior.
For example, this code prints a positive number on 64-bit systems and
a negative one on 32-bit systems:
< pre >
x := ^uint32(0) // x is 0xffffffff
i := int(x) // i is -1 on 32-bit systems, 0xffffffff on 64-bit
fmt.Println(i)
< / pre >
< p > Portable code intending 32-bit sign extension (yielding -1 on all systems)
would instead say:
< / p >
< pre >
i := int(int32(x))
< / pre >
< h3 id = "asm" > Assembler< / h3 >
< p >
Due to the < a href = "#int" > int< / a > and TODO: OTHER changes,
the placement of function arguments on the stack has changed.
Functions written in assembly will need to be revised at least
to adjust frame pointer offsets.
< / p >
2013-01-02 05:38:47 -07:00
< h3 id = "race" > Data race detector< / h3 >
< p >
The implementation now includes a built-in < a href = "/doc/articles/race_detector.html" > data race detector< / a > .
< / p >
2012-09-24 18:57:01 -06:00
< h2 id = "library" > Changes to the standard library< / h2 >
2012-11-14 08:24:14 -07:00
< h3 id = "debug/elf" > debug/elf< / h3 >
< p >
Previous versions of the debug/elf package intentionally skipped over the first
symbol in the ELF symbol table, since it is always an empty symbol. This symbol
is no longer skipped since indexes into the symbol table returned by debug/elf,
will be different to indexes into the original ELF symbol table. Any code that
calls the debug/elf functions Symbols or ImportedSymbols may need to be
adjusted to account for the additional symbol and the change in symbol offsets.
< / p >
2012-12-10 16:08:07 -07:00
< h3 id = "net" > net< / h3 >
< p >
The protocol-specific resolvers were formerly
lax about the network name passed in. For example, although the documentation was clear
that the only valid networks for < code > ResolveTCPAddr< / code > are < code > "tcp"< / code > ,
< code > "tcp4"< / code > , and < code > "tcp6"< / code > , the Go 1.0 implementation silently accepted
any string. The Go 1.1 implementation returns an error if the network is not one of those strings.
The same is true of the other protocol-specific resolvers < code > ResolveIPAddr< / code > , < code > ResolveUDPAddr< / code > , and
< code > ResolveUnixAddr< / code > .
< / p >
2012-12-15 19:51:47 -07:00
< p >
The previous < code > ListenUnixgram< / code > returned < code > UDPConn< / code > as
arepresentation of the connection endpoint. The Go 1.1 implementation
returns < code > UnixConn< / code > to allow reading and writing
with < code > ReadFrom< / code > and < code > WriteTo< / code > methods on
the < code > UnixConn< / code > .
< / p >
2012-12-10 16:08:07 -07:00
2012-12-09 01:59:33 -07:00
< h3 id = "time" > time< / h3 >
< p >
runtime: use clock_gettime to get ns resolution for time.now & runtime.nanotime
For Linux/{386,arm}, FreeBSD/{386,amd64,arm}, NetBSD/{386,amd64}, OpenBSD/{386,amd64}.
Note: our Darwin implementation already has ns resolution.
Linux/386 (Core i7-2600 @ 3.40GHz, kernel 3.5.2-gentoo)
benchmark old ns/op new ns/op delta
BenchmarkNow 110 118 +7.27%
Linux/ARM (ARM Cortex-A8 @ 800MHz, kernel 2.6.32.28 android)
benchmark old ns/op new ns/op delta
BenchmarkNow 625 542 -13.28%
Linux/ARM (ARM Cortex-A9 @ 1GHz, Pandaboard)
benchmark old ns/op new ns/op delta
BenchmarkNow 992 909 -8.37%
FreeBSD 9-REL-p1/amd64 (Dell R610 Server with Xeon X5650 @ 2.67GHz)
benchmark old ns/op new ns/op delta
BenchmarkNow 699 695 -0.57%
FreeBSD 9-REL-p1/amd64 (Atom D525 @ 1.80GHz)
benchmark old ns/op new ns/op delta
BenchmarkNow 1553 1658 +6.76%
OpenBSD/amd64 (Dell E6410 with i5 CPU M 540 @ 2.53GHz)
benchmark old ns/op new ns/op delta
BenchmarkNow 1262 1236 -2.06%
OpenBSD/i386 (Asus eeePC 701 with Intel Celeron M 900MHz - locked to 631MHz)
benchmark old ns/op new ns/op delta
BenchmarkNow 5089 5043 -0.90%
NetBSD/i386 (VMware VM with Core i5 CPU @ 2.7GHz)
benchmark old ns/op new ns/op delta
BenchmarkNow 277 278 +0.36%
NetBSD/amd64 (VMware VM with Core i5 CPU @ 2.7Ghz)
benchmark old ns/op new ns/op delta
BenchmarkNow 103 105 +1.94%
Thanks Maxim Khitrov, Joel Sing, and Dave Cheney for providing benchmark data.
R=jsing, dave, rsc
CC=golang-dev
https://golang.org/cl/6820120
2012-12-18 07:57:25 -07:00
On FreeBSD, Linux, NetBSD, OS X and OpenBSD, previous versions of the time package
returned times with microsecond precision. The Go 1.1 implementation of time on these
systems now returns times with nanosecond precision. Code may exist that expects to be
able to store such a time in an external format with only microsecond precision,
2012-12-09 01:59:33 -07:00
read it back, and recover exactly the same time instant.
In Go 1.1 the same time will not be recovered, since the external storage
will have discarded nanoseconds.
To address this case, there are two new methods of time.Time, Round and Truncate,
that can be used to remove precision from a time before passing it to
external storage.
< / p >
2012-09-24 18:57:01 -06:00
TODO