We do still re-JIT for each thread on PPC, though we wouldn't have to
The real problem that all JIT architectures still have is a different one: its called const_table and hidden either in the CONST macro or in syntax like NUM_CONST, which is translated by the jit2h.pl utility.
String, number (and PMC) constants are all addressed in terms of the compiling interpreter. Basically everywhere, where the exec code adds text relocations we aren't safe (e.g. load_nc in the PPC jit_emit code).
When we do an eval() e.g. in a loop, we have to create a new constant table (and recycle it later, which is a different problem). Running such a compiled piece of code with different threads would currently do the wrong thing.
Access to constants in the constant table is not only a problem for the JIT runcore, its a lengthy operation for all code, For a string constant at PC[i]:
interpreter->code->const_table->constants[PC[i]]->u.string
These are 3 indirections to get at the constants pointer array, and worse they depend on each other, emitting these 3 instructions on an i386 stalls for 1 cycle twice (but the compiler is clever and interleaves other instructions)
For the JIT core, we can precalculate the location of the constants array and store it in the stack or even in a register (on not so register-crippled machines like i386). It only needs reloading, when an C<invoke> statement is emitted.
OTOH it might be better to just toss all the constant table access in all instructions, except:
set_n_nc set_s_sc set_p_pc # alias set_p_kc
This would reduce the interpreter size significantly (compare the size of core_ops_cgp.o with core_ops_cg.o). The assembler could still allow all constant variations of opcodes and just translate it.
leo
