Go allocator requests memory from OS in large arenas (on Linux x86_64 the size of arena is 64Mb), then allocator splits each arena to 8 Kb pages, than merges pages in spans of different sizes (from 8kb to 80kb size according to https://go.dev/src/runtime/sizeclasses.go). This process is well described in various blog posts and presentations.
But there is much less information about scavenger. Is it true that in contrast to allocation process, scavenger reclaims to OS not arenas, but pages underlying idle spans? This performed with madvice(MADV_DONT_NEED). If so, Am I correct that after a while the virtual address space of a Go application resembles a "layered cake" of interleaving used and reclaimed memory regions (kind of classic memory fragmentation problem)? Looks like if application requires more virtual memory after some time, the OS won't be able to reuse these page-size regions to allocate contiguous space sufficient for arena allocation. Are there any consequences of this design for the runtime performance, especially for the RSS consumption? Finally, how does runtime decide, what to use - munmap or madvice - for the purposes of memory reclamation? Thank you -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/57975587-88f5-4808-8c8d-12c9b8d4391fn%40googlegroups.com.
