[CM] Idea: using handles instead of pointers, s7_clone

[bil at ccrma.Stanford.EDU]

To expand a bit on Elijah's note:

I don't think this will reduce cache misses or make objects smaller.
To evaluate anything, you have to access the things being evaluated.
Most of the points in the article you mention do not apply to s7 --
s7 manages its own memory, the cells are already packed tightly, etc.
In your s7_clone example, having two s7's call a function from one
of the s7's is dangerous because you might call s7_free on the source 
s7;
I actually don't know if this would work at all currently.

You can't use the s7 heap itself (which seems redundant because
the handle is just a pointer to the s7_pointer into the heap),
because cells can be removed from the heap (to reduce pointless GC 
work).
The article thinks it can save space by using 32-bit handles, but
I have run with 2 billion cells, and if I had a machine with enough 
memory,
I could overflow 32-bits.

Newer chips have larger caches -- I've seen 256 MBytes, so
cache misses might be solved by newer hardware.  When I ran
cachegrind, I didn't get the impression that cache misses
were a huge problem -- the bigger cache was about 15-20% faster
in the cases where it mattered at all.  Perhaps you could
run with a smaller heap.

Why do you need s7_clone?  I can call s7_init, load and evaluate
some stuff, then s7_free in about 1/2 millisecond.  Perhaps
you could keep a sort of history in scheme, then evaluate that
in the subsequent s7.  Or get the functions for the clone
from the files loaded in the current s7, and any computed
stuff might be passed via the "readable" object->string
facility.