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