Re: Speeding up GC

[Daniel Berlin <dberlin at dberlin dot org>]

> 
> 2) Functions like loop.c:product_cheap_p() generate RTL to see
>    if valid expressions of a given type can be created and if so
>    see what it looks like.  Then the RTL is %100 forgotten.
> 
>    FIX: Create a "short-term" mode for GC allocation.  Enable this
>    mode around such allocations.
It might make more sense, rather than even bothering to mark this stuff, 
to use memory pools/arenas.
Unlike obstacks, you can realloc/free given pieces of memory in the arena 
easily, but you can destroy all of the arena at the end of the pass or 
whatever.

For thinks where we *know* the lifetime to a certainty (IE it's only 
supposed to live for this pass), why should we be making the GC try to 
figure it out?

This seems like the right solution to me for our throwaway/fixed lifetime 
objects.

The problem with gc is that it's slow because it effectively tries to 
figure out when your objects are dead, so it's bad for throwaway objects.
The problem with obstacks is that they are too inflexible, and don't let 
us do anything but allocate (easily, anyway).
So something in the middle, that lets you allocate/free/realloc without 
penalty, but still blow away everything quickly when you are done seems 
right.
Which would, of course, be memory pools/arenas (whatever you want to call 
them).

> To me, it seems much more prudent to fix the cause of the problem
> instead of adding all of these page protection et al. games to GC.
> What I am hearing right now from rth and others is "We allocate things
> stupidly in the compiler, so we're going to fix the allocator."
>