Inline threaded interpreter?
Submitted by zhukov on Sun, 03/28/2004 - 15:53.
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.
- Login to post comments
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
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.