Eliot,

> Cog already supports multiple bytecode sets.  The current
> compiled method header format has only space for a single
> bit so Cog currently supprts two bytecode sets.  [...]

Interesting. I don't know why, but I had an impression that the plan was
to add an offset as some bits in each method header that you would then
add to each "logical" bytecode to get the "physical" bytecode. I guess
one bit is equivalent to having the offset be either 0 or 256. Allowing
other values would make it possible to share bytecodes between sets (but
with different values), but this would be too complicated for practical
use.

> Why is it costly?

The instruction ("microcode") cache has a 4KB area that is loaded by the
hardware and a 4KB area that is loaded under software control. This
second area is a table with 256 entries of 16 bytes each, with each
entry holding the native code to interpret a particular bytecode. So to
switch to another bytecode set you have to reload this 4KB area with
different contents, and that will probably cause the rest of the cache
to miss a lot for a while.

Adding a flag and either growing that part of the cache to 8KB or
reducing each entry from 16 to 8 bytes each would allow two bytecode
sets. But with several cores, each with its separate cache, this
probably isn't worth it.

-- Jecel