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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
