At 7:01 PM -0700 5/22/02, Sean O'Rourke wrote:
>I took a look at what was going on, and found that the GC probably needs a
>good tuning. For the 20K file, parrot is doing 217 collections of the
>string pool, the last 102 of which reclaim less than 10% of the pool.
>Changing compact_string_pool() to increase the pool size by a factor of
>(0.5 - pct_freed_last_time) if it reclaimed less than 50% of memory
>reduced this to 21 collections, much fewer of which reclaimed abysmally
>small amounts of memory.
Interesting. Could you work with Peter Gibbs and see what the two of
you can do to come up with an adaptive collection system? That's the
best way to go in the long term--the current system's functionally
complete, but far from well tuned.
>This is a total quick hack -- I'm fairly sure I'm doing it in the wrong
>place, and it's no replacement for real generational collection.
>However, it does improve performance by something like a factor of 4.
>Could someone point me to somewhere I could find out more about the
>performance-relevant aspects of the GC design?
Our GC design? It's a straightforward compacting collector, nothing
at all fancy outside the potential for multiple FromSpaces.
> Are there plans to make it
>generational in the future? The PDD seems to deal mostly with safety
>issues.
There's nothing in the design of the system to prevent it, I hope (if
there is, then this'd be a good time to point out the flaws so we can
see about fixing them), but neither are there anything other than
nebulous "at some point" plans for it.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
