FAQ
I was looking at the reflect.Value source yesterday and noticed two
TODOs to deprecate methods to get backing value addresses.

http://golang.org/src/reflect/value.go?s=36337:36355#L1185
http://golang.org/src/reflect/value.go?s=49967:49985#L1676

There is no comment about this in the commit or discussion in the code
review.

What are the plans here?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Nigel Tao at Mar 25, 2015 at 12:40 am

    On Wed, Mar 25, 2015 at 10:01 AM, Dan Kortschak wrote:
    What are the plans here?
    I'd ask rsc (CC'ed), although he's currently away.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Mar 25, 2015 at 12:53 am

    On Wed, 2015-03-25 at 11:40 +1100, Nigel Tao wrote:
    On Wed, Mar 25, 2015 at 10:01 AM, Dan Kortschak
    wrote:
    What are the plans here?
    I'd ask rsc (CC'ed), although he's currently away.
    Thanks Nigel, I'll wait till he gets back. The CL though was sent by
    khr:

    https://github.com/golang/go/commit/cbc565a80156a4dd4108ef5e1e170602415418a8

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nigel Tao at Mar 25, 2015 at 1:10 am

    On Wed, Mar 25, 2015 at 11:53 AM, Dan Kortschak wrote:
    The CL though was sent by khr
    Well, I'd ask khr (CC'ed) then. :-)

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Mar 25, 2015 at 1:33 am

    On Wed, 2015-03-25 at 12:10 +1100, Nigel Tao wrote:
    On Wed, Mar 25, 2015 at 11:53 AM, Dan Kortschak
    wrote:
    The CL though was sent by khr
    Well, I'd ask khr (CC'ed) then. :-)
    Very cunning. You've done this kind of thing before haven't you?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Brad Fitzpatrick at Mar 25, 2015 at 1:59 am
    [+khr]

    The GC doesn't follow uintptr. Only real pointers or unsafe.Pointer, so
    this interface is no longer safe to use as of the upcoming Go 1.5.

    I think "deprecate" in that comment means update the documentation to warn
    people heavily to only use this if it's immediately wrapped in an
    "unsafe.Pointer(v.Pointer())" expression.


    On Tue, Mar 24, 2015 at 4:01 PM, Dan Kortschak wrote:

    I was looking at the reflect.Value source yesterday and noticed two
    TODOs to deprecate methods to get backing value addresses.

    http://golang.org/src/reflect/value.go?s=36337:36355#L1185
    http://golang.org/src/reflect/value.go?s=49967:49985#L1676

    There is no comment about this in the commit or discussion in the code
    review.

    What are the plans here?

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Mar 25, 2015 at 2:08 am

    On Tue, 2015-03-24 at 18:59 -0700, Brad Fitzpatrick wrote:
    The GC doesn't follow uintptr. Only real pointers or unsafe.Pointer,
    so this interface is no longer safe to use as of the upcoming Go 1.5.

    I think "deprecate" in that comment means update the documentation to
    warn people heavily to only use this if it's immediately wrapped in an
    "unsafe.Pointer(v.Pointer())" expression.
    Yeah that makes sense, I also was wondering about the possible impact of
    moving GC on these returns.

    The reason I was looking at it was for my fork of go-spew which I plan
    to have a little more detailed pointer analysis on the data structures.
    The issue above (moving GC) is something that I was wondering about and
    it's sort of related:

    During part of the analysis I walk the structure retaining information
    about nodes that are referenced so I can output their address. When
    moving GC is implemented, this would leave me in a possible state where
    addresses output at the beginning of a dump don't agree with addresses
    to the same values at the end of a dump - this is something that will be
    more generally an issue for debugging I expect too.

    The approach that I think will work to deal with this is to keep a
    map[unsafe.Pointer]uintptr which maps the actual address to the uintptr
    converted address for the first time the pointer was seen, freezing it.
    This map is then used during the pointer output. Does this seem
    reasonable?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Brad Fitzpatrick at Mar 25, 2015 at 2:12 am
    We're a number of releases away from a moving collector and probably lots
    of stuff will break if/when that happens, so I wouldn't worry about it just
    yet.

    On Tue, Mar 24, 2015 at 7:08 PM, Dan Kortschak wrote:
    On Tue, 2015-03-24 at 18:59 -0700, Brad Fitzpatrick wrote:
    The GC doesn't follow uintptr. Only real pointers or unsafe.Pointer,
    so this interface is no longer safe to use as of the upcoming Go 1.5.

    I think "deprecate" in that comment means update the documentation to
    warn people heavily to only use this if it's immediately wrapped in an
    "unsafe.Pointer(v.Pointer())" expression.
    Yeah that makes sense, I also was wondering about the possible impact of
    moving GC on these returns.

    The reason I was looking at it was for my fork of go-spew which I plan
    to have a little more detailed pointer analysis on the data structures.
    The issue above (moving GC) is something that I was wondering about and
    it's sort of related:

    During part of the analysis I walk the structure retaining information
    about nodes that are referenced so I can output their address. When
    moving GC is implemented, this would leave me in a possible state where
    addresses output at the beginning of a dump don't agree with addresses
    to the same values at the end of a dump - this is something that will be
    more generally an issue for debugging I expect too.

    The approach that I think will work to deal with this is to keep a
    map[unsafe.Pointer]uintptr which maps the actual address to the uintptr
    converted address for the first time the pointer was seen, freezing it.
    This map is then used during the pointer output. Does this seem
    reasonable?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Mar 25, 2015 at 2:15 am

    On Tue, 2015-03-24 at 19:12 -0700, Brad Fitzpatrick wrote:
    We're a number of releases away from a moving collector and probably
    lots of stuff will break if/when that happens, so I wouldn't worry
    about it just yet.
    Yeah, not worried. Just thinking.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Mar 25, 2015 at 5:59 am

    On Tue, Mar 24, 2015 at 7:01 PM, Dan Kortschak wrote:

    I was looking at the reflect.Value source yesterday and noticed two
    TODOs to deprecate methods to get backing value addresses.

    http://golang.org/src/reflect/value.go?s=36337:36355#L1185
    http://golang.org/src/reflect/value.go?s=49967:49985#L1676

    There is no comment about this in the commit or discussion in the code
    review.

    What are the plans here?

    I don't think we can remove the API due to the Go 1 API stability contract
    unless we invoke the clause about fixing bugs, however, ever since Go 1
    is released, I don't remember many times that we used this clause to justify
    an incompatible change. (See http://tip.golang.org/api/except.txt for the
    current list, it could have been much larger. Most of the syscall exceptions
    are due to the introduction of new OS ports, and they're not actually
    changed.)

    The reason they don't return unsafe.Pointer is that we want to make sure
    that to get a unsafe.Pointer, you must import "unsafe" package yourself,
    and as unsafe.Pointer can be cast to any other pointer types, it's deemed
    too "powerful" to be returned from a reflect API (basically if they return
    unsafe.Pointer, any program can use reflect to violate memory safety without
    importing the unsafe package.)

    I remembered that Russ once said that
    unsafe.Pointer(reflect.Value.UnsafeAddr())
    is among the forms that we should continue to support, but unfortunately,
    I can't find a URL to prove that, so you'd better wait for him.

    PS: the only concrete proof is the govet rules about unsafe.Pointer:
    https://github.com/golang/tools/blob/master/cmd/vet/unsafeptr.go

    It currently has the following comment:
    // (if x already known to be uintptr)
    // It is safe (to convert x to unsafe.Pointer) if x is itself derived
    // directly from an unsafe.Pointer via conversion and pointer arithmetic
    // or if x is the result of reflect.Value.Pointer or
    reflect.Value.UnsafeAddr
    // or obtained from the Data field of a *reflect.SliceHeader or
    *reflect.StringHeader.
    // (the last two is allowed only when SliceHeader and StringHeader are
    themselves
    // derived from real slice and string.)

    You can also see the desire to keep these forms working from the rejection
    of this CL (https://codereview.appspot.com/153110044/) right before the
    release of 1.4.

    Anyway, above is only my personal feeling about this issue, you should
    definitely wait for Russ or Keith (or others) for authoritative information.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Mar 25, 2015 at 6:06 am
    Yeah, that's all pretty much my understanding, I was just interested.
    I'll wait until khr or rsc weigh in.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Keith Randall at Mar 25, 2015 at 4:13 pm
    I don't think we have any definite plans. Certainly some more
    documentation would be in order.
    Yes, InterfaceData, Pointer, and UnsafeAddr are all unsafe. We recommend
    against using them. If you do use them, you want to wrap them immediately
    in an unsafe.Pointer cast so that the runtime does not GC in a state where
    you don't have a real pointer to the underlying object. If we ever have a
    moving GC, the immediate wrapping will be even more important. These
    methods require the use of package unsafe (or cgo) to use the results, so
    to some extent we're depending on unsafe users to know what they are doing.

    Possibly in Go 2.0 we would remove these methods. We can't remove them for
    1.x.
    On Tuesday, March 24, 2015 at 11:07:03 PM UTC-7, kortschak wrote:

    Yeah, that's all pretty much my understanding, I was just interested.
    I'll wait until khr or rsc weigh in.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Mar 25, 2015 at 7:13 pm
    Thanks, Keith.

    Follow questions up for future reference.

    quoted from precious post:
    """
    During part of the analysis I walk the structure retaining information
    about nodes that are referenced so I can output their address. When
    moving GC is implemented, this would leave me in a possible state where
    addresses output at the beginning of a dump don't agree with addresses
    to the same values at the end of a dump - this is something that will be
    more generally an issue for debugging I expect too.

    The approach that I think will work to deal with this is to keep a
    map[unsafe.Pointer]uintptr which maps the actual address to the uintptr
    converted address for the first time the pointer was seen, freezing it.
    This map is then used during the pointer output.

    Does this seem reasonable?
    """

    The second thing is how dropping Pointer in Go2 would affect things like the %p fmt verb (or code that depends on a combination of reflect and unsafe with pointers)?
    On 26/03/2015, at 2:43 AM, "Keith Randall" wrote:

    I don't think we have any definite plans. Certainly some more documentation would be in order.
    Yes, InterfaceData, Pointer, and UnsafeAddr are all unsafe. We recommend against using them. If you do use them, you want to wrap them immediately in an unsafe.Pointer cast so that the runtime does not GC in a state where you don't have a real pointer to the underlying object. If we ever have a moving GC, the immediate wrapping will be even more important. These methods require the use of package unsafe (or cgo) to use the results, so to some extent we're depending on unsafe users to know what they are doing.

    Possibly in Go 2.0 we would remove these methods. We can't remove them for 1.x.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Keith Randall at Mar 25, 2015 at 9:22 pm
    That does sound reasonable. There's no need for the value of the map to be
    the actual address, so you don't need the reflect functions at all. The
    "address" of an object doesn't make much sense anyway in a moving
    collector. Just use an incrementing counter to make unique ids.

    %p in Go 2? I don't know. Maybe we drop it, maybe fmt has an unsafe
    backdoor. In a moving collector, %p doesn't really tell you much.
      However, for objects outside the heap %p might still be useful to retain.
    On Wednesday, March 25, 2015 at 12:13:29 PM UTC-7, kortschak wrote:

    Thanks, Keith.

    Follow questions up for future reference.

    quoted from precious post:
    """
    During part of the analysis I walk the structure retaining information
    about nodes that are referenced so I can output their address. When
    moving GC is implemented, this would leave me in a possible state where
    addresses output at the beginning of a dump don't agree with addresses
    to the same values at the end of a dump - this is something that will be
    more generally an issue for debugging I expect too.

    The approach that I think will work to deal with this is to keep a
    map[unsafe.Pointer]uintptr which maps the actual address to the uintptr
    converted address for the first time the pointer was seen, freezing it.
    This map is then used during the pointer output.

    Does this seem reasonable?
    """

    The second thing is how dropping Pointer in Go2 would affect things like
    the %p fmt verb (or code that depends on a combination of reflect and
    unsafe with pointers)?

    On 26/03/2015, at 2:43 AM, "Keith Randall" <k...@google.com <javascript:>>
    wrote:
    I don't think we have any definite plans. Certainly some more
    documentation would be in order.
    Yes, InterfaceData, Pointer, and UnsafeAddr are all unsafe. We
    recommend against using them. If you do use them, you want to wrap them
    immediately in an unsafe.Pointer cast so that the runtime does not GC in a
    state where you don't have a real pointer to the underlying object. If we
    ever have a moving GC, the immediate wrapping will be even more important.
    These methods require the use of package unsafe (or cgo) to use the
    results, so to some extent we're depending on unsafe users to know what
    they are doing.
    Possibly in Go 2.0 we would remove these methods. We can't remove them
    for 1.x.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Mar 25, 2015 at 10:00 pm

    On Wed, 2015-03-25 at 14:21 -0700, Keith Randall wrote:
    That does sound reasonable. There's no need for the value of the map
    to be the actual address, so you don't need the reflect functions at
    all. The "address" of an object doesn't make much sense anyway in a
    moving collector. Just use an incrementing counter to make unique
    ids.

    %p in Go 2? I don't know. Maybe we drop it, maybe fmt has an unsafe
    backdoor. In a moving collector, %p doesn't really tell you much.
    However, for objects outside the heap %p might still be useful to
    retain.
    The use case I have, a structure-globally snapshotted approach to %p
    actually does make sense even in a moving collector world.

    If I use the map approach mentioned, then I can output a consistent view
    on addresses to allow human (or other external system) readable output
    of a data structure state (the code where I'm doing this is a fork [1]
    of go-spew - this issue [2] explains a particular case to understand the
    general situation). There would obviously be unsafe approaches to get
    this same information, but it seems to me that removing something that
    is intrinsically safe (unless unsafe is imported and used) is cutting
    off a nose to spite a face (obvious caveats that Go2 is a long way a
    away and so this discussion is premature).

    [1]https://godoc.org/github.com/kortschak/utter
    [2]https://github.com/kortschak/utter/issues/2

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMar 24, '15 at 11:01p
activeMar 25, '15 at 10:00p
posts15
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase