Hi Krys, 

On August 3, 2016 3:41:46 PM PDT, Krystal Mok <rednaxel...@gmail.com> wrote:
>(Having missed last night's dinner and all the fun there...)
>When Rémi started talking about this interpreter today, I thought it'd
>tailcall related.

I would love that it was tailcall related too. people seams to reduce tailcall 
to a feature of some obscure languages but in reality each time you have to do 
some argument transformations/injections/checking in a generic way, it screams 
for tailcall.

>In college, my introductory course to computer systems was based on the
>book "Introduction to Computing Systems: From Bits & Gates to C &
>where it introduces a small educational 16-bit architecture called
>LC-2. We
>were given a LC-2 simulator to run our "assembly" programs.
>Later on, when I've learned enough Java to be dangerous, I wanted to
>a more powerful simulator (interpreter) of the LC-2 ISA in Java.
>My first version was a most straightforward switch-threaded one.
>much to be said about that.
>The next version, wanting to mimic a indirect-threaded style, was
>structured in very much the same way Rémi presented in the link, but
>MethodHandle was still years from available so I didn't have the luxury
>using it. Instead, I modeled the opcode handlers as "single-method
>objects", and do a virtual call at the end of each handler.
>(So, instead of Rémi's MH calls, I'm just using a table lookup +
>public class NopHandler extends AbstractHandler // or implements
>  public void execute(State s) {
>    HANDLERS[s.code[s.pc++]].execute(s); // dispatch
>  }
>That's didn't work out quite well. The performance was okay-ish with
>program inputs. But HotSpot's JIT compilers doesn't implement tail call
>optimizations (well, recursive inlining sort of counts...), so with a
>long-enough program the stack blows up. And it didn't take that long of
>LC-2 assembler program to make it blow up.

To avoid of blowing the stack, the trick is to stop the "trace" at the end of a 
basic block, i.e. when you have a jump or a return. It also means that things 
like null check, things that should not jump, has to be encoded with a 
different bytecode that conditional jump because you don't want to stop the 
trace for them.

>I realized that I had to have proper tail calls to make it work. So I
>a central dispatch loop to serve as a trampoline, e.g.
>Handler next = getNextHandler();
>while (next != null) {
>  next = next.execute(s);
>where my Handler.execute() would still perform the lookup, but not the
>actual invocation. As expected, the performance was no where as good as
>directly making the virtual call at the tail position in each handler.
>central dispatch loop makes the unpredictable-ness of the
>Need a good trampoline. Need proper tail calls.


>- Kris


>On Wed, Aug 3, 2016 at 3:14 PM, John Rose <john.r.r...@oracle.com>
>> On Aug 3, 2016, at 1:22 PM, Remi Forax <fo...@univ-mlv.fr> wrote:
>> >
>> > Charles ask if we can make a fast register interpreter in Java,
>> > here is my take on a threaded-like interpreter
>> >
>> > https://gist.github.com/forax/f38b533e089217cfc4d0ae3c6e2de9c9
>> Nicely done.  We were talking last night at dinner about making
>> bytecode interpreters go fast, and this is helpful.
>> I think there may be a combinator here, for bytecode dispatch loops.
>> (This feels like the PIC combinator, both fundamental and tricky to
>> right.)
>> A "bytecode" dispatch combinator might provide a pattern like the
>> following:
>> MethodHandle init, pred, step, fini, index;
>> @NonNull MethodHandle[] tab;
>> R dispatch(A… a) {
>>    V v = init(a…);  // one here; there might be many v…
>>    while (pred(a…)) {
>>       v = step(v, a…);
>>       // execute one "instruction":
>>       int i = index(v, a…);
>>       tab[i].invokeExact(v, a…);
>>    }
>>    return fini(V, a…);
>> }
>> The explicit table would be recopied internally to an @Stable array
>> constant folding.
>> The various index values could be tracked and turned into traces (or
>> other profile
>> driven structure) which would be compiled together, in specialized
>> segments of the unrolled
>> interpreter loop.
>> Or maybe just the table lookup part alone makes a good combinator, to
>> paired
>> with the loop combinators?
>> Comments welcome…
>> — John
>> P.S. Another new RFE:
>> experimental hook for creating heisenboxes
>> https://bugs.openjdk.java.net/browse/JDK-8163133
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>mlvm-dev mailing list

Sent from my Android device with K-9 Mail. Please excuse my brevity.
mlvm-dev mailing list

Reply via email to