Austin Clements [Wed, 30 Mar 2016 21:15:15 +0000 (17:15 -0400)]
runtime: eliminate floating garbage estimate
Currently when we compute the trigger for the next GC, we do it based
on an estimate of the reachable heap size at the start of the GC
cycle, which is itself based on an estimate of the floating garbage.
This was introduced by 4655aad to fix a bad feedback loop that allowed
the heap to grow to many times the true reachable size.
However, this estimate gets easily confused by rapidly allocating
applications, and, worse it's different than the heap size the trigger
controller uses to compute the trigger itself. This results in the
trigger controller often thinking that GC finished before it started.
Since this would be a pretty great outcome from it's perspective, it
sets the trigger for the next cycle as close to the next goal as
possible (which is limited to 95% of the goal).
Furthermore, the bad feedback loop this estimate originally fixed
seems not to happen any more, suggesting it was fixed more correctly
by some other change in the mean time. Finally, with the change to
allocate black, it shouldn't even be theoretically possible for this
bad feedback loop to occur.
Hence, eliminate the floating garbage estimate and simply consider the
reachable heap to be the marked heap. This harms overall throughput
slightly for allocation-heavy benchmarks, but significantly improves
mutator availability.
Fixes #12204. This brings the average trigger in this benchmark from
0.95 (the cap) to 0.7 and the active GC utilization from ~90% to ~45%.
Updates #14951. This makes the trigger controller much better behaved,
so it pulls the trigger lower if assists are consuming a lot of CPU
like it's supposed to, increasing mutator availability.
name old time/op new time/op delta
XBenchGarbage-12 2.21ms ± 1% 2.28ms ± 3% +3.29% (p=0.000 n=17+17)
Some of this slow down we paid for in earlier commits. Relative to the
start of the series to switch to allocate-black (the parent of "count
black allocations toward scan work"), the garbage benchmark is 2.62%
slower.
Austin Clements [Wed, 30 Mar 2016 21:02:23 +0000 (17:02 -0400)]
runtime: allocate black during GC
Currently we allocate white for most of concurrent marking. This is
based on the classical argument that it produces less floating
garbage, since allocations during GC may not get linked into the heap
and allocating white lets us reclaim these. However, it's not clear
how often this actually happens, especially since our write barrier
shades any pointer as soon as it's installed in the heap regardless of
the color of the slot.
On the other hand, allocating black has several advantages that seem
to significantly outweigh this downside.
1) It naturally bounds the total scan work to the live heap size at
the start of a GC cycle. Allocating white does not, and thus depends
entirely on assists to prevent the heap from growing faster than it
can be scanned.
2) It reduces the total amount of scan work per GC cycle by the size
of newly allocated objects that are linked into the heap graph, since
objects allocated black never need to be scanned.
3) It reduces total write barrier work since more objects will already
be black when they are linked into the heap graph.
This gives a slight overall improvement in benchmarks.
name old time/op new time/op delta
XBenchGarbage-12 2.24ms ± 0% 2.21ms ± 1% -1.32% (p=0.000 n=18+17)
Currently allocating black switches to the system stack (which is
probably a historical accident) and atomically updates the global
bytes marked stat. Since we're about to depend on this much more,
optimize it a bit by putting it back on the regular stack and updating
the per-P bytes marked stat, which gets lazily folded into the global
bytes marked stat.
Currently we count black allocations toward the scannable heap size,
but not toward the scan work we've done so far. This is clearly
inconsistent (we have, in effect, scanned these allocations and since
they're already black, we're not going to scan them again). Worse, it
means we don't count black allocations toward the scannable heap size
as of the *next* GC because this is based on the amount of scan work
we did in this cycle.
Fix this by counting black allocations as scan work. Currently the GC
spends very little time in allocate-black mode, so this probably
hasn't been a problem, but this will become important when we switch
to always allocating black.
Marcel van Lohuizen [Fri, 29 Jan 2016 15:16:03 +0000 (16:16 +0100)]
testing: add matching of subtest
Allows passing regexps per subtest to --test.run and --test.bench
Note that the documentation explicitly states that the split regular
expressions match the correpsonding parts (path components) of
the bench/test identifier. This is intended and slightly different
from the i'th RE matching the subtest/subbench at the respective
level. Picking this semantics allows guaranteeing that a test or
benchmark identifier as printed by go test can be passed verbatim
(possibly quoted) to, respectively, -run or -bench: subtests and
subbenches might have a '/' in their name, causing a misaligment if
their ID is passed to -run or -bench as is.
This semantics has other benefits, but this is the main motivation.
cmd/compile/internal/gc: fix return value offset for SSA backend on ARM
Progress on SSA backend for ARM. Still not complete. It compiles a
Fibonacci function, but the caller picked the return value from an
incorrect offset. This CL adjusts it to match the stack frame layout
for architectures with link register.
Alex Brainman [Thu, 21 Apr 2016 01:44:05 +0000 (11:44 +1000)]
debug/pe: introduce Section.Relocs
cmd/link reads PE object files when building programs with cgo.
cmd/link accesses object relocations. Add new Section.Relocs that
provides similar functionality in debug/pe.
Robert Griesemer [Wed, 20 Apr 2016 20:40:55 +0000 (13:40 -0700)]
math/big: more tests, documentation for Flot gob marshalling
Follow-up to https://golang.org/cl/21755.
This turned out to be a bit more than just a few nits
as originally expected in that CL.
1) The actual mantissa may be shorter than required for the
given precision (because of trailing 0's): no need to
allocate space for it (and transmit 0's). This can save
a lot of space when the precision is high: E.g., for
prec == 1000, 16 words or 128 bytes are required at the
most, but if the actual number is short, it may be much
less (for the test cases present, it's significantly less).
2) The actual mantissa may be longer than the number of
words required for the given precision: make sure to
not overflow when encoding in bytes.
3) Add more documentation.
4) Add more tests.
Change-Id: I9f40c408cfdd9183a8e81076d2f7d6c75e7a00e9
Reviewed-on: https://go-review.googlesource.com/22324 Reviewed-by: Alan Donovan <adonovan@google.com>
Keith Randall [Tue, 19 Apr 2016 15:31:04 +0000 (08:31 -0700)]
cmd/compile: change the way we handle large map values
mapaccess{1,2} returns a pointer to the value. When the key
is not in the map, it returns a pointer to zeroed memory.
Currently, for large map values we have a complicated scheme which
dynamically allocates zeroed memory for this purpose. It is ugly
code and requires an atomic.Load in a bunch of places we'd rather
not have it.
Switch to a scheme where callsites of mapaccess{1,2} which expect
large return values pass in a pointer to zeroed memory that
mapaccess can return if the key is not found. This avoids the
atomic.Load on all map accesses with a few extra instructions only
for the large value acccesses, plus a bit of bss space.
There was a time (1.4 & 1.5?) where we did something like this but
all the tricks to make the right size zero value were done by the
linker. That scheme broke in the presence of dyamic linking.
The scheme in this CL works even when dynamic linking.
Fixes #12337
Change-Id: Ic2d0319944af33bbb59785938d9ab80958d1b4b1
Reviewed-on: https://go-review.googlesource.com/22221
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Michael Munday [Fri, 15 Apr 2016 22:45:17 +0000 (18:45 -0400)]
crypto/aes: add s390x assembly implementation
Adds support for single block encryption using the cipher message
(KM) instruction. KM handles key expansion internally and
therefore it is not done up front when using the assembly
implementation on s390x.
Change-Id: I69954b8ae36d549e1dc40d7acd5a10bedfaaef9c
Reviewed-on: https://go-review.googlesource.com/22194
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bill O'Farrell <billotosyr@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Alex Brainman [Mon, 18 Apr 2016 06:12:48 +0000 (16:12 +1000)]
debug/pe: introduce StringTable type
PE specification requires that long section and symbol names
are stored in PE string table. Introduce StringTable that
implements this functionality. Only string table reading is
implemented.
Keith Randall [Tue, 19 Apr 2016 22:38:59 +0000 (15:38 -0700)]
cmd/compile,runtime: pass elem type to {make,grow}slice
No point in passing the slice type to these functions.
All they need is the element type. One less indirection,
maybe a few less []T type descriptors in the binary.
There's no need for Eiota, Eindir, Eaddr, or Eproc; the values are
threaded through to denote various typechecking contexts, but they
don't actually influence typechecking behavior at all.
Also, while here, switch the Efoo const declarations to use iota.
Julia Hansbrough [Mon, 18 Apr 2016 22:53:29 +0000 (15:53 -0700)]
runtime: updated SIGSYS to cause a panic + stacktrace
On GNU/Linux, SIGSYS is specified to cause the process to terminate
without a core dump. In https://codereview.appspot.com/3749041 , it
appears that Golang accidentally introduced incorrect behavior for
this signal, which caused Golang processes to keep running after
receiving SIGSYS. This change reverts it to the old/correct behavior.
Updates #15204
Change-Id: I3aa48a9499c1bc36fa5d3f40c088fdd7599e0db5
Reviewed-on: https://go-review.googlesource.com/22202 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously, isStaticCompositeLiteral would
return the wrong value for literals like:
[1]struct{ b []byte }{b: []byte{1}}
Note that the outermost component is an array,
but once we recurse into isStaticCompositeLiteral,
we never check again that arrays are actually arrays.
Instead of adding more logic to the guts of
isStaticCompositeLiteral, allow it to accept
any Node and return the correct answer.
Change-Id: I6af7814a9037bbc7043da9a96137fbee067bbe0e
Reviewed-on: https://go-review.googlesource.com/22247 Reviewed-by: Keith Randall <khr@golang.org>
Michael Munday [Fri, 15 Apr 2016 20:56:37 +0000 (16:56 -0400)]
crypto/aes: de-couple asm and go implementations
There is currently only one assembly implementation of AES
(amd64). While it is possible to fit other implementations to the
same pattern it complicates the code. For example s390x does not
use expanded keys, so having enc and dec in the aesCipher struct
is confusing.
By separating out the asm implementations we can more closely
match the data structures to the underlying implementation. This
also opens the door for AES implementations that support block
cipher modes other than GCM (e.g. CTR and CBC).
This commit changes BenchmarkExpandKey to test the go
implementation of key expansion. It might be better to have some
sort of 'initialisation' benchmark instead to cover the startup
costs of the assembly implementations (which might be doing
key expansion in a different way, or not at all).
CL 21891 was too clever in its attempts to avoid spills.
Storing newlen too early caused uses of append in the runtime
itself to receive an inconsistent view of a slice,
leading to corruption.
This CL makes the generate code much more similar to
the old backend. It spills more than before,
but those spills have been contained to the grow path.
It recalculates newlen unnecessarily on the fast path,
but that's measurably cheaper than spilling it.
CL 21891 caused runtime failures in 6 of 2000 runs
of net/http and crypto/x509 in my test setup.
This CL has gone 6000 runs without a failure.
Robert Griesemer [Fri, 26 Feb 2016 23:52:13 +0000 (15:52 -0800)]
spec: refine rules about terminating statements
Per a suggestion from mdempsky.
Both gc and gccgo consider a statement list as terminating if the
last _non_empty_ statement is terminating; i.e., trailing semis are
ok. Only gotype followed the current stricter rule in the spec.
This change adjusts the spec to match gc and gccgo behavior. In
support of this change, the spec has a matching rule for fallthrough,
which in valid positions may be followed by trailing semis as well.
For details and examples, see the issue below.
Fixes #14422.
Change-Id: Ie17c282e216fc40ecb54623445c17be111e17ade
Reviewed-on: https://go-review.googlesource.com/19981 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
Michael Munday [Fri, 15 Apr 2016 19:20:24 +0000 (15:20 -0400)]
crypto/aes: delete TestEncryptBlock and TestDecryptBlock
The encryptBlock and decryptBlock functions are already tested
(via the public API) by TestCipherEncrypt and TestCipherDecrypt
respectively. Both sets of tests check the output of the two
functions against the same set of FIPS 197 examples. I therefore
think it is safe to delete these two tests without losing any
coverage.
Deleting these two tests will make it easier to modify the
internal API, which I am hoping to do in future CLs.
Change-Id: I0dd568bc19f47b70ab09699b507833e527d39ba7
Reviewed-on: https://go-review.googlesource.com/22115 Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Mikio Hara [Sun, 28 Feb 2016 00:37:36 +0000 (09:37 +0900)]
net: add support for Zone of IPNet
This change adds Zone field to IPNet structure for making it possible to
determine which network interface is associated with IPv6 link-local
address. Also makes ParseCIDR and IPNet.String capable handling literal
IPv6 address prefixes with zone identifier.
Fixes #14518.
Change-Id: I8f8a40d3b4f500ffef25728d4995651379d8408a
Reviewed-on: https://go-review.googlesource.com/19946 Reviewed-by: Ian Lance Taylor <iant@golang.org>
David du Colombier [Tue, 19 Apr 2016 01:19:12 +0000 (03:19 +0200)]
net: enable TestDialParallel, TestDialerFallbackDelay and TestDialCancel on Plan 9
TestDialParallel, TestDialerFallbackDelay and TestDialCancel
require dialTCP to support cancellation, which has been
implemented for Plan 9 in CL 22144.
Updates #11225.
Updates #11932.
Change-Id: I3b30a645ef79227dfa519cde8d46c67b72f2485c
Reviewed-on: https://go-review.googlesource.com/22203
Run-TryBot: David du Colombier <0intro@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
David Crawshaw [Wed, 6 Apr 2016 17:09:06 +0000 (13:09 -0400)]
cmd/link: shorter type symbol names
Use (part of) a SHA-1 checksum to replace type symbol names.
In typical programs this has no effect because types are not included
in the symbol table. But when dynamically linking, types are in the
table to make sure there is only one *rtype per Go type.
Eventually we may be able to get rid of all pointers to rtype values in
the binary, but probably not by 1.7. And this has a nice effect on
binary size today:
David Crawshaw [Mon, 4 Apr 2016 17:07:24 +0000 (13:07 -0400)]
cmd/link, cmd/compile: typelink sorting in linker
Instead of writing out the type almost twice in the symbol name,
teach the linker how to sort typelink symbols by their contents.
This ~halves the size of typelink symbol names, which helps very
large (6KB) names like those mentioned in #15104.
This does not increase the total sorting work done by the linker,
and makes it possible to use shorter symbol names for types. See
the follow-on CL 21583.
Change-Id: Ie5807565ed07d31bc477d20f60e4c0b47144f337
Reviewed-on: https://go-review.googlesource.com/21457 Reviewed-by: Ian Lance Taylor <iant@golang.org>
David Crawshaw [Mon, 18 Apr 2016 08:50:19 +0000 (04:50 -0400)]
reflect: test that method name offset is valid
Bug fix went in CL 21396, this is a matching test.
Fixes #15343
Change-Id: I3670145c7cac45cb4fb3121ffc039cfb7fa7c87a
Reviewed-on: https://go-review.googlesource.com/22171 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Keith Randall [Mon, 18 Apr 2016 18:17:55 +0000 (11:17 -0700)]
cmd/compile: eliminate copy for static literals
*p = [5]byte{1,2,3,4,5}
First we allocate a global containing the RHS. Then we copy
that global to a local stack variable, and then copy that local
stack variable to *p. The intermediate copy is unnecessary.
Note that this only works if the RHS is completely constant.
If the code was:
*p = [5]byte{1,2,x,4,5}
this optimization doesn't apply as we have to construct the
RHS on the stack before copying it to *p.
net: fix plan9 after context change, propagate contexts more
My previous https://golang.org/cl/22101 to add context throughout the
net package broke Plan 9, which isn't currently tested (#15251).
It also broke some old unsupported version of Windows (Windows 2000?)
which doesn't have the ConnectEx function, but that was only found
visually, since our minimum supported Windows version has ConnectEx.
This change simplifies the Windows and deletes the non-ConnectEx code
path. Windows 2000 will work even less now, if it even worked
before. Windows XP remains our minimum supported version.
Specifically, the previous CL stopped using the "dial" function, which
0intro noted:
https://github.com/golang/go/issues/15333#issuecomment-210842761
This CL removes the dial function instead and makes plan9's net
implementation respect contexts, which likely fixes a number of
t.Skipped tests. I'm leaving that to 0intro to investigate.
In the process of propagating and respecting contexts for plan9, I had
to change some signatures to add contexts to more places and ended up
pushing contexts down into the Go-based DNS resolution as well,
replacing the pure-Go DNS implementation's use of "timeout
time.Duration" with a context instead.
Updates #11932
Updates #15328
Fixes #15333
Change-Id: I6ad1e62f38271cdd86b3f40921f2d0f23374936a
Reviewed-on: https://go-review.googlesource.com/22144 Reviewed-by: David du Colombier <0intro@gmail.com> Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
David Crawshaw [Mon, 18 Apr 2016 11:24:48 +0000 (07:24 -0400)]
cmd/link: use gold when dynamic linking on arm64
The GNU linker follows the letter of -znocopyreloc by refusing to
generate COPY relocations on arm64. Unfortunately it generates an
error instead of finding another way. The gold linker works, so
switch to it.
David Crawshaw [Tue, 29 Mar 2016 01:51:10 +0000 (21:51 -0400)]
cmd/compile, etc: use name offset in method tables
Introduce and start using nameOff for two encoded names. This pair
of changes is best done together because the linker's method decoder
expects the method layouts to match.
Precursor to converting all existing name and *string fields to
nameOff.
Change-Id: Ia044423f010fb987ce070b94c46a16fc78666ff6
Reviewed-on: https://go-review.googlesource.com/21396 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Klaus Post [Sun, 10 Apr 2016 10:00:13 +0000 (12:00 +0200)]
compress/flate: use uncompressed if dynamic encoding is larger
This adds size calculation to "dynamic" writes.
This ensures that if dynamic Huffman encoding is bigger,
or only slightly smaller than raw data, the block is written
uncompressed.
To minimize the code duplication of this function, the
size calculation has been moved to separate functions.
Since I was modifying these calculations, I changed "int64"
size calculations to "int". Blocks are of very limited size,
so there is not any risk of overflows.
This should mainly improve 32 bit performance, but amd64 also
gets a slight boost:
cmd/compile/internal/ssa: use Compare instead of Equal
They have different semantics.
Equal is stricter and is designed for the front-end.
Compare is looser and cheaper and is designed for the back-end.
To avoid possible regression, remove Equal from ssa.Type.
encoding/json: update docs to not use misuse the term "object"
In JSON terminology, "object" is a collect of key/value pairs. But a
JSON object is only one type of JSON value (others are string, number,
array, true, false, null).
This updates the Go docs (at least the public godoc) to not use
"object" when we mean any JSON value.
Change-Id: Ieb1c456c703693714d63d9d09d306f4d9e8f4597
Reviewed-on: https://go-review.googlesource.com/22003 Reviewed-by: Andrew Gerrand <adg@golang.org>
runtime: scavenge memory on physical page-aligned boundaries
Currently the scavenger marks memory unused in multiples of the
allocator page size (8K). This is safe as long as the true physical
page size is 4K (or 8K), as it is on many platforms. However, on
ARM64, PPC64x, and MIPS64, the physical page size is larger than 8K,
so if we attempt to mark memory unused, the kernel will round the
boundaries of the region *out* to all pages covered by the requested
region, and we'll release a larger region of memory than intended. As
a result, the scavenger is currently disabled on these platforms.
Fix this by first rounding the region to be marked unused *in* to
multiples of the physical page size, so that when we ask the kernel to
mark it unused, it releases exactly the requested region.
Fixes #9993.
Change-Id: I96d5fdc2f77f9d69abadcea29bcfe55e68288cb1
Reviewed-on: https://go-review.googlesource.com/22066 Reviewed-by: Rick Hudson <rlh@golang.org>
runtime: check that sysUnused is always physical-page aligned
If sysUnused is passed an address or length that is not aligned to the
physical page boundary, the kernel will unmap more memory than the
caller wanted. Add a check for this.
For #9993.
Change-Id: I68ff03032e7b65cf0a853fe706ce21dc7f2aaaf8
Reviewed-on: https://go-review.googlesource.com/22065 Reviewed-by: Rick Hudson <rlh@golang.org> Reviewed-by: Dave Cheney <dave@cheney.net> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
runtime: check kernel physical page size during init
The runtime hard-codes an assumed physical page size. If this is
smaller than the kernel's page size or not a multiple of it, sysUnused
may incorrectly release more memory to the system than intended.
Add a runtime startup check that the runtime's assumed physical page
is compatible with the kernel's physical page size.
For #9993.
Change-Id: Ida9d07f93c00ca9a95dd55fc59bf0d8a607f6728
Reviewed-on: https://go-review.googlesource.com/22064 Reviewed-by: Rick Hudson <rlh@golang.org>
The Linux kernel provides 16 bytes of random data via the auxv vector
at startup. Currently we consume this separately on 386, amd64, arm,
and arm64. Now that we have a common auxv parser, handle _AT_RANDOM in
the common path.
Currently several different Linux architectures have separate copies
of the auxv parser. Bring these all together into a single copy of the
parser that calls out to a per-arch handler for each tag/value pair.
This is in preparation for handling common auxv tags in one place.
net/http: normalize empty port in URL.Host's ":port"
- Ensures that the empty port and preceeding ":"
in a URL.Host are stripped.
Normalize the empty port in a URL.Host's ":port" as
mandated by RFC 3986 Section 6.2.3 which states that:
`Likewise an explicit ":port", for which the port is empty or
the default for the scheme, is equivalent to one where the port
and its ":" delimiter are elided and thus should be
removed by scheme-based normalization.`
- Moves function `hasPort` from client.go (where it was defined but
not used directly), to http.go the common area.
Morten Siebuhr [Fri, 19 Feb 2016 20:53:17 +0000 (21:53 +0100)]
net: fix looking up port numbers starting with numbers.
LookupPort() correctly parses service names beginning with numerals by
implementing a new parser, mainly taken from strconv/atoi.go.
Also testes some previously undefined behaviours around port numbers
larger than 65535 that previously could lead to some tests fail with
EOPNOTSUPP (Operation Not Supported).
Matthew Dempsky [Fri, 15 Apr 2016 21:22:27 +0000 (14:22 -0700)]
cmd/compile: remove dead flags
For some time now, the -d flag has been used to control various named
debug options, rather than setting Debug['d']. Consequently, that
means dflag() always returns false, which means the -y flag is also
useless.
Similarly, Debug['L'] is never used anywhere, so the -L flag can be
dropped too.
Mikio Hara [Fri, 15 Jan 2016 05:57:41 +0000 (14:57 +0900)]
runtime: don't always unblock all signals on dragonfly, freebsd and openbsd
https://golang.org/cl/10173 intrduced msigsave, ensureSigM and
_SigUnblock but didn't enable the new signal save/restore mechanism for
SIG{HUP,INT,QUIT,ABRT,TERM} on DragonFly BSD, FreeBSD and OpenBSD.
At present, it looks like they have the implementation. This change
enables the new mechanism on DragonFly BSD, FreeBSD and OpenBSD the same
as Darwin, NetBSD.
Change-Id: Ifb4b4743b3b4f50bfcdc7cf1fe1b59c377fa2a41
Reviewed-on: https://go-review.googlesource.com/18657
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Conrad Irwin [Fri, 19 Feb 2016 18:12:44 +0000 (10:12 -0800)]
net/mail: allow utf-8 in ParseAddress
The existing implementation correctly supported RFC 5322, this
change adds support for UTF-8 while parsing as specified by
RFC 6532. The serialization code is unchanged, so emails created
by go remain compatible with very legacy systems.