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