Hello!
The `bdw-gc-static-alloc' branch now contains an implementation of
statically allocated subrs. This was done in 2 steps:
1. Using double-cells instead of single-cells for subrs [0]. The
patch is quite nice in that it simplifies `procs.[ch]'. This
change is needed so that subrs don't contain a subr entry number
allocated at run-time (the subr entry number is the index of the
subr in the subr table).
It does not introduce any storage overhead: previously, a subr
consumed one cell and sizeof (scm_t_subr_entry), i.e., 2 + 4 = 6
words; with the patch, a subr consumes one double cell and 2 words
for `meta_info', i.e., 4 + 2 = 6.
The change leaves the 24 MSBs of the first word of the cell unused.
We might want to do something smart with all these bits.
For these reasons, we may want to merge this patch in `master' as
well.
2. The second step does the actual work [1]. Currently, it only
deals with subrs, i.e., primitive procedures with "relatively few"
arguments (see `create_gsubr ()').
To distinguish subrs (few arguments) from gsubrs (unrestricted
arity, see `default:' in `create_gsubr ()'), a Dirty Hack(tm) was
needed. The hack is that `SCM_DEFINE' is an alias for a new macro
`SCM_DEFINE_SUBR_reqX_optY_rstZ', where X, Y and Z are the number
of required, optional and rest arguments. If X, Y and Z are such
that a raw subr can be used, then the macro is an alias for
`SCM_DEFINE_SUBR', which does the actual static allocation;
otherwise, it's an alias for `SCM_DEFINE_GSUBR', which is the same
as `SCM_DEFINE' in `master'.
The dirtiest part of the hack is the generation of "snarf-gsubr.h"
which contains definitions of `SCM_DEFINE_SUBR_reqX_optY_rstZ' for
a "reasonable" number of combinations of X, Y and Z (C++ template
specialization would solve this problem much more elegantly...).
The good news is that it actually works. :-)
I ran `gcbench.scm' with both BDW-GC branches and didn't observe any
significant difference. The benefits are that (i) initialization should
be slightly faster, and (ii) running several instances of guile should
consume less memory since statically allocated data can be mapped
read-only by the loader and, consequently, the underlying physical
memory can be shared across instances.
Thanks,
Ludo'.
[0]
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=2ee5aa25dbd679b175707762f5961585027e1397
[1]
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=46f9baf49a8ea4461e8494c75a88b87d0f5c5195
