Skip to content

runtime: "valid" use of reflect.SliceHeader confuses garbage collector #8004

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
rsc opened this issue May 15, 2014 · 4 comments
Closed

runtime: "valid" use of reflect.SliceHeader confuses garbage collector #8004

rsc opened this issue May 15, 2014 · 4 comments
Labels
FrozenDueToAge
Milestone
Go1.3

Comments

@rsc
Copy link
Contributor

rsc commented May 15, 2014 

Broken even in Go 1.2 but legal according to what we've typically said about the use of
SliceHeader. It's not clear what to do. The simplest thing might be to make any GC
program treat *SliceHeader the same as unsafe.Pointer, so that the collection uses the
heap type information to follow the pointer.

http://play.golang.org/p/FusOBSDXlo

package main

import (
    "reflect"
    "runtime"
    "unsafe"
)

func main() {
    var all []interface{}
    for i := 0; i < 100; i++ {
        p := new([]int)
        *p = append(*p, 1, 2, 3, 4)
        h := (*reflect.SliceHeader)(unsafe.Pointer(p))
        all = append(all, h, p)
    }
    runtime.GC()
    for i := 0; i < 100; i++ {
        p := *all[2*i+1].(*[]int)
        if p[0] != 1 || p[1] != 2 || p[2] != 3 || p[3] != 4 {
            println("bad slice1 at index", i, p[0], p[1], p[2], p[3])
        }
    }
}
@gopherbot
Copy link
Contributor

Comment 2:

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

@randall77
Copy link
Contributor

Comment 3:

We should have a list of types in the runtime that we know are "bogus".  We should not
propagate them when doing GC.
reflect.SliceHeader
reflect.StringHeader
there are probably a few others.

@rsc
Copy link
Contributor Author

rsc commented May 15, 2014

Comment 4:

Ever since the precise heap went in, it treats all *T where T itself has no pointers as
being like unsafe.Pointer. That handles the variant of this case called test2 in CL
100470045's test program.
The handling of interfaces did not have the same conservative behavior; in CL 100470045
it will match what we already did for concrete pointers.
To be clear, the 'conservative' here is not interpreting integers as pointers. It is
merely saying to the garbage collector 'I don't trust my static type information, look
in your allocation records please'.
I'm happy to explore what happens if we use the static type information for pointer
traversal in 1.4. Of course, if we move to pointer bitmaps for the whole heap as the
primary metadata used during collection, there would be no static type information to
worry about and this would all be moot.

@rsc
Copy link
Contributor Author

rsc commented May 15, 2014

Comment 5:

This issue was closed by revision 68aaf2c.

Status changed to Fixed.

@rsc rsc added fixed labels May 15, 2014
@rsc rsc added this to the Go1.3 milestone Apr 14, 2015
@rsc rsc removed the release-go1.3 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.3
Development

No branches or pull requests
3 participants
@rsc @randall77 @gopherbot