- 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
