Re: Extreme PRE compile times

[Daniel Berlin <dberlin at dberlin dot org>]

>
> Yeah, it's not your fault, what we now have basically just sucks.
>
> We should have a way to allocate objects in GC space, but where the user
> somehow has more control over what can be allocated/freed.  There are many
> passes that produce obvious garbage and right now we put it right between the
> "non-garbage".  That's just wasteful.

That's why the zone collector has a garbage zone.

>
> The idea I had to work around this a bit, is to introduce some kind of GC pool
> allocator.  A pass would allocate some memory in GC space, and allocate/free
> objects in that space.  Memory for freed objects could be re-used, just like
> with "real" alloc pools.  The pass would be resposnsible for making sure that
> nothing points at "freed" objects.  At the end of the pass the space would be
> "released" to the garbage collector.

This is just arenas with page table entries shared with the gc, AFAICT.
:P

> This gives passes some kind of "scratch space", and you'd only have to collect
> at the end of each pass.  And things like fragmentation would be at least no
> worse than what we have now.
>
> (Something like this would also make it easier to make basic blocks & edges
> garbage collectable without losing the nice properties of alloc-pools...)
>
> This all is probably not too hard to implement for the page allocator (dunno
> about ggc-simple/ggc-zone, or what would happen on out-of-memory, or...).
> The thing is, right now it would have to be implemented for _three_ different
> collectors :-(

The zone collector can do this trivially. Just create a new zone at the
beginning of the pass, and free it at the end!

> Does it sound like a reasonable idea at all?

>
> BTW Just how much garbage does PRE produce?

About 5-9 meg for 16000 blocks, per expression :P.
But this is because I pool allocate the erefs, for example.

>
> Gr.
> Steven
>
>