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: TestArenaCollision failing on Solaris #23862
2b41554 broke Solaris. For example, https://build.golang.org/log/d32bb2fc9ace29dcdddd34f0df6361a4a2978fbb:
Apparently Solaris can allocate user address space in the upper portion of the amd64 virtual address space.
There is a diagram of the Solaris memory map at http://www.oracle.com/technetwork/server-storage/solaris/solaris-memory-135224.html . I haven't looked at this test, but Solaris will put the stack and shared objects above
Thanks for the pointer; that's consistent with the builder failure. I'm already mapping enough metadata for 48 bit addresses because of arm64. I'll just have to close the hole either by masking off the sign extension or adding to rotate the hole around.
Currently, bulkBarrierPreWrite uses inheap to decide whether the destination is in the heap or whether to check for stack or global data. However, this isn't the best question to ask. Instead, get the span directly and query its state. This lets us directly determine whether this might be a global, or is stack memory, or is heap memory. At this point, inheap is no longer used in the hot path, so drop it from the must-be-inlined list and substitute spanOf. This will help in a circuitous way with #23862, since fixing that is going to push inheap very slightly over the inline-able threshold on a few platforms. Change-Id: I5360fc1181183598502409f12979899e1e4d45f7 Reviewed-on: https://go-review.googlesource.com/95495 Run-TryBot: Austin Clements <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Rick Hudson <email@example.com>
Accessing the arena index is about to get slightly more complicated. Abstract this away into a set of functions for going back and forth between addresses and arena slice indexes. For #23862. Change-Id: I0b20e74ef47a07b78ed0cf0a6128afe6f6e40f4b Reviewed-on: https://go-review.googlesource.com/95496 Run-TryBot: Austin Clements <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: Rick Hudson <firstname.lastname@example.org>
Now that we support the full non-contiguous virtual address space of amd64 hardware, some of the comments and constants related to this are out of date. This renames memLimitBits to heapAddrBits because 1<<memLimitBits is no longer the limit of the address space and rewrites the comment to focus first on hardware limits (which span OSes) and then discuss kernel limits. Second, this eliminates the memLimit constant because there's no longer a meaningful "highest possible heap pointer value" on amd64. Updates #23862. Change-Id: I44b32033d2deb6b69248fb8dda14fc0e65c47f11 Reviewed-on: https://go-review.googlesource.com/95498 Run-TryBot: Austin Clements <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Rick Hudson <email@example.com>