weak: docs don't guarantee Pointer compares not equal for different values

[FiloSottile]

weak.Pointer docs say this about when they compare equal

// Two Pointer values always compare equal if the pointers from which they were
// created compare equal. This property is retained even after the
// object referenced by the pointer used to create a weak reference is
// reclaimed.
// If multiple weak pointers are made to different offsets within the same object
// (for example, pointers to different fields of the same struct), those pointers
// will not compare equal.
// If a weak pointer is created from an object that becomes unreachable, but is
// then resurrected due to a finalizer, that weak pointer will not compare equal
// with weak pointers created after the resurrection.

However, to use safely as a cache key, two things need to be true

• always compare equal if the pointers from which they were created compare equal (yes)
• never compare equal if the pointers from which they were created don't compare equal (unclear?)

In particular, I am worried about using weak.Make(x) as a cache key, then x is garbage collected, a new value y is allocated at the same address, and now weak.Make(y) compares equal to my weak.Pointer map key.

I think this can't be the case, because at that point Value would end up returning y instead of x, but that's me reading into the implementation details, rather than the docs telling me what I am doing is safe.

[ianlancetaylor]

CC @mknyszek

[mknyszek]

What you intend to do is supported.

In particular, I am worried about using weak.Make(x) as a cache key, then x is garbage collected, a new value y is allocated at the same address, and now weak.Make(y) compares equal to my weak.Pointer map key.

This won't happen. Weak pointers map to object identity, not address identity, which "This property is retained even after the object referenced by the pointer used to create a weak reference is reclaimed" is trying to indicate.

I think the docs are a little confusing around "pointer" here, but mainly for those that understand what's going on under the hood. "Same pointer" doesn't really mean "same address." "Pointer" is being used in the sense of the Go spec, which isn't really aware of a garbage collector, and operates (in some sense) under an illusion of infinite memory (there's a way to create objects, but no way to destroy them).

To be absolutely clear: say you have a pointer to some object. If you copy that pointer and create two weak pointers from it, they will compare equal. If you lose that pointer and the object is collected, the two weak pointers will still compare equal. Later, if an object of the same type is allocated at the same address, weak pointers created to that object will not compare equal with the previous two weak pointers. At the point where the first object at that address is collected, you can never again construct a weak pointer that will compare equal to the two that pointed to that object, because you lost that object's pointer (even if other pointer values have the same address).

If you have suggestions on how to improve the docs, feel free to send a change, or post them here. Thanks.

[FiloSottile]

Sweet, that's what I assumed but couldn't find definitive confirmation of in the docs.

I think it might be as simple as making the first sentence "Two Pointer values always compare equal if and only if the pointers from which they were created compare equal."

Does that sound correct?

[mknyszek]

Yup, sounds right to me. I'll send a patch.

[gopherbot]

Change https://go.dev/cl/643935 mentions this issue: weak: clarify Pointer equality semantics

[gabyhelp]

Related Code Changes

• weak: clarify Pointer equality semantics

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}