Thanks for the explanation, it make sense to me, and I find that the MemoryAllocator is refactored, it's readability is better now.
Regards, Jianxiao On Tuesday, January 11, 2022 at 10:22:59 PM UTC+8 dinf...@chromium.org wrote: > Hi, > > this is indeed surprising. I suppose the main reason for this behavior is > that we record memory size before and after the GC (see > https://source.chromium.org/chromium/chromium/src/+/main:v8/src/heap/gc-tracer.cc;l=330). > > If we would decrement size_ some time after that point, we wouldn't see > that memory size decreases after a GC. > > Regards, > Dominik > > On Wednesday, December 22, 2021 at 8:17:20 AM UTC+1 jianx...@intel.com > wrote: > >> In MemoryAllocator, there is a member variable size_ to record current >> committed memory size.. >> The size_ increase after allocate or commit a VirtualMemory. >> From the perspective of symmetry, the size_ should decrease after free or >> uncommit a VirtualMemory . >> But in fact it's in PreFreeMemory. >> When free pages with mode kPooledAndQueue, the size_ will decrease during >> UnregisterMemory during PreFreeMemory, but the MemoryChunk is not really >> freed or uncommitted. >> >> I think the decrease of size_ should be in PerformFreeMemory. >> I wonder what is the purpose of the current design? >> > -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/fc6f293d-bf79-45de-8388-a251dabd74abn%40googlegroups.com.
