First, I'm sorry - I shoud really check out current state of japhar
before saying anything. It seems that a lot of works is done which is
not reflected/discussed on this mailing list - and it caused my
perception of japhar being more or less still for last months/year.
I'm checking out latest source now and I'll try to backup some of things
I mentioned here with actual code fragments. I do not want to be just a
bad guy, so I'll try to come with something creative :)
For now just answers to few parts - you can assume that I've agreed with
rest and I'm ashamed of things I've said there.
Chris Toshok wrote:
> > 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.
>
> The most basic core logic? How about all the code generation? I seriously
> doubt TYA (or any other JIT) would have to generate substantially different
> code to interact with different VM's. I would consider the VM interaction
> to be one of the smaller pieces of the puzzle for JITs.
It really depends on jit. I suppose the more complicated is the jit, the
more code will be shared. With simple one-by-one opcode substitution,
like one in tya, really a lot of code is VM dependent.
You talk about code generation. Only opcodes that could be really
handled in same way are simple stack ops + basic math. If you look at
tyarecode.c almost 1/3 of it is taken by invoke* code - very vm specific
code. Add to it get/set field/static, monitorenter/exit, throw, all
array opcodes and more than half of file needs to be rewritten for other
vm.
Entire tyaruntime.c, some of tyarechelp.c, a lot of tya.c, I'm not sure
about others, would also have to be changed.
A bit large portion of code to be handled by abstract interfaces. With
more complicated jits, more and more code will become common - it might
has sense then.
> You've used this argument before, Artur. I actually removed the stores of
> variable types and it made *very* little different in performance (on my pc,
> anyway.) The store is accompanied by other things anyway (an increment for
> the opstack pointer, and a comparison to make sure we aren't going to
> overflow.) -- It's not like removing the assignment of the local variable
> type is going to halve the code being executed. This has to be the same in
> other VM's as well. Also, the JIT is free to leave the extra assignment out
> entirely.
Last sentence is important - I wasn't aware of this (also of many other
things as it turned out). But I cannot agree with rest. Of course if you
will use interpreter with switch for opcodes and then check stack and
code everything in C, one assigment does not make difference. But in tya
like code difference is between:
MOV EAX -> [EBP+n]
POP EAX
and
MOV EAX -> [EBP+n]
MOV magic_number -> [EBP+n+4]
POP EAX
and it makes greater difference. But if jits aren't required to fill it
in, then let's forget about this thing.
> precise gc is impossible with the possibility of arbitrary C code in native
> methods.
Hotspot works in some way, doesn't it ?
Of course if you mean really arbitrary code, then nothing is possible
(after C code will memset all vm data to 0). But if we are talking about
C code conforming to JNI specs - not storing references without
requesting global handle etc, then it is possible. In short, all jobject
ptrs point to special handles which get updated when object is moved.
Most of JNI calls have to be atomic in regard to gc, but it can be done.
What are the other reasons for it being impossible ?
The real problem is how to precisely recognize references versus
integers on java stack, not on C stack. But it can be done.
Artur
P.S.
Please, do not treat this as a flame - I understand that I was too heavy
on subject, I'm sorry.
