cmd/compile: open code unsafe.Slice

[josharian]

golang.org/cl/352953 used unsafe.Slice in the runtime. I am about to revert that change b/c it causes a 4% performance regression in a stack copying benchmark. At least half of that is due to function call overhead. We might want to open code unsafe.Slice instead of making it a runtime call.

cc @mdempsky

[gopherbot]

Change https://golang.org/cl/354090 mentions this issue: Revert "runtime: use unsafe.Slice in getStackMap"

[ianlancetaylor]

Looking at the current implementation of unsafe.Slice, I see that it gives an error if the overall size of the slice is > maxAlloc, but I don't know why. One can imagine using unsafe.Slice on a huge chunk of memory that is larger than maxAlloc, and doesn't seem any less safe than unsafe.Slice itself.

[mdempsky]

I think my rationale was to ensure the slice didn't wrap around the address space, and I just copied that from growslice. But reflecting on it now, it doesn't actually achieve that. Perhaps there's no reason to cap the addressed memory range at maxAlloc.

Probably a better check would be mem > -uintptr(ptr) to prevent wrap around.

[zx2c4]

I think my rationale was to ensure the slice didn't wrap around the address space, and I just copied that from growslice. But reflecting on it now, it doesn't actually achieve that. Perhaps there's no reason to cap the addressed memory range at maxAlloc.

Probably a better check would be mem > -uintptr(ptr) to prevent wrap around.

It's already "unsafe". Can we just omit all checks and have the compiler emit ideal code that assumes its usage is correct, just like unsafe.Pointer casts? Then we can put all sorts of safety checks behind checkptr, again like unsafe.Pointer casts.

[gopherbot]

Change https://golang.org/cl/355252 mentions this issue: cmd/compile: speed up unsafe.Slice by omitting checks

[mdempsky]

Can we just omit all checks and have the compiler emit ideal code that assumes its usage is correct, just like unsafe.Pointer casts?

In cases where we can statically determine that to be safe, I'm happy for the compiler to elide the bounds checks. I'm also happy to open code the checks so the function call overhead is reduced.

However, I'm skeptical that most Go code that would want to use unsafe.Slice is unable to afford the bounds checks. E.g., any subsequent indexing/slicing operations will still have bounds checks and the code can evidently afford those, otherwise it would directly compute indices using unchecked unsafe.Pointer arithmetic.

Package unsafe is used by an unfortunately large percentage of Go programs, and many Go programmers (including expert Go programmers) do not carefully read the fine print on how to use unsafe.Pointer correctly. unsafe.Slice exists to help those users write correct code, not maximally performant code. Use cases that really can't afford the extra overhead can continue to use unsafe.Pointer and reflect.SliceHeader; those aren't going away.

[josharian]

I think that we should start by open coding the checks. It's not much code, the function call overhead is much larger than the bounds checks overhead, and if they are open coded then the compiler will have a chance to optimize them away. Then we can re-assess whether there's still a performance concern and resume discussion if necessary.

[gopherbot]

Change https://golang.org/cl/355490 mentions this issue: unsafe: optimize Slice bounds checking

[gopherbot]

Change https://golang.org/cl/355489 mentions this issue: unsafe: allow unsafe.Slice up to end of address space

[mdempsky]

CL 355490 streamlines unsafe.Slice's bounds checks somewhat, so hopefully it's easier to open code. It would also be interesting to know if it has any measurable impact to unsafe.Slice's overhead when used for stack copying.