petdance/scratch — Issue #340: GC threshold and other values need to be set during configuration
Author: petdance
Created: 2011-11-01 04:25:44+00:00
State: open

Since the merge of the gc_massacre branch into trunk at r49269, we have experienced a number of problems during `make` and `make test`. These have been discussed [http://news.gmane.org/find-root.php?message_id=%3ci7ku3k%24a2v%241%40dough.gmane.org%3e on parrot-dev] as well as on #parrot. In the course of this discussion, attention was called to the fact that certain values affecting garbage collection are hard-coded deep inside ''.c'' source code files.

As a general rule, it is not a good idea to bury hard-coded values deep inside source code. They should be made available for determination by the user during the configuration process. We need to pull these values out of source code and make them more visible during Parrot configuration.

Here's a GC-amateur's list of GC-related values which appear to be hard-coded into our source code:
{{{
./src/gc/gc_ms2.c:626: self->gc_threshold = 256 * 1024 * 1024;
./src/main.c:429: if (interp->gc_threshold > 1000) {

src/gc/alloc_resources.c

26 #define RECLAMATION_FACTOR 0.20
27 #define WE_WANT_EVER_GROWING_ALLOCATIONS 0
28
29 /* show allocated blocks on stderr */
30 #define RESOURCE_DEBUG 0
31 #define RESOURCE_DEBUG_SIZE 1000000
...
280 static void
281 check_fixed_size_obj_pool(ARGIN(const Fixed_Size_Pool *pool))
282 {
283 ASSERT_ARGS(check_fixed_size_obj_pool)
284 size_t total_objects;
285 size_t last_free_list_count;
286 Fixed_Size_Arena * arena_walker;
287 size_t free_objects;
288 size_t count;
289 GC_MS_PObj_Wrapper * pobj_walker;
290
291 count = 10000000; /*detect unendless loop just use big enough number*/
...
328 count = 10000000;
...
357 static void
358 check_var_size_obj_pool(ARGIN(const Variable_Size_Pool *pool))
359 {
360 ASSERT_ARGS(check_var_size_obj_pool)
361 size_t count;
362 Memory_Block * block_walker;
363 count = 10000000; /*detect unendless loop just use big enough number*/
}}}
We currently have one configuration step, `auto::gc`, which configures configuration. But since we currently only offer users one garbage collection system, this step (found in ''config/auto/gc.pm'' doesn't do much other than to identify ''src/gc/alloc_resources.c'' as the location where GC is determined. `auto::gc` currently conducts no C probes of the user's machine. It might as well be `init::gc` and its status as an 'automatic probe' configuration step merely reflects legacy settings.

(To recap how configuration works (oversimplified): `init::` steps take configuration values from Perl 5 `%Config` or other hard-coded locations; `inter::` steps work similarly but, on request, will offer the configurer several options; `auto` steps calculate settings, largely based on running C probes of the user's machine, that should not need user intervention; and `gen` steps take all the values discovered in the first three kinds of steps and writes Makefiles and other files needed for build and records the values in ''lib/Parrot/Config/Generated.pm'' and ''config_lib.pir''.)

The hard-coded values listed above should, at least in certain cases, be user-configurable. That means that the configuration of garbage collection needs to be moved to some combination of `init::`, `inter::` and `auto::` steps. For example, if we determine that on machines with 'small' physical memory the value of `gc_threshold` needs to be set an order of magnitude smaller than 256M, then we need to probe the machine for the size of its physical memory, then calculate an appropriate value for `gc_threshold`, then provide the user the option of confirming/altering this choice at a command-line prompt.

I can't yet propose specific modifications of the configuration system to handle GC values. But I am convinced that some or all of these values need to be extracted from ''.c'' source code files and made explicit during configuration.

Thank you very much.

kid51