Inline threaded interpreter?

Ok I know interpreter for jnode is out. Still I have a question did the interpreter used in previous versions use the inline threaded way of interpretation?
More on that:
SableVM project:
http://www.sablevm.org
Effective Inline-Threaded Interpretation of Java Bytecode Using Preparation Sequences:
http://www.sable.mcgill.ca/publications/papers/2003-2/sable-paper-2003-2...
It is very portable (requires no/little assembly) and a lot faster than switch()ed or direct threaded interpreting.

Big switch statement

It was a big switch statement (well an assembler jump table).

like:

loop:
- fetch instruction
- jump jumptable[instruction]

....
goto loop

Inline threading maybe?

direct threading:

void *code[] = { &&ICONST_2, &&ICONST_2, &&ICONST_1, &&IADD, ... }
void **pc = code;

goto **(pc++);

/* implementations */
ICONST_1: *sp++ = 1; goto **(pc++);

ICONST_2: *sp++ = 2; goto **(pc++);

IADD: --sp; sp[-1] += *sp; goto **(pc++);

/* we dont need while-switch with this: approx 3x faster */

inline threading:
/* Instructions */
ICONST_1_START: *sp++ = 1;
ICONST_1_END: goto **(pc++);

INEG_START: sp[-1] = -sp[-1];
INEG_END: goto **(pc++);

DISPATCH_START: goto **(pc++);
DISPATCH_END: ;

/* Implement the sequence ICONST_1 INEG */
void *buffer = malloc(large enough to hold ICONST_1_END - ICONST_1_START + *_END - *START code)
memcpy(buffer, (*_END - *_START CODE_REQUIRED) );

goto **buffer;

/* processor executes buffer directly */
/* 10 times faster than while-switch */

This technique is implemented in SableVM and is highly portable to most of architectures gcc compiler supports.
As for performance it is equal (sometimes lower sometimes higher) to Sun JVM interpreted performance which leads me to conclusion Sun uses this method in their VM. Maybe we could give it a try, until adaptive/optimizing/hotspot-like compiler is not written.

NOTE TO WEBADM: "pre" or "code" tag would be very useful Smiling

optimizing compilers under development

There are optimizing compilers (2) under development, which are already quite far.
Also having portable c code is not something i like jnode to contain. Better to say no c code at all.