Recent changes impeded building and testing on smaller boxes

[Nick Wellnhofer]

On 25/09/10 15:40, James E Keenan wrote:
> 256M happens to be amount of Physical Memory reported by 'top' for this
> machine. Changing the gc_threshold from 256M to 64M did enable 'make
> test' to run completely (including t/compilers/opsc/*.t) and PASS in
> about 19 minutes. So the value of the gc_threshold does have a
> significant impact on whether parrot will run (in any meaningful sense)
> on a particular machine.

Can you try the gc_ms2_tuning branch that I just created? I ported the 
dynamic threshold and the --gc-threshold command line option to the new 
GC code and made some other changes that should bring it back to the 
performance and memory consumption levels of the old GC.

> Now, I know that there are some who will snigger at the thought of
> trying to test Parrot on a machine that is more than 6 years old. "Just
> go out and buy a new laptop, kid51. It'll be sure to have at least 10
> times as much memory as that ancient, battered box."

The only big problem at the moment is the memory consumption during a 
Rakudo build. Building core.pir uses about 240MB plus GC overhead, so 
this will cause swapping on a 256MB machine. I think the build process 
could be changed to consume less memory but I'm no expert in this area.

Nick