You seem to be describing threaded code, but using a linked list instead of an array. Why go through the extra pointer chasing to use a linked list of code ent

You seem to be describing threaded code, but using a linked list instead of an array. Why go through the extra pointer chasing to use a linked list of code entry points instead of iterating over an array of code entry points? [jonesforth.s] is a great search term for a well-documented Forth implementation explaining how threaded code works. I'm actually surprised I've never seen a system that uses tiny JIT stubs to implement the interpreter portion of a modern hybrid interpreter and JIT system. The class loader would initially "JIT" each method as a function call to the interpreter function followed immediately by a return, with a pointer to a memory-mapped buffer of the bytecode after the return instruction. The interpreter function would look at its return address (which points to the JIT stub's return instruction) and add a constant offset to find the pointer to the bytecode to interpret. This avoids the need for an extra pointer indirection or conditional branch in your hot path method dispatch. Granted, in your really hot paths, you hope your JIT inlines everything.