Currently race detector runtime maps shadow memory eagerly at process startup.
It works poorly on Windows, because Windows requires reservation in swap file
(especially problematic if several Go program runs at the same, each consuming GBs
of memory).
With this change race detector maps shadow memory lazily, so Go runtime must notify
about all new heap memory.
It will help with Windows port, but also eliminates scary 16TB virtual mememory
consumption in top output (which sometimes confuses some monitoring scripts).
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6811085
Thank you zhoumichaely for original CL 5175042.
Fixes#1740.
Fixes#2315.
R=golang-dev, bradfitz, mikioh.mikioh
CC=golang-dev, zhoumichaely
https://golang.org/cl/6822045
When the first result of a type assertion is blank, the compiler would still copy out a potentially large non-interface type.
Fixes#1021.
R=golang-dev, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/6812079
It speedups the race detector somewhat, but also prevents
getcallerpc() from obtaining lessstack().
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/6812091
The deadlock occurs when another goroutine requests GC
during the test. When wait=true the test expects physical parallelism,
that is, that P goroutines are all active at the same time.
If GC is requested, then part of the goroutines are not scheduled,
so other goroutines deadlock.
With wait=false, goroutines finish parallel for w/o waiting for all
other goroutines.
Fixes#3954.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6820098
The race detector does not understand ParFor synchronization, because it's implemented in C.
If run with -cpu=2 currently race detector says:
WARNING: DATA RACE
Read by goroutine 5:
runtime_test.TestParForParallel()
src/pkg/runtime/parfor_test.go:118 +0x2e0
testing.tRunner()
src/pkg/testing/testing.go:301 +0x8f
Previous write by goroutine 6:
runtime_test.func·024()
src/pkg/runtime/parfor_test.go:111 +0x52
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6811082
It also increases timeout deltas to allow for longer wait.
Also disables this test on plan9.
R=golang-dev, minux.ma
CC=golang-dev
https://golang.org/cl/6821062
It was well-defined but easy to miss that the return value for
"not found" is len(input) not -1 as many expect.
Fixes#4205.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/6820080
The only code change is in exp/gotype/gotype.go.
The latest reviewed version of exp/types is now
exp/types/staging.
First step toward replacing exp/types with
exp/types/staging.
R=iant
CC=golang-dev
https://golang.org/cl/6819071
- simplified assignment checking by removing duplicate code
- implemented field lookup (methods, structs, embedded fields)
- importing methods (not just parsing them)
- type-checking functions and methods
- typechecking more statements (inc/dec, select, return)
- tracing support for easier debugging
- handling nil more correctly (comparisons)
- initial support for [...]T{} arrays
- initial support for method expressions
- lots of bug fixes
All packages under pkg/go as well as pkg/exp/types typecheck
now with pkg/exp/gotype applied to them; i.e., a significant
amount of typechecking works now (several statements are not
implemented yet, but handling statements is almost trivial in
comparison with typechecking expressions).
R=rsc
CC=golang-dev
https://golang.org/cl/6768063
Incorrect cast was causing panics when
calling String() on dnsMsg with dnsRR_A
answers.
R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/6818043
defined by the PLTE chunk. Such pixels decode to opaque black,
which matches what libpng does.
Fixes#4319.
On my reading, the PNG spec isn't clear whether palette index values
outside of those defined by the PLTE chunk is an error, and if not,
what to do.
Libpng 1.5.3 falls back to opaque black. png_set_PLTE says:
/* Changed in libpng-1.2.1 to allocate PNG_MAX_PALETTE_LENGTH instead
* of num_palette entries, in case of an invalid PNG file that has
* too-large sample values.
*/
png_ptr->palette = (png_colorp)png_calloc(png_ptr,
PNG_MAX_PALETTE_LENGTH * png_sizeof(png_color));
ImageMagick 6.5.7 returns an error:
$ convert -version
Version: ImageMagick 6.5.7-8 2012-08-17 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2009 ImageMagick Studio LLC
Features: OpenMP
$ convert packetloss.png x.bmp
convert: Invalid colormap index `packetloss.png' @ image.c/SyncImage/3849.
R=r
CC=golang-dev
https://golang.org/cl/6822065
Tailorings are represented by removing and reinserting entries from a linked list.
After all tailorings are done, missing weights are computed and verified.
This implementation assumes that entries that are used in expansions are not
reinserted at a later point. This considerably simplifies the implementation.
R=r
CC=golang-dev
https://golang.org/cl/6739052
incremental comparisons. Instead, processing is now done directly on colElems.
As a result, the size of the weights array is now reduced by 75%.
Details:
- Primary value of type 1 colElem is shifted by 1 bit so that primaries
of all types can be compared without shifting.
- Quaternary values are now stored in the colElem itself. This is possible
as quaternary values other than 0 or maxQuaternary are only needed when other
values are ignored.
- Simplified processWeights by removing cases that are needed for ICU but not
for us (our CJK primary values fit in a single value).
R=r
CC=golang-dev
https://golang.org/cl/6817054
It is common to close network connection while another goroutine is
blocked reading on another goroutine. This sequence corresponds to
windows calls to WSARecv to start io, followed by GetQueuedCompletionStatus
that blocks until io completes, and, finally, closesocket called from
another thread. We were expecting that closesocket would unblock
GetQueuedCompletionStatus, and it does, but not always
(http://code.google.com/p/go/issues/detail?id=4170#c5). Also that sequence
results in connection is being reset.
This CL inserts CancelIo between GetQueuedCompletionStatus and closesocket,
and waits for both WSARecv and GetQueuedCompletionStatus to complete before
proceeding to closesocket. This seems to fix both connection resets and
issue 4170. It also makes windows code behave similar to unix version.
Unfortunately, CancelIo needs to be called on the same thread as WSARecv.
So we have to employ strategy we use for connections with deadlines to
every connection now. It means, there are 2 unavoidable thread switches
for every io. Some newer versions of windows have new CancelIoEx api that
doesn't have these drawbacks, and this CL uses this capability when available.
As time goes by, we should have less of CancelIo and more of CancelIoEx
systems. Computers with CancelIoEx are also not affected by issue 4195 anymore.
Fixes#3710Fixes#3746Fixes#4170
Partial fix for issue 4195
R=golang-dev, mikioh.mikioh, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/6604072
On 6g/linux:
benchmark old ns/op new ns/op delta
BenchmarkFDCT 4606 4241 -7.92%
BenchmarkIDCT 4187 3923 -6.31%
BenchmarkDecodeBaseline 3154864 3170224 +0.49%
BenchmarkDecodeProgressive 4072812 4017132 -1.37%
BenchmarkEncode 39406920 34596760 -12.21%
Stack requirements before (from 'go tool 6g -S'):
(scan.go:37) TEXT (*decoder).processSOS+0(SB),$1352-32
(writer.go:448) TEXT (*encoder).writeSOS+0(SB),$5344-24
after:
(scan.go:37) TEXT (*decoder).processSOS+0(SB),$1064-32
(writer.go:448) TEXT (*encoder).writeSOS+0(SB),$2520-24
Also, in encoder.writeSOS, re-use the yBlock scratch buffer for Cb and
Cr. This reduces the stack requirement slightly, but also avoids an
unlucky coincidence where a BenchmarkEncode stack split lands between
encoder.writeByte and bufio.Writer.WriteByte, which occurs very often
during Huffman encoding and is otherwise disasterous for the final
benchmark number. FWIW, the yBlock re-use *without* the s/int/int32/
change does not have a noticable effect on the benchmarks.
R=r
CC=golang-dev, rsc
https://golang.org/cl/6823043
