[Fwd: Unreviewed patch]

[Zack Weinberg]

On Fri, Nov 03, 2000 at 09:19:58PM +0100, Laurynas Biveinis wrote:
> > 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.  
> 
> When I copied that, I looked if I could remove it from gcc/configure.in.
> But at that time it seemed to be used somewhere else (can't recall now - 
> maybe preprocessor?). I'll recheck that now.

It's only used in ggc-page.c.  You may be thinking of HAVE_MMAP_FILE.

> > 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.
> 
> I was thinking about putting this part into separate patch. But I can
> make one big batch too, no problem here.

Actually I'd recommend splitting it by directory - first get the
necessary infrastructure into libiberty, then convert gcc to use it.

> > However, it appears that it is
> > still possible to get the pathological behavior where we waste one
> > page for every page allocated.  
> 
> Right, in the case of malloc. Alexandre Oliva's original patch had
> code which tries to determine the way system's malloc works to get
> it to allocate page-aligned memory without big wasting. But it didn't
> work on all platforms, that's why I've played safe with malloc.

valloc on some systems also wastes a page per page allocated.  But I
agree with your decision to play it safe.

It might be worth looking for memalign as well as valloc.

> > 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).
> 
> In personal mail earlier you've agreed that removing this optimization
> is OK if it is very hard to keep it. But with your idea it is much
> easier anyway.

I was talking about the mmap batching, which is marginal.  The munmap
batching, on the other hand, is rather important on SMP systems.

> > 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?
> 
> That's fine. I'll implement it in my copious free time and resend the
> updated patch.

I may try to do this myself, if I have time in the next week or so.

zw