cmd/compile: no write barrier for stores to reflect.{Slice,String}Header

[mdempsky]

Package unsafe's godocs explicitly state this is safe:

hdr.Data = uintptr(unsafe.Pointer(p))              // case 6 (this case)

But compiling this code does not produce any write barriers:

package p

import (
	"reflect"
	"unsafe"
)

func F(hdr *reflect.SliceHeader, p *byte) {
	hdr.Data = uintptr(unsafe.Pointer(p))
}

func G(hdr *reflect.StringHeader, p *byte) {
	hdr.Data = uintptr(unsafe.Pointer(p))
}

We should probably change needwritebarrier(l) to return true when l is an ODOTPTR for accessing reflect.{Slice,String}Header.Data.

This should probably be backported to 1.8 too?

/cc @aclements @rsc

[mdempsky]

Actually, I think the fix is slightly more involved than that. This program is valid:

package main

import "reflect"

func main() {
    var hdr reflect.SliceHeader
    p := &hdr
    p.Data = 42
}

but writebarrierptr will complain about 42 being in the range (0, minPhysPageSize).

Perhaps add a writebarrieruintptr variant for assigning to runtime.{Slice,String}Header.Data that just omits that check?

Edit: This program is NOT valid. Package unsafe's documentation warns "A program should not declare or allocate variables of these struct types."

[randall77]

I'm not sure we guarantee that SliceHeader actually works any more. Its documentation wording is quite strong:

It cannot be used safely or portably and its representation may change in a later release.

I'm not sure you can ever reliably detect writes to it.

var hdr reflect.SliceHeader
p = &hdr.Data
some_crazy_function_that_ends_up_writing_to_its_arg(p)

[ianlancetaylor]

The unsafe package docs provide specific guarantees for reflect.SliceHeader and reflect.StringHeader that must continue to work. I think @mdempsky is right that this will require special handling in the compiler.

[ianlancetaylor]

That said, I think we can modify the unsafe package docs to reject the case you mention: I think we can forbid modifying the Data field in any way other than x.Data = uintptr(p) where p is some pointer type (meaning that if p is not unsafe.Pointer it must be converted to unsafe.Pointer to support the conversion to uintptr).

[mdempsky]

@ianlancetaylor I'm okay with forbidding assigning to x.Data through a pointer (that's how I currently interpret the docs already), but I don't think we should restrict the RHS. E.g., I think x.Data = uintptr(p) + 1 should be valid.

[cherrymui]

The doc of unsafe package also says (at the end)

A program should not declare or allocate variables of these struct types.

// INVALID: a directly-declared header will not hold Data as a reference.
var hdr reflect.StringHeader
hdr.Data = uintptr(unsafe.Pointer(p))
hdr.Len = n
s := *(*string)(unsafe.Pointer(&hdr)) // p possibly already lost

So I don't think it needs write barrier, which is to hold Data as reference.

[mdempsky]

@cherrymui The distinction there is memory is being allocated for a variable of type reflect.StringHeader, so Data's memory slot doesn't get marked as containing a pointer.

In the valid example, memory is allocated for a variable of type string, and only modified indirectly through a *reflect.StringHeader pointer.

[cherrymui]

@mdempsky Oh, I see the difference. But I still think that hdr.Data = uintptr(unsafe.Pointer(p)) doesn't mean to hold a reference to p.

[randall77]

I think the problem here is the hybrid write barrier - the old value of hdr.Data might need saving, even if you agree that p is not referred to.
@aclements

[mdempsky]

We discussed this internally:

1. Assignments of the precise form p.Data = u where p has type *reflect.SliceHeader or *reflect.StringHeader require a write barrier. We do not need to support q := &p.Data; *q = u.
2. The package unsafe docs already warn "A program should not declare or allocate variables of these struct types." so the p.Data = 42 example I posted above is invalid anyway.

[cespare]

1.8.1 material? Has the write barrier always been missing, or is this new to 1.8?

[ianlancetaylor]

I could be wrong, but I think that is what is new to 1.8 is that missing the write barrier could conceivably actually matter in practice. Before the hybrid write barrier, which is new in 1.8, it's pretty hard to imagine a real program that would fail. With the hybrid write barrier, it's much easier to imagine that omitting the write barrier could leave a dangling reference on the stack.

[gopherbot]

CL https://golang.org/cl/37663 mentions this issue.