Re: [BDW-GC] Static cell/string/symbol allocation

[Ludovic Courtès]

Hi!

address@hidden (Ludovic Courtès) writes:

> I modified <snarf.h> in the BDW-GC branch to transparently have all
> `SCM_SYMBOL ()' invocations use a statically allocated stringbuf.  The
> symbol itself still has to be interned then so for simplicity the
> implementation statically allocates an immutable string and then uses
> `string->symbol' at initialization time to create an interned symbol
> (which reuses the string's stringbuf).

Here's an estimate of how much memory ends up being statically allocated
for libguile itself:

  $ cat libguile/*.c | grep -e 'SCM_\(GLOBAL_\)\?SYMBOL' | \
    sed s'/SCM_\(GLOBAL_\)\?SYMBOL[[:blank:]]*([^,]\+, "\([^"]\+\)".*$/\2/g' \
    |wc -c
  2921

This is the number of bytes of all the raw ASCII strings that make up
the symbols.

  $ cat libguile/*.c | grep -e 'SCM_\(GLOBAL_\)\?SYMBOL' | \
    sed s'/SCM_\(GLOBAL_\)\?SYMBOL[[:blank:]]*([^,]\+, "\([^"]\+\)".*$/\2/g' \
    |wc -l
  181

This is the number of symbols.  Since we have two double-cells (on a
32-bit arch, each double-cell is 4 * 4 = 16 byte-long) per symbol (one
for the stringbuf and one for the string), we end up statically
allocating 2921 + (16 * 181) = 5817 B.  OTOH, since we use
`string->symbol', we still have to allocate another 16 * 181 = 2896 B
worth of double-cells (for the symbols) so the "savings" are just
2921 B, i.e., 2921 B that are statically allocated instead of
dynamically (and they are shared, since they are read-only).  Producing
directly statically-allocated writable uninterned symbols would help
here.

We could apply the technique to the 1001 subrs (~16 KiB of
double-cells), but these still have to be initialized at run-time.  So
it looks like there isn't so much to be gained here.  Comments?

Thanks,
Ludo'.