Before, I think the memory is allocated by mmap anon, which Linux OS guarantees reading will return zero value and no physical pages allocated. When writing happens, the physical pages will be allocated. Then I think the create a byte slice maybe the same.
Your idea is clear. I agree with it. Just now, I use gdb to dump the ballast anon memory and use hexdump to check its dirty content, all data is zero (Maybe zeroing happens). But after turning GC off, it works as expected (no RSS is taken, no DIRTY). I think there must be something I didn't get it. On Sunday, November 6, 2022 at 8:11:51 PM UTC+8 Jan Mercl wrote: > On Sun, Nov 6, 2022 at 12:54 PM Kn (Kn) <hit.zh...@gmail.com> wrote: > > > Now the problem begins. I expect the ballast like `ballast := > make([]byte, 1<<30)` shouldn't take up any physical memory because there's > no any writing to it. > > The backing array is specified to be zeroed, so we cannot say there's > no writing to it. Depending on the size of the backing array and the > operating system it may not get written as an optimization if backed > by memory the OS can guarantee to be zero filled. Only then it may > remain not yet bound to physical memory. > > A simple implementation will just zero it, meaning the opposite > happens - every byte of the backing array gets written and backing > pages for it get allocated. > -- 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/39c96691-ef76-4bda-86ea-351e0b96cedbn%40googlegroups.com.
