[Fwd: Unreviewed patch]

Zack Weinberg zackw@stanford.edu
Thu Nov 2 21:20:00 GMT 2000


On Fri, Oct 27, 2000 at 03:45:35PM +0200, Laurynas Biveinis wrote:
> 
> This patch moves page-aligned memory allocation to liberty and adopts
> GC to use it. Also it allows to use plain malloc() for page-aligned memory
> allocation, which enables ggc-page on platforms w/o mmap() or valloc().
> This patch fixes one of biggest showstoppers on DJGPP - ggc-simple is too
> slow to compile anything useful.

It's not really my area of the compiler, but I've been playing with GC
performance issues and it'd be real nice if ggc-simple went away.  I
like the principle, but I have some nitpicks relating to the configure
changes, and a major concern regarding the algorithm.

Please don't send diffs for configure.  They are rarely useful and
they bulk up the patch.

You copied the configuration check for MMAP_ANYWHERE from
gcc/configure.in into libiberty/configure.in.  It doesn't appear to be
necessary to do it over in gcc/configure.in.  If that's so, you should
take it out completely.  Likewise, if there are any other tests in
gcc's configure.in that are rendered unnecessary by this patch, take
them out too.

The AC_DEFUN([AC_FUNC_MMAP_ANYWHERE]) block belongs in
libiberty/aclocal.m4, not libiberty/configure.in.

Do I correctly understand that ggc-simple.c is no longer necessary on
any platform, with this patch?  If so you should remove all traces of
its selection logic from gcc's configure.in and Makefile.in, then
delete the object file rule and the file itself.  Otherwise it will
remain forever, confusing people.

Now for the major concern.  I do not understand what is done in
xvalloc.c when mmap is not available.  However, it appears that it is
still possible to get the pathological behavior where we waste one
page for every page allocated.  Also, we lose the ability to batch
allocations and deallocations on systems with mmap.  This is a serious
problem.  mmap is usually cheap, but munmap can be extremely expensive
(it has to invalidate TLB entries and sometimes memory cache).

It seems to me that both of these concerns would be addressed if
xvalloc asked the underlying allocator, whatever it is, for large
chunks of memory, then doled them out one page at a time.  When an
entire chunk became free, then we would deallocate it.  What is your
opinion of this idea?

Whatever you decide to do, you should comment xvalloc.c more
thoroughly.  I'd feel a lot better about this patch if I could
comprehend the non-mmap case.

zw


More information about the Gcc-patches mailing list