Chris Toshok wrote:
> This may be a good time to define a JNI-like interface for jits to use.
> I'd rather not write a layer on top of Japhar that makes it look like
> Sun's vm.
JNI is slow, but it is a cost for being binary compatible between
various object layouts and garbage collectors. And as more and more code
goes to java part, it is acceptable.
But I don't think that having slow jit is good thing. It is piece of
code designed only to be fast and generate fast code.
Said that, I don't think it is possible to write interface layer that
would allow jits to be even source compatible between VMs that really
differ. It COULD be possible to write generic jit and then use a lot of
macros/conditional code to allow compiling for given set of VMs, but it
is other way around to what you have proposed - not the uniform
interface of vm for many jits to conform, but interface to jit for which
vm implementors have to provide number of macros/parameters.
Some time ago I was thinking about doing such thing. I wanted to be more
or less vm and platform independent. In fact it turned out, that only
most basic core logic will be common, and even that had call to
vm/platform specific function/macro once per 3 lines.
As far as japhar is concerned, it should be quite easy to write simple
jit compiler similar to tya, borrowing from it's experiences. As TYA is
quite stable now, and will probably not suffer major change anymore, it
is safe to just rewrite it/hack it to be japhar compatible, without
worrying for keeping versions in sync. This would allow japhar to have
simple jit.
Real problem, I'm afraid, is that japhar was not created with
performance in mind. I have't checked source lately, but from what I
remember, it is using 3 slots for each local variable for example (1
type, 2 for possible long/double). Writing jit which will generate code
for it is just a waste for time - with simple design change you can
increase speed of local store twofold. I suppose that there are number
of other places with similar problems.
Let's be honest - I doubt if anybody except real open source maniacs
will use vm that is:
- order of magnitude slower
- without gc
- have memory footprint two times larger than others
- have problems with even simple programs
All of these have to be fixed before japhar will be production quality
program. When it started JNI conformance was almost only priority. Now
JNI compatibility isn't a 'feature' - it is a must.
I suppose that it will be ignored, because japhar just started to work
for more programs that hello world and it would be terrile to go back to
'nothing runs' stage. But I think that it is only way to get japhar out
of open source maniacs niche:
DO THE VM DESIGN RIGHT.
Object and class layout aren't things that can be done incrementally,
with just adding one more field if some problem emerge. You have to
design entire core in one step, thinking at same time about following
things:
- smallest object size possible
- how to imlement monitors and identity hashcode for object (small and
fast)
- garbage collection (how make compacting collector possible)
- field access and method/interface calls as fast as possible
- good integration of interpreter with compiled code + integration of
both stacks with possibly precise gc
- maybe few other things I've forgotten
There is some data on how it can be done well - for example hotspot
whitepapers/slides, or ElectricFire project.
Artur
