harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodrigo Kumpera <kump...@gmail.com>
Subject Re: [arch] Interpreter vs. JIT for Harmony VM
Date Wed, 21 Sep 2005 17:30:10 GMT
Having a mixed JITed-interpreted enviroment makes things harder.
Writing a baseline, single pass JITer is easy, but there are A LOT
more stuff to make a port that just the code execution part.

JikesRVM have a base JITer class that does the bytecode decoding and
one subclass per platform that does the code generation. Porting is a
matter of creating another subclass and implement a few methods (a LOT
less than the 198 opcodes from the java bytecode).

The hard part is not the code of the JITer subclass, but writing an
assembler for it. Take x86, for example, generating all those
addressing modes is pure and simple PITA. And there are other code
artifacts that need to be generated, like call traps and interface
dispatch functions.

Then we have some platform specific issues, like exception handling,
stack walking, scanning and unwinding, native calls, NPE traps and
many more that I´m missing here.

The GC code should suffer from some plaform issues due to read/write
barriers, card marking methods, how to park all threads, etc.

And this is only just to port from one hardware platform to another.
OS porting is another big source of problems.

All in all, I think that using a JITed only enviroment is easier.


On 9/21/05, Peter Edworthy <peter@edworthy.org> wrote:
> Hello,
>
> > Do we need an interpreter or a fast code generating, zero optimizing JIT?
>
> I'd vote with a zero optimizing JIT. My reasons are not so much based on
> speed, but on code reuse. The structures required to support this would
> also be used by optimizing JITs. In an interpreter and JIT system the two
> tend not to overlap as nicely. Less code & concepts to understand =
> better, IMHO.
>
> > I can think of advantages to each approach. Assuming a C/C++
> > implementation, a traditional interpreter is easy to port to a new
> > architecture and we can populate Execution Engines (EE) for different
> > platforms rather easily.
>
> (This is at the edge of my knowledge, I've read about it but never tried it)
> If the JIT is a bottom up pattern matching compiler, which seems to fit
> well with the Java Byte Code format, then populating the 'pattern tables'
> especially if not aiming for much if any optimization would be just as
> easy as setting up EEs.
>
> > On the other hand, a fast code-generating JIT can call runtime helpers and
> > native methods without additional glue code whereas an interpreter has to
> > have special glue code to make it work in a JIT environment. Needless to
> > say, if a method is called more than once, the one time cost of JITing
> > without optimization may be lower than the cost of running the interpreter
> > loop.
>
> For Magnus an example to explain the above.
>
> a = sin (b) compiles to something like
>
> load b
> push
> call sin
> pop
> mov a
>
> If the sin function is native then for an interpreter the process would be
>
> read load b; push
> carry out equivalent operation
> read call sin
> Find sin method is native
> call native call routine
>   call sin
>   return sin return
> read pop; mov a
> carry out equivalent operation
>
> so the call to the sin function is actually two jumps, which is bad as
> jumps take time and often invalidate the data cache in the processor.
>
> If compiled then it would be
>
> load b; push; call sin; pop; move to a
>
> There is only one call to get to the sin method
>
> > Our experience is that a fast, zero optimizing JIT can yield low-enough
> > response time. So, I think at least Harmony has the option of having a
> > decent system without an interpreter. Thoughts?
> Again less is more ;-}>
>
> Thanks,
> Peter Edworthy
>
>

Mime
View raw message