#1805: GC threshold and other values need to be set during configuration
---------------------+------------------------------------------------------
Reporter: jkeenan | Owner:
Type: todo | Status: new
Priority: normal | Milestone:
Component: GC | Version: 2.8.0
Severity: medium | Keywords:
Lang: | Patch:
Platform: |
---------------------+------------------------------------------------------
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
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/1805>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
