[go-nuts] Why gc's work.cycles not need to consider integer overflow?

[陶青云]

work.cycles defined as uint32.  Assuming gc happens every 2ms,  it take  
(1 << 32) / 500 / (24 * 3600) = 99 days to overflow.  it seems possible.

gcWaitOnMark use  (n > work.cycles) test,  is this a problem here? 

```
// gcWaitOnMark blocks until GC finishes the Nth mark phase. If GC has
// already completed this mark phase, it returns immediately.
func gcWaitOnMark(n uint32) {
        for {
                // Disable phase transitions.
                lock(&work.sweepWaiters.lock)
                nMarks := atomic.Load(&work.cycles)
                if gcphase != _GCmark {
                        // We've already completed this cycle's mark.
                        nMarks++
                }
                if nMarks > n {
                        // We're done.
                        unlock(&work.sweepWaiters.lock)
                        return
                }

                // Wait until sweep termination, mark, and mark
                // termination of cycle N complete.
                work.sweepWaiters.list.push(getg())
                goparkunlock(&work.sweepWaiters.lock, 
waitReasonWaitForGCCycle, traceEvGoBlock, 1)
        }
}
``` 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0ef890a8-269a-4b2f-a2e9-ab56980ae17cn%40googlegroups.com.