golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
124.14k stars 17.69k forks source link

runtime: make goid and goidgen 64 bits #4275

Closed rsc closed 9 years ago

rsc commented 12 years ago
goidgen should be 64 bits to make wraparound impossible.
Assigning to Dmitriy because the race checker cares more than the runtime.
dvyukov commented 12 years ago

Comment 1:

Can we remove the goid entirely?
For the race detector I want to add an additional pointer to race detector context to
the G struct. Using goid's is inconvenient and slow. Currently there is a 10^6 limit on
total number of goroutines under the race detector, this is needed for fast direct
mapping between goid's and internal contexts, but I've seen a test that creates more
goroutines.
If we add the explicit race context pointer to G, then the race detector does not care
about goid's as well.
For the scheduler patch (https://golang.org/cl/6441097) I had to effectively
remove goid's. The single atomic increment on shared var can severe impact scalability.
This will limit the rate at which goroutines can be created (otherwise they can be
allocated from local cache, scheduled on local queue and then deallocated to local
cache).
I've started with using G pointer as identifier in crash dumps, and then switched to
"persistent" goid's. That is, an unique goid is assigned to G struct when it's first
allocated and then it's not updated when G is reused.
So I would prefer to:
1. Add explicit race context to G.
2. Switch to "persistent" goid's. They should not overflow.
rsc commented 12 years ago

Comment 2:

I want incrementing never-used-before goids for printing stack traces.
They don't have to be and probably shouldn't be used for anything else.
Russ
dvyukov commented 12 years ago

Comment 3:

What do you mean by "incrementing never-used-before goids"? Do you mean the same way
they work now? If so, it looks like a rather high price for printing stack traces.
When we have Processors, we can have unique ids by combining Processor id (16 bits) with
monotonically increasing per-Processor id (48 bits).
ianlancetaylor commented 12 years ago

Comment 4:

The price for an incrementing never-before-used goid does not seem terribly high to be. 
It costs one atomic 64-bit increment for each new goroutine created.
Having a goid does not preclude having the G structure point to the race context.
dvyukov commented 12 years ago

Comment 5:

This issue was closed by revision 320df44f04928285fa55a20d07864d366052b82.

Status changed to Fixed.