runtime: special case timer channels

[dvyukov]

Consider special-casing timer channels created with time.Ticker and time.After.
Namely, such chans need to contain next fire time and period. Then receive from such
looks like:

func chanrecv(c *Hchan) {
  ...
  if c.isTimeChan {
    for {
      next := c.nextTime
      if next == -1 {
        // already fired one-time timer
        blockForever()
      }
      newTime := -1
      if c.period != 0 {
        newTime = next + c.period
      }
      if CAS(&c.nextTime, next, newTime) {
        wait := next - now
        if wait > 0 {
          sleepFor(wait)
        }
        return
      }
    }
  }
  ...
}

This has several advantages:
1. No need to stop timers. If nobody waits on a timers, it's just a normal heap object
that can be garbage collected.
2. Faster operation for both blocking and non-blocking case.
3. Faster selects involving time chans.
4. Can combine time.Ticker/After into a single allocation.

[bradfitz]

Comments about this bug are in https://go-review.googlesource.com/#/c/8356/

[rsc]

I intend to look into this for Go 1.7. I've started work on a CL.

[dvyukov]

Note there is a caveat: if we have code like:

t := time.NewTimer(time.Munute)
for {
  select {
  case <-t.C:
  case ...
  }
}

Currently we arm and install the timer once. If we special case timer channels, we will need to install and uninstall the timer for each select.
Or do you have some smart plan for this?

[quentinmit]

@rsc is this going to make 1.8?

[gyf19]

@dvyukov @rsc ping？

[rsc]

Did not get to this.

[bcmills]

1. No need to stop timers. If nobody waits on a timers, it's just a normal heap object
   that can be garbage collected.

That seems like a disadvantage, not an advantage: it would encourage writing non-portable Go code (that is, programs which appear to work when using the gc compiler but leak memory when compiled with other implementations).

Unless you're proposing to make a corresponding language change, in which case this seems like it needs to be a full-fledged proposal.

4. Can combine time.Ticker/After into a single allocation.

There is a more general version of this optimization which we might want to consider anyway. If we:

• have a struct with a pointer or reference-type field, and
• can detect at compile-time that the referent of that field never changes (because it is not exported and never reassigned in methods), and
• heuristically believe that the struct and referent always or almost always have the same lifetime (e.g. because the struct contains unexported fields, has only pointer methods, and is always returned by pointer),

then we can (and arguably should) combine the struct and the referent into a single allocation.

That optimization is more or less orthogonal to any special-casing for timer channels in select.