Artur Biesiadowski wrote:
> 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.
I didn't mean something exactly like the JNI. I meant a vtablized API. I
don't see how this is terribly slow...
> 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.
JITs, in most cases, are a huge performance hit. The whole reason it's
acceptable is that the programs will hopefully run for a long enough time
that the performance hit will be amortized out.
> 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.
I didn't specify which side would have a JNI-like api. In my mind, there
would have to be api's on both sides (the vm would implement part, and the
jit would implement part as well.)
> 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.
> 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).
Well, since you haven't checked the source lately, please allow me to
correct your misconceptions.
The extra slots for local variables are not used by anything other than the
JVMDI interface. In fact, japhar doesn't even set them in all cases. The
JIT wouldn't have to use them if it didn't want to. No other code (besides
JVMDI) depends on them being there.
> 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.
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.
> I suppose that there are number of other places with similar problems.
Gee, thanks.
> 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
Artur. Excuse me, but why are you such an asshole? I've never tried to
make other people use Japhar. I work on Japhar because it's something that
makes me happy. It's something to occupy my time. I couldn't care less if
people use it. If they do, great. If they don't, I'll still work on it.
So please, if you're going to be "honest," do it someplace else. If you
feel like "helping," I'd be more than happy to accept patches from you. But
after this message, so long as you feel the need to sit on high and dispense
knowledge on How To Do Things Right (which you seem to do every few
months... wait - isn't this message identical to the last one you sent?)
when we are already aware of the things you're saying, you will be summarily
ignored.
> 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.
Thanks again for the insight.
> 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.
"just started." Japhar has been running javac for quite a while now,
Artur. I believe you must be thinking of some other free VM. But again, to
correct your misconception, Japhar has often gone back to the 'nothing runs'
stage to fix problems. But we didn't do this because you wanted us to, so
you're free to feel ignored.
> But I think that it is only way to get japhar out
> of open source maniacs niche:
>
> DO THE VM DESIGN RIGHT.
... According to Saint Artur.
> Object and class layout aren't things that can be done incrementally,
Not true. Japhar has done incremental changes to class/object layout
several times. Each time getting better and better performance. Just
because that's not how you choose to do things doesn't invalidate it as a
development option.
> 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
common sense.
> - how to imlement monitors and identity hashcode for object (small and
> fast)
again, common sense.
> - garbage collection (how make compacting collector possible)
there are people working on it.
> - field access and method/interface calls as fast as possible
field accesses are already about as fast as possible. method/interface
calls have been sped up a tremendous amount recently. Do you ever read the
japhar list before dispensing these jewels?
> - good integration of interpreter with compiled code + integration of
> both stacks with possibly precise gc
precise gc is impossible with the possibility of arbitrary C code in native
methods.
> - 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.
Heh. "Go look here to find out how to do it right." I've read the
ElectricalFire project documentation. I've looked at the code a lot -
I helped get it released at netscape. We're not operating in a vaccuum,
here. I've taken ideas from them. But I don't want to end up with
ElectricalFire sitting in the japhar cvsroot.
That will be all. I'm going back to work on my VM. Mail of this sort (both
yours, and this response) wastes my time.
Chris
