Open aclements opened 6 years ago
This bug description sounds like the race detector is broken with tip since the sparse heap switch. Is it actually broken or just sub-optimal?
It's mostly not broken. :) In the unlikely event that the runtime encounters another memory mapping when it's attempting to grow the heap linearly, it will skip forward by 4GB in the virtual address space, which right now will cause the race detector to consume an extra 2GB of memory (which it will never touch and doesn't matter on Unix-like OSes, but which Windows charges the process for). And this could happen multiple times (though that's even more unlikely). If this happens 32 times, then it could genuinely break because the heap could start to grow outside of the area required by the race detector, though if it happens 32 times something is probably terribly wrong already.
Change https://golang.org/cl/104717 mentions this issue: runtime: stop when we run out of hints in race mode
Currently, the race detector runtime for Go assumes that the heap is contiguous and grows up. In particular,
MapShadow
always maps the meta shadow contiguously. According to @dvyukov's comment, this was done to deal with the fact that the Go heap grew irregularly and the meta shadow mapping has large alignment constraints.As of 2b415549, the Go heap is no longer contiguous and doesn't necessarily grow up. However, it also now grows in large, aligned blocks (as of 78846472, 4MB on Windows, 64MB elsewhere). This easily satisfies the alignment constraints on the meta shadow. Hence, the meta shadow mapping code can be simplified to take advantage of this while at the same time adding support for Go's new sparse heap layout.