testing needed for branch luben/gc_threshold_adjust

Luben Karavelov karavelov at spnet.net
Fri Nov 26 00:54:13 UTC 2010


 Working with bacek and NotFound I have created new branch that need 
 testing.

 The problems considered:

 - Current parrot determines gc_threshold (memory wasted by GC) at 
 configure time. There is inconsistency between platforms - some 
 platforms have gc_threshold as fraction of total memory (BDS,Darwin), 
 other platforms have gc_thresold as fraction of free memory (SysV, 
 Linux, Win32). Further, gc_threshold is not consistent between parrot 
 runs on the later platforms because it does not take into account fs 
 caches and buffers used by the OS. Example: rakudo compile could take 
 from 2 to 12 minutes depending on the state of the system (in either 
 case the compile was the only job running).

 - Different programs have different needs. Bigger threshold gives 
 better throughput, smaller threshold gives better interactive behavior. 
 In current parrot we could not change gc_threshold.

 Changes in the branch:

 - Parrot_sysmem_amount() return the total installed memory
 - gc_threshold is fraction of total installed memory
 - gc-threshold commandline parameter is used to specify the percentage 
 (default 5%). This parameter was already there but it was not used in 
 the current GC system.

 Testing needed:
 - On win32 systems: I have made changes in 
 config/gen/platform/win32/sysmem.c but I do not have win32 system to 
 test.
 - On memory constrained systems : could you compile rakudo? If not, try 
 with different --gc-threshold parameter and report what value works for 
 you.
 - On all systems: is it faster or slower than before? What percentage 
 for --gc-threshold works best for you?

 Best regards

-- 
 Luben Karavelov



More information about the parrot-dev mailing list