Skip to content

G
golang
Switch branch/tag
  1. 12 Jun, 2015 2 commits
  3. 11 Jun, 2015 11 commits
  5. 10 Jun, 2015 6 commits
  7. 09 Jun, 2015 13 commits
  9. 08 Jun, 2015 5 commits
  11. 07 Jun, 2015 3 commits
    • Austin Clements's avatar
      runtime: unwind stack barriers when writing above the current frame · 306f8f11
      Austin Clements authored 
      Stack barriers assume that writes through pointers to frames above the
current frame will get write barriers, and hence these frames do not
need to be re-scanned to pick up these changes. For normal writes,
this is true. However, there are places in the runtime that use
typedmemmove to potentially write through pointers to higher frames
(such as mapassign1). Currently, typedmemmove does not execute write
barriers if the destination is on the stack. If there's a stack
barrier between the current frame and the frame being modified with
typedmemmove, and the stack barrier is not otherwise hit, it's
possible that the garbage collector will never see the updated pointer
and incorrectly reclaim the object.

Fix this by making heapBitsBulkBarrier (which lies behind typedmemmove
and its variants) detect when the destination is in the stack and
unwind stack barriers up to the point, forcing mark termination to
later rescan the effected frame and collect these pointers.

Fixes #11084. Might be related to #10240, #10541, #10941, #11023,
 #11027 and possibly others.

Change-Id: I323d6cd0f1d29fa01f8fc946f4b90e04ef210efd
Reviewed-on: https://go-review.googlesource.com/10791Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      306f8f11
    • Austin Clements's avatar
      runtime: enable write barriers during concurrent scan · 1303957d
      Austin Clements authored 
      Currently, write barriers are only enabled after completion of the
concurrent scan phase, as we enter the concurrent mark phase. However,
stack barriers are installed during the scan phase and assume that
write barriers will track changes to frames above the stack
barriers. Since write barriers aren't enabled until after stack
barriers are installed, we may miss modifications to the stack that
happen after installing the stack barriers and before enabling write
barriers.

Fix this by enabling write barriers during the scan phase.

This commit intentionally makes the minimal change to do this (there's
only one line of code change; the rest are comment changes). At the
very least, we should consider eliminating the ragged barrier that's
intended to synchronize the enabling of write barriers, but now just
wastes time. I've included a large comment about extensions and
alternative designs.

Change-Id: Ib20fede794e4fcb91ddf36f99bd97344d7f96421
Reviewed-on: https://go-review.googlesource.com/10795Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      1303957d
    • Austin Clements's avatar
      runtime: fix checkmarks to rescan stacks · 6f6403ed
      Austin Clements authored 
      Currently checkmarks mode fails to rescan stacks because it sees the
leftover state bits indicating that the stacks haven't changed since
the last scan. As a result, it won't detect lost marks caused by
failing to scan stacks correctly during regular garbage collection.

Fix this by marking all stacks dirty before performing the checkmark
phase.

Change-Id: I1f06882bb8b20257120a4b8e7f95bb3ffc263895
Reviewed-on: https://go-review.googlesource.com/10794Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      6f6403ed