PATCH: new GC implementation
Mark Mitchell
mark@codesourcery.com
Thu Sep 30 23:58:00 GMT 1999
>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
Richard> Recalling my previous comment that changing the memory
Richard> map of a process is inherently expensive, you don't want
Richard> to give pages back to the OS right away -- you want to
Richard> keep a pool of free memory, and if the pool grows too
Richard> big, you want to combine calls to munmap for adjacent
Richard> pages.
Mark> Do you think that's worth it? We were seeing numbers like
Mark> 0.03% of the total time for compiling attrtab.i being spent
Mark> in munmap; about the same amount of time in mmap. It seems
Mark> to me like there's no need to complicate the algorithms here
Mark> for a 0.06% win.
Actually, I retract this objection. Alex, I think we noticed a lot
more page faults, and more system time, with the new GC. That's
probably because of the kernel lazily zeroing pages we allocated; by
caching free pages we avoid the extra zeroing and the extra page
fault.
So, I think Richard is right on the money; we should probably pool up
a bunch of free (system) pages, and only actually unmap them if there
get to be a lot of them.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
More information about the Gcc-patches
mailing list