zero in the new unique package

[Jochen Voss]

Dear all,

I am looking at the source code for the new "unique" package (just out of curiosity).

One thing I did not understand: why is `zero` defined to be an `uintptr`?

https://cs.opensource.google/go/go/+/master:src/unique/handle.go;l=16

My understanding is the `zero` variable just provides a unique memory location, and any type, e.g. byte, would have worked just as well.  Is this right?  Was uintptr choosen for performance reasons?  Or to guarantee alignment?

Many thanks,

Jochen

[Константин Иванов]

Hello.

May be because all zero-size values have the same pointer: https://go.dev/play/p/n0dKQFN2EpR
Because the values have no memory location.

четверг, 28 ноября 2024 г. в 14:21:06 UTC+3, Jochen Voss:

[roger peppe]

On Thu, 28 Nov 2024 at 23:36, 'Константин Иванов' via golang-nuts <golan...@googlegroups.com> wrote:

Hello.

May be because all zero-size values have the same pointer: https://go.dev/play/p/n0dKQFN2EpR
Because the values have no memory location.

I think that's part of the story: we can't just take a pointer to the zero-sized value because that may or may not be guaranteed to be the same pointer (there's no language guarantee that it is, and indeed in some circumstances it might not be). So we need a non-nil pointer to something as a placeholder.

But why uintptr? AFAICS that zero variable could have been defined as any non-zero-sized type. Perhaps uintptr was chosen to guarantee word alignment and avoid any potential false sharing?

четверг, 28 ноября 2024 г. в 14:21:06 UTC+3, Jochen Voss:

Dear all,

I am looking at the source code for the new "unique" package (just out of curiosity).

One thing I did not understand: why is `zero` defined to be an `uintptr`?

https://cs.opensource.google/go/go/+/master:src/unique/handle.go;l=16

My understanding is the `zero` variable just provides a unique memory location, and any type, e.g. byte, would have worked just as well.  Is this right?  Was uintptr choosen for performance reasons?  Or to guarantee alignment?

Many thanks,

Jochen

--
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...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/248ca7dc-debb-438e-b858-bdc6aa2c2e17n%40googlegroups.com.

[Cuong Manh Le]

Hello,

> My understanding is the `zero` variable just provides a unique memory location, and any type, e.g. byte, would have worked just as well.  Is this right?

Yes.

> Was uintptr choosen for performance reasons?  Or to guarantee alignment?

None of the above.

`uintptr` was chosen for being consistent with runtime.zerobase, which is also an uintptr.

Before `runtime.zerobase` is used, it was `runtime.zeroObject`, which is a `byte`, that's the result of rewriting mallocgc from C -> Go.

In the mallocgc C source, the zerobase is defined as an uintptr:

extern uintptr runtime·zerobase;

Then in the process of support for auto-generating Go constants from the C definitions, duplicated constants were removed, prevent

out of sync between C and Go constants. The result is that zeroObject was removed and `runtime·zerobase` becomes `runtime.zerobase`.

Last but not least, since unique.zero and rutime.zerobase represents the base memory address of 0-byte object, what's better than an uintptr?

My 2 cents.