On my laptop, I had an 800x600 jpeg and an 800x600 png (with
transparency). I timed how long it took to draw each image onto an
equivalently sized, zeroed RGBA image.
Previously, the jpeg took 75ms and the png took 70ms, going through
the medium-fast path, i.e. func drawRGBA in draw.go.
After this CL, the jpeg took 14ms, and the png took 21ms with the
Over operator and 12ms with the Src operator.
It's only a rough estimate basd on one image file, but it should
give an idea of the order of magnitude of improvement.
R=rsc, r
CC=adg, golang-dev
https://golang.org/cl/4468044
- added a cache for last file looked up: avoids binary
search if the file matches
- don't look up extra line info if not present
(it is almost never present)
- inline one critical binary search call (inlining
provides almost 30% improvement in this case)
Together, these changes make the go/printer benchmark
more than twice as fast (53% improvement). gofmt also
sped up by about the same amount.
Also: removed an unused internal field from FileSet.
Measurements (always best of 5 runs):
* original:
printer.BenchmarkPrint 5 238354200 ns/op (100%)
* using last file cache:
printer.BenchmarkPrint 10 201796600 ns/op (85%)
* avoiding lookup of extra line info:
printer.BenchmarkPrint 10 157072700 ns/op (66%)
* inlining a critical binary search call:
printer.BenchmarkPrint 10 111523500 ns/op (47%)
gofmt (always best of 3 runs):
* before:
time gofmt -l src misc
real 0m33.316s
user 0m31.298s
sys 0m0.319s
* after:
time gofmt -l src misc
real 0m15.889s
user 0m14.596s
sys 0m0.224s
R=r, dfc, bradfitz, rsc1
CC=golang-dev
https://golang.org/cl/4433086
Works around bug in kernel implementation on old ARM5 kernels.
Bug was fixed on 26 Nov 2007 (between 2.6.23 and 2.6.24) but
old kernels persist.
Fixes#1750.
R=dfc, golang-dev
CC=golang-dev
https://golang.org/cl/4436072
Avoids image.At(), color.RGBA(), opposing 8 bit shifts,
and min function calls in a loop. Not as pretty as before,
but the pure version is still there to revert back to
later if/when the compiler gets better.
before (best of 5)
jpeg.BenchmarkEncodeRGBOpaque 50 64781360 ns/op 18.97 MB/s
after (best of 5)
jpeg.BenchmarkEncodeRGBOpaque 50 42044300 ns/op 29.23 MB/s
(benchmarked on an HP z600; 16 core Xeon E5520 @ 2.27Ghz)
R=r, r2, nigeltao
CC=golang-dev
https://golang.org/cl/4433088
The g->sched.sp saved stack pointer and the
g->stackbase and g->stackguard stack bounds
can change even while "the world is stopped",
because a goroutine has to call functions (and
therefore might split its stack) when exiting a
system call to check whether the world is stopped
(and if so, wait until the world continues).
That means the garbage collector cannot access
those values safely (without a race) for goroutines
executing system calls. Instead, save a consistent
triple in g->gcsp, g->gcstack, g->gcguard during
entersyscall and have the garbage collector refer
to those.
The old code was occasionally seeing (because of
the race) an sp and stk that did not correspond to
each other, so that stk - sp was not the number of
stack bytes following sp. In that case, if sp < stk
then the call scanblock(sp, stk - sp) scanned too
many bytes (anything between the two pointers,
which pointed into different allocation blocks).
If sp > stk then stk - sp wrapped around.
On 32-bit, stk - sp is a uintptr (uint32) converted
to int64 in the call to scanblock, so a large (~4G)
but positive number. Scanblock would try to scan
that many bytes and eventually fault accessing
unmapped memory. On 64-bit, stk - sp is a uintptr (uint64)
promoted to int64 in the call to scanblock, so a negative
number. Scanblock would not scan anything, possibly
causing in-use blocks to be freed.
In short, 32-bit platforms would have seen either
ineffective garbage collection or crashes during garbage
collection, while 64-bit platforms would have seen
either ineffective or incorrect garbage collection.
You can see the invalid arguments to scanblock in the
stack traces in issue 1620.
Fixes#1620.
Fixes#1746.
R=iant, r
CC=golang-dev
https://golang.org/cl/4437075
runtime: memory allocated by OS not in usable range
runtime: out of memory: cannot allocate 1114112-byte block (2138832896 in use)
throw: out of memory
runtime.throw+0x40 /Users/rsc/g/go/src/pkg/runtime/runtime.c:102
runtime.throw(0x1fffd, 0x101)
runtime.mallocgc+0x2af /Users/rsc/g/go/src/pkg/runtime/malloc.c:60
runtime.mallocgc(0x100004, 0x0, 0x1, 0x1, 0xc093, ...)
runtime.mal+0x40 /Users/rsc/g/go/src/pkg/runtime/malloc.c:289
runtime.mal(0x100004, 0x20bc4)
runtime.new+0x26 /Users/rsc/g/go/src/pkg/runtime/malloc.c:296
runtime.new(0x100004, 0x8fe84000, 0x20bc4)
main.main+0x29 /Users/rsc/x.go:11
main.main()
runtime.mainstart+0xf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:93
runtime.mainstart()
runtime.goexit /Users/rsc/g/go/src/pkg/runtime/proc.c:178
runtime.goexit()
----- goroutine created by -----
_rt0_386+0xbf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:80
R=iant, r
CC=golang-dev
https://golang.org/cl/4444073
Add local URI path support, which isn't as fringe
as I originally thought. (it's supported by Apache)
Send an implicit 302 status on redirects (not 200).
Fixes#1597
R=rsc, r
CC=golang-dev
https://golang.org/cl/4442089
In a GOROOT path a backslash is a path separator
not an escape character. For example, `C:\go`.
Fixes gotest error:
version.go:3: unknown escape sequence: g
R=rsc
CC=golang-dev
https://golang.org/cl/4437076
I ran the new verification code against a large number of certificates
with a huge (>1000) number of intermediates.
I had previously convinced myself that a cycle in the certificate
graph implied a cycle in the hash graph (and thus, a contradiction).
This is bogus because the signatures don't cover each other.
Secondly, I managed to drive the verification into a time explosion
with a fully connected graph of certificates. The code would try to
walk the factorial number of paths.
This change switches the CertPool to dealing with indexes of
certificates rather than pointers: this makes equality easy. (I didn't
want to compare pointers because a reasonable gc could move objects
around over time.)
Secondly, verification now memorizes the chains from a given
certificate. This is dynamic programming for the lazy, but there's a
solid reason behind it: dynamic programming would ignore the Issuer
hints that we can exploit by walking up the chain rather than down.
R=bradfitzgo
CC=golang-dev
https://golang.org/cl/4439070
Used to fault trying to access l->list->next
when l->list == nil after MCentral_AllocList.
Now prints
runtime: out of memory: no room in arena for 65536-byte allocation (536870912 in use)
throw: out of memory
followed by stack trace.
Fixes#1650.
R=r, dfc
CC=golang-dev
https://golang.org/cl/4446062
This permits the websocket handler to inspect http headers and such.
Fixes#1726.
R=ukai, bradfitz, bradfitzgo
CC=golang-dev
https://golang.org/cl/4439069
The unexported version returns a sensible default when the user hasn't
set a value. The exported version crashes in that case.
R=bradfitzgo, rsc1
CC=golang-dev
https://golang.org/cl/4435070
Having the test be in the container/heap package yields a cycle
container/heap (for the test)
-> testing
-> time
-> container/heap (for timerHeap)
Occasionally the linker would get mixed up, resulting in a test panic
in a very weird place.
R=rsc, r2
CC=golang-dev
https://golang.org/cl/4395042
With full multi-prime support we can support version 1 PKCS#1 private
keys. This means exporting all the members of rsa.PrivateKey, thus
making the API a little messy. However there has already been another
request to export this so it seems to be something that's needed.
Over time, rsa.GenerateMultiPrimeKey will replace rsa.GenerateKey, but
I need to work on the prime balance first because we're no longer
generating primes which are a multiples of 8 bits.
Fixes#987.
R=rsc
CC=golang-dev
https://golang.org/cl/4378046
Only for Unix presently. Other operating systems
are stubbed out, as well as arm (lacks cgo).
R=rsc, r, bradfitzwork
CC=golang-dev
https://golang.org/cl/4440057
Adds an optional hook to Parser to let charset
converters step in when a processing directive
with a non-UTF-8 encoding is specified.
(Open to alternative proposals too...)
R=rsc
CC=golang-dev
https://golang.org/cl/4437061
note: due to issue 1466 the Msghdr and BpfProgram
struct for src/pkg/syscall/ztypes_darwin_386.go,
src/pkg/syscall/ztypes_darwin_amd64.go had to be
edited after the godefs generation.
R=rsc
CC=golang-dev
https://golang.org/cl/4403042
Avoid getting out of synch when a function, such as main.init,
has no associated line number information. Without this the
function before main.init can skip the PC all the way to the
next function, which will cause the next function's line table
to be associated with main.init, and leave subsequent
functions with the wrong line numbers.
R=rsc
CC=golang-dev
https://golang.org/cl/4426055
On Mac X 10.6 /etc/resolv.conf is changed dynamically,
and may not exist at all when all network connections
are turned off, thus any lookup, even for "localhost"
would fail with "error reading DNS config: open
/etc/resolv.conf: no such file or directory". This
change avoids the error by trying to lookup addresses
in /etc/hosts before loading DNS config.
R=golang-dev, rsc1, rsc
CC=golang-dev
https://golang.org/cl/4431054
The SW_HIDE parameter looks like the only way for a windows GUI application to execute a CLI subcommand without having a shell windows appearing.
R=brainman, golang-dev, bradfitzgo, rsc1
CC=golang-dev
https://golang.org/cl/4439055
go/types: update for export data format change
reflect: require package qualifiers to match during interface check
runtime: require package qualifiers to match during interface check
test: fixed bug324, adapt to be silent
Fixes#1550.
Issue 1536 remains open.
R=gri, ken2, r
CC=golang-dev
https://golang.org/cl/4442071
This CL makes reflect require that values be assignable to the target type
in exactly the same places where that is the rule in Go. It also adds
the Implements and AssignableTo methods so that callers can check
the types themselves so as to avoid a panic.
Before this CL, reflect required strict type identity.
This CL expands Call to accept and correctly marshal arbitrary
argument lists for variadic functions; it introduces CallSlice for use
in the case where the slice for the variadic argument is already known.
Fixes#327.
Fixes#1212.
R=r, dsymonds
CC=golang-dev
https://golang.org/cl/4439058
This CL makes it possible to resolve DNS names on OS X
without offending the Application-Level Firewall.
It also means that cross-compiling from one operating
system to another is no longer possible when using
package net, because cgo needs to be able to sniff around
the local C libraries. We could special-case this one use
and check in generated files, but it seems more trouble
than it's worth. Cross compiling is dead anyway.
It is still possible to use either GOARCH=amd64 or GOARCH=386
on typical Linux and OS X x86 systems.
It is also still possible to build GOOS=linux GOARCH=arm on
any system, because arm is for now excluded from this change
(there is no cgo for arm yet).
R=iant, r, mikioh
CC=golang-dev
https://golang.org/cl/4437053
* Accept armored private key blocks
* If an armored block is missing, return an InvalidArgumentError,
rather than ignoring it.
* If every key in a block is skipped due to being unsupported,
return the last unsupported error.
* Include the numeric type of unsupported public keys.
* Don't assume that the self-signature comes immediately after the
user id packet.
R=bradfitzgo
CC=golang-dev
https://golang.org/cl/4434048
This pulls in changes that should have been in 3faf9d0c10c0, but
weren't because x509.go was part of another changelist.
TBR=bradfitzgo
R=bradfitzgo
CC=golang-dev
https://golang.org/cl/4433056
People have a need to verify certificates in situations other than TLS
client handshaking. Thus this CL moves certificate verification into
x509 and expands its abilities.
R=bradfitzgo
CC=golang-dev
https://golang.org/cl/4407046
* Reduces malloc counts during gob encoder/decoder test from 6/6 to 3/5.
The current reflect uses Set to mean two subtly different things.
(1) If you have a reflect.Value v, it might just represent
itself (as in v = reflect.NewValue(42)), in which case calling
v.Set only changed v, not any other data in the program.
(2) If you have a reflect Value v derived from a pointer
or a slice (as in x := []int{42}; v = reflect.NewValue(x).Index(0)),
v represents the value held there. Changing x[0] affects the
value returned by v.Int(), and calling v.Set affects x[0].
This was not really by design; it just happened that way.
The motivation for the new reflect implementation was
to remove mallocs. The use case (1) has an implicit malloc
inside it. If you can do:
v := reflect.NewValue(0)
v.Set(42)
i := v.Int() // i = 42
then that implies that v is referring to some underlying
chunk of memory in order to remember the 42; that is,
NewValue must have allocated some memory.
Almost all the time you are using reflect the goal is to
inspect or to change other data, not to manipulate data
stored solely inside a reflect.Value.
This CL removes use case (1), so that an assignable
reflect.Value must always refer to some other piece of data
in the program. Put another way, removing this case would
make
v := reflect.NewValue(0)
v.Set(42)
as illegal as
0 = 42.
It would also make this illegal:
x := 0
v := reflect.NewValue(x)
v.Set(42)
for the same reason. (Note that right now, v.Set(42) "succeeds"
but does not change the value of x.)
If you really wanted to make v refer to x, you'd start with &x
and dereference it:
x := 0
v := reflect.NewValue(&x).Elem() // v = *&x
v.Set(42)
It's pretty rare, except in tests, to want to use NewValue and then
call Set to change the Value itself instead of some other piece of
data in the program. I haven't seen it happen once yet while
making the tree build with this change.
For the same reasons, reflect.Zero (formerly reflect.MakeZero)
would also return an unassignable, unaddressable value.
This invalidates the (awkward) idiom:
pv := ... some Ptr Value we have ...
v := reflect.Zero(pv.Type().Elem())
pv.PointTo(v)
which, when the API changed, turned into:
pv := ... some Ptr Value we have ...
v := reflect.Zero(pv.Type().Elem())
pv.Set(v.Addr())
In both, it is far from clear what the code is trying to do. Now that
it is possible, this CL adds reflect.New(Type) Value that does the
obvious thing (same as Go's new), so this code would be replaced by:
pv := ... some Ptr Value we have ...
pv.Set(reflect.New(pv.Type().Elem()))
The changes just described can be confusing to think about,
but I believe it is because the old API was confusing - it was
conflating two different kinds of Values - and that the new API
by itself is pretty simple: you can only Set (or call Addr on)
a Value if it actually addresses some real piece of data; that is,
only if it is the result of dereferencing a Ptr or indexing a Slice.
If you really want the old behavior, you'd get it by translating:
v := reflect.NewValue(x)
into
v := reflect.New(reflect.Typeof(x)).Elem()
v.Set(reflect.NewValue(x))
Gofix will not be able to help with this, because whether
and how to change the code depends on whether the original
code meant use (1) or use (2), so the developer has to read
and think about the code.
You can see the effect on packages in the tree in
https://golang.org/cl/4423043/.
R=r
CC=golang-dev
https://golang.org/cl/4435042
NewRequest will save a lot of boilerplate code.
This also updates some docs on Request.Write and
adds some tests.
R=rsc, petar-m, r
CC=golang-dev
https://golang.org/cl/4406047
Ubuntu and/or GNOME have some bug that likes
to set the "http_proxy" environment variable
and forgets to unset it. This is annoying
to debug. Be clear in the error message that
a proxy was in use.
R=rsc
CC=golang-dev
https://golang.org/cl/4409045
. Missing declaration of runtime.brk_();
. Argument v in runtime.SysReserve() is not used;
(I'd prefer a Plan 9-type solution...)
R=golang-dev, r, r2
CC=golang-dev
https://golang.org/cl/4368076
We already had support on the client side. I also changed the name of
the flag in the ServerHello structure to match the name of the same
flag in the ClientHello (ocspStapling).
R=bradfitzgo
CC=golang-dev
https://golang.org/cl/4408044
This fixes our http behavior (even if Handlers forget to
consume a request body, we do it for them before we send
their response header), fixes the racy TestServerExpect,
and adds TestServerConsumesRequestBody.
With GOMAXPROCS>1, the http tests now seem race-free.
R=rsc
CC=golang-dev
https://golang.org/cl/4419042
The list elements are already being allocated out of a
single memory buffer. We can drop the Link* pointer
following and the memory it requires, replacing it with
index operations.
The change also keeps a channel from containing a pointer
back into its own allocation block, which would create a
cycle. Blocks involved in cycles are not guaranteed to be
finalized properly, and channels depend on finalizers to
free OS-level locks on some systems. The self-reference
was keeping channels from being garbage collected.
runtime-gdb.py will need to be updated in order to dump
the content of buffered channels with the new data structure.
Fixes#1676.
R=ken2, r
CC=golang-dev
https://golang.org/cl/4411045
