Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
runtime: annotation for sysAlloced types #13386
@randall77 recently found some subtle issues related to write barriers on fields that point from runtime structures allocated from non-GCed (and hence non-scanned) memory to GCed heap memory. I manually audited all non-GCed structures to find any other such pointers, but obviously manual auditing can get out of date.
One possible way to help automate this is to add an annotation on types that are allocated from non-GCed memory. This annotation would disallow pointers to types that do not have this annotation and would disallow calling new on this type (implicit heap allocations are already disallowed in the runtime). It should probably also disallow unsafe.Pointer in annotated types (effectively requiring uintptr instead).
This adds a //go:notinheap pragma for declarations of types that must not be heap allocated. We ensure these rules by disallowing new(T), make(T), append(T), or implicit allocation of T, by disallowing conversions to notinheap types, and by propagating notinheap to any struct or array that contains notinheap elements. The utility of this pragma is that we can eliminate write barriers for writes to pointers to go:notinheap types, since the write barrier is guaranteed to be a no-op. This will let us mark several scheduler and memory allocator structures as go:notinheap, which will let us disallow write barriers in the scheduler and memory allocator much more thoroughly and also eliminate some problematic hybrid write barriers. This also makes go:nowritebarrierrec and go:yeswritebarrierrec much more powerful. Currently we use go:nowritebarrier all over the place, but it's almost never what you actually want: when write barriers are illegal, they're typically illegal for a whole dynamic scope. Partly this is because go:nowritebarrier has been around longer, but it's also because go:nowritebarrierrec couldn't be used in situations that had no-op write barriers or where some nested scope did allow write barriers. go:notinheap eliminates many no-op write barriers and go:yeswritebarrierrec makes it possible to opt back in to write barriers, so these two changes will let us use go:nowritebarrierrec far more liberally. This updates #13386, which is about controlling pointers from non-GC'd memory to GC'd memory. That would require some additional pragma (or pragmas), but could build on this pragma. Change-Id: I6314f8f4181535dd166887c9ec239977b54940bd Reviewed-on: https://go-review.googlesource.com/30939 Reviewed-by: Keith Randall <firstname.lastname@example.org> Reviewed-by: Matthew Dempsky <email@example.com>