This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: malloc-based ggc-page
On Jan 18, 2000, Mark Mitchell <mark@codesourcery.com> wrote:
> I question whether this is really worth it.
It is. I, as a user of a system that used to use ggc-slow (which
should be the real name of ggc-simple :-) because no other alternative
was (known to be) available, would be very much pleased to be able to
use ggc-page instead.
> o Any system without `malloc' is just not interesting.
There's no system without malloc, is there?
> o Any system with `malloc' can easily be made to provide *at least*
> an inefficient `valloc' -- just by malloc'ing more than a
> page at a time.
That's precisely the point this patch is trying to accomplish.
> Basically, I feel like you should take your code, wrap it us as
> valloc, and provide it as a valloc substitute in `libiberty', rather
> than putting it in the collector.
Unfortunately, that's not possible. If only the heuristics, as you
say, could be made in a way that *ensures* they'll eventually lead to
an aligned page, it would be possible. However, because we may have
to fallback to the
ask-for-one-extra-pagesize-and-align-within-the-obtained-block hack,
the pointer we'll end up returning to the requester cannot be free()d.
That's the reason why it's impossible to implement a portable xvalloc.
Unless the user agrees to call xvfree or something. (*)
However, even in this case, the caller needs feedback from the xvalloc
implementation so as not to waste whole pages just because he's
requesting for a byte more than the xvalloc implementation can fit in
a page, considering its space overheads. So we'd also need
xvpagesize() and xvoverhead(). And then, there's also xvinit(), that
must be called early enough in the program so that it can get
``clean'' malloc blocks, i.e., not previously allocated blocks nor
holes therein.
If you say that's the way to go, I'll be glad to move it into
libiberty and arrange for ggc-page to use it.
> Instead, you're folding the efficient `valloc' implementation into
> GCC, except that because you're not actually integrated with `malloc'
> you're having to use a bunch of clever heuristics. (And they are
> clever!)
Please note that they're not just heuristics. They're provably
correct, no matter how weird the implementation is. By correct, I
mean:
1- it will always provide a page-aligned address with as many bytes as
requested following it.
2- it will not consume all the memory of the system attempting to find
such a page.
> I think this is the wrong thing to do. It makes GCC's collector
> more complex, more difficult to maintain, and more likely to have
> different failure modes on different machines. One of the nice things
> about going to the collector is that I've been tracking down *no*
> memory allocation bugs in the last few months -- it just works. But,
> when something does fail, it's still a pain to figure out why
> something got collected, etc.; dealing with a lot of memory management
> stuff in there as well is just going to make it harder.
(*) Note that the Solaris man-page of valloc() doesn't state that the
value it returns can be used as an argument to free(). In fact, it
explicitly says the argument to free() must have been returned by
malloc(), calloc() or realloc(). No mention to valloc() nor
memalign(), that are covered in the very same man page. However, it
doesn't mention any way to release valloc()ed pages. :-(
Isn't ggc-page in error attempting to free() the value returned by
valloc()?
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them