1. 04 Oct, 2018 5 commits
  2. 03 Oct, 2018 29 commits
  3. 02 Oct, 2018 6 commits
    • Brad Fitzpatrick's avatar
      net/http: make Transport send WebSocket upgrade requests over HTTP/1 · a73d8f5a
      Brad Fitzpatrick authored
      WebSockets requires HTTP/1 in practice (no spec or implementations
      work over HTTP/2), so if we get an HTTP request that looks like it's
      trying to initiate WebSockets, use HTTP/1, like browsers do.
      
      This is part of a series of commits to make WebSockets work over
      httputil.ReverseProxy. See #26937.
      
      Updates #26937
      
      Change-Id: I6ad3df9b0a21fddf62fa7d9cacef48e7d5d9585b
      Reviewed-on: https://go-review.googlesource.com/c/137437
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDmitri Shuralyov <dmitshur@golang.org>
      a73d8f5a
    • Aleksandr Razumov's avatar
      net/http: rewind request body unconditionally · 3aa3c052
      Aleksandr Razumov authored
      When http2 fails with ErrNoCachedConn the request is retried with body
      that has already been read.
      
      Fixes #25009
      
      Change-Id: I51ed5c8cf469dd8b17c73fff6140ab80162bf267
      Reviewed-on: https://go-review.googlesource.com/c/131755
      Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      3aa3c052
    • Austin Clements's avatar
      runtime: eliminate gchelper mechanism · 0906d648
      Austin Clements authored
      Now that we do no mark work during mark termination, we no longer need
      the gchelper mechanism.
      
      Updates #26903.
      Updates #17503.
      
      Change-Id: Ie94e5c0f918cfa047e88cae1028fece106955c1b
      Reviewed-on: https://go-review.googlesource.com/c/134785
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      0906d648
    • Austin Clements's avatar
      runtime: eliminate work.markrootdone and second root marking pass · 550dfc8a
      Austin Clements authored
      Before STW and concurrent GC were unified, there could be either one
      or two root marking passes per GC cycle. There were several tasks we
      had to make sure happened once and only once (whether that was at the
      beginning of concurrent mark for concurrent GC or during mark
      termination for STW GC). We kept track of this in work.markrootdone.
      
      Now that STW and concurrent GC both use the concurrent marking code
      and we've eliminated all work done by the second root marking pass, we
      only ever need a single root marking pass. Hence, we can eliminate
      work.markrootdone and all of the code that's conditional on it.
      
      Updates #26903.
      
      Change-Id: I654a0f5e21b9322279525560a31e64b8d33b790f
      Reviewed-on: https://go-review.googlesource.com/c/134784
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      550dfc8a
    • Austin Clements's avatar
      runtime: flush mcaches lazily · 873bd47d
      Austin Clements authored
      Currently, all mcaches are flushed during STW mark termination as a
      root marking job. This is currently necessary because all spans must
      be out of these caches before sweeping begins to avoid races with
      allocation and to ensure the spans are in the state expected by
      sweeping. We do it as a root marking job because mcache flushing is
      somewhat expensive and O(GOMAXPROCS) and this parallelizes the work
      across the Ps. However, it's also the last remaining root marking job
      performed during mark termination.
      
      This CL moves mcache flushing out of mark termination and performs it
      lazily. We keep track of the last sweepgen at which each mcache was
      flushed and as each P is woken from STW, it observes that its mcache
      is out-of-date and flushes it.
      
      The introduces a complication for spans cached in stale mcaches. These
      may now be observed by background or proportional sweeping or when
      attempting to add a finalizer, but aren't in a stable state. For
      example, they are likely to be on the wrong mcentral list. To fix
      this, this CL extends the sweepgen protocol to also capture whether a
      span is cached and, if so, whether or not its cache is stale. This
      protocol blocks asynchronous sweeping from touching cached spans and
      makes it the responsibility of mcache flushing to sweep the flushed
      spans.
      
      This eliminates the last mark termination root marking job, which
      means we can now eliminate that entire infrastructure.
      
      Updates #26903. This implements lazy mcache flushing.
      
      Change-Id: Iadda7aabe540b2026cffc5195da7be37d5b4125e
      Reviewed-on: https://go-review.googlesource.com/c/134783
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      873bd47d
    • Austin Clements's avatar
      runtime: eliminate blocking GC work drains · 457c8f4f
      Austin Clements authored
      Now work.helperDrainBlock is always false, so we can remove it and
      code paths that only ran when it was true. That means we no longer use
      the gcDrainBlock mode of gcDrain, so we can eliminate that. That means
      we no longer use gcWork.get, so we can eliminate that. That means we
      no longer use getfull, so we can eliminate that.
      
      Updates #26903. This is a follow-up to unifying STW GC and concurrent GC.
      
      Change-Id: I8dbcf8ce24861df0a6149e0b7c5cd0eadb5c13f6
      Reviewed-on: https://go-review.googlesource.com/c/134782
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      457c8f4f