Java VM Update

[tonyw]

Some time ago I took on the task of getting kaffe, the open source Java compiler/interpreter/JIT to work on the A1 with AOS4. Here is a little update on what has happened so far.

Kaffe is a multi-platform distribution, supporting many machines. One of those machines is the 68k Amiga, although the distribution has not been touched since 1998. The kaffe "system" is configured for your hardware/OS, then compiled to produce a running installation. The Amiga configuration had not been touched since 1998, so by the time I got to it early this year, the main source had changed quite a bit and the Amiga build didn't work at all.

Since then I have managed to make the Amiga 68k build work again, even better than before, although part of that is the general improvement in the sophistication of the source. I have submitted my patches to the general source tree (mainly for the 68k Amiga version only).

Currently the Amiga 68k version runs on my 4000/060@50 MHz. Well, when I say 'runs', I don't mean 'run', or even 'walk'. To be truthful, it oozes like the green slime in Marble Madness. The main reason for the slowness is that whether compiling or running a compiled class, the 'system' loads all the gzipped run-time classes, then unzips them, dynamically allocates storage for each class, then copies the class into its new place in memory. As an example, that process takes 26,000 memory allocations just to store the classes into memory. And that's before the source file has even been opened. On my 600 MHz Duron-powered PC, it's a blink of an eye - about a tenth of a second.

On the Amiga, it's a minute or so for the same process - that's not just because the processor runs at a twelfth of the speed, but also because kaffe is running under ixemul, in a Linux emulation mode. So it's bloody slow. However, I have also installed a native 68k version of Linux on the Amiga, and kaffe runs about four times' faster on that OS using the same hardware.

To be fair to the designers of kaffe, that overhead is constant. Once the library has been loaded, it runs pretty fast from then on. Of course, under Linux, the file system is cached, so it doesn't thrash the disc drive the way it does under Amiga OS.

The kaffe development group have recently brought out a new version that loads pre-compiled classes more efficiently, but I haven't tried it yet. Neither have I tried out the JIT VM. I've only used the interpreter so far.

I expect the speed to improve greatly on the A1 under native PPC Linux, and under AOS4.

I have been concentrating recently on getting the "Regression" tests to run. There is a suite of 115 tests, and a test script that runs them all in turn. When first I got the Amiga version to run, only about 87/115 would run without error. After some work over the last month or so, I now have about 105/115 running without fault. Those that still fail, fail for these reasons:
2 fail because the test is for Linux pathnames like "." and "..". The Amiga OS fails these tests.
1 fails because the 68060 FPU has some issues with division of the maximum negative number (0x80000000).
3 fail because of arithmetic errors (in the last place of long numbers).
2 fail tests designed for the Solaris OS (but they pass on 68k Linux).
 - and some others.

I'd publish a running version for people to try on their 68k Amigas, but you need the whole GNU GeekGadgets thing, which is a pain in the neck. If anyone has this setup and would like a copy, PM me.

When the A1 arrives, I'll move the distro over to the new hardware and bring it up under PPC Linux. That will probably bring up a whole lot more problems.

Then, when AOS4 is available, it'll be a whole new ball game. I don't want to run ixemul on the new system, but we'll see what support there is going to be for Linux-like programs. There might be some built-in support that improves on the ixemul approach.

Work continues.

tony

[jahc]

I dont know anything about Java. Is this the Java that everyones jumping up and down about and screaming for? Java 2 1.3/1.4 whatever it is they were talking about in the recent Java thread in the AmigaOS development forum?

[tonyw]

No, this is not what people are screaming for. Those version numbers are for Sun's Java. Kaffe is supposed to be written to be compatible with the Sun specification, but contains no Sun code and has some compatibilty issues. It also has poor support for debugging, profiling and security features. However, it is free, there is an existing Amiga version, and it will be better than nothing. Also it gives me something constructive to do.

tony

[nyteschayde]

The version of kaffe that runs on the Amiga (68K) is equivalent of which jdk version? 1.1.x? 1.2+? Also how is the support for AWT and Swing? What isn't supported under the Amiga version of Java via Kaffe.

I know this seems like something that you would never want to do but I would like a version but I need it compiled for 68030 without FPU if possible. I wouldn't mind a 68040 w/FPU version as well. Please let me know where I need to go to get this as well as any files I need to get it up and running.

As far as geekgadgets I'll figure that out if I can get a decent working VM under the AmigaOS. Thanks in advance.

My email is nyteschayde@yahoo.com.

[Rob]

Keep up the good work!

[tonyw]

Hey, nyteschade:

You can download any of this kaffe stuff as sources from the kaffe site. If I were you, though, I'd get the Geekgadgets thing first. It took me two months to get that going properly. I tried downloading stuff from the web, but it's all varying update levels and lots of the stuff is incompatible with other versions. There isn't any one site that has a consistent set of GG code.

I eventually bought the CD set from Schatztruhe. Some of the stuff is a little out of date, but it's a consistent build and it'll get you started.

You won't be able to run kaffe unless you've got that going first. I can't give you a binary that will run under AmigaOS, and it's more than just loading ixemul.library into LIBS:.

You'll be talking like a Linux geek by the time you get it all to run.

tony

[Dan]

Wow, cool! 8-)
Actually I have the old version(with slow buggy AWT ) running on my amiga. But I never got neither guavac or jikes to run.
 The compilerclass is S L O W. :-)

This is very interesting indeed.

[Karlos]

For the current generation of amiga HW, for Java to be anything other than an academic curiosity, we really need a JIT system and a decent native optimised port of the runtime classes (those that handle graphics/sound/io at least).

Bytecode interpretation is slow as hell. A thread based JIT, combined with register allocation has the potential to run at near native speed and would make Java a serious development tool for Amiga.

[Agafaster]

True Karlos, but how to do it ?!

[filson]

according to Sun, the Java engine is buildt on C/C++, so creating a port with something like gcc should not be too complex. no need to rewrite the JIT as Sun most likely has more knowledge about this than we have.
Once the tools and the engine has been ported, the rest is already java (all the classes and stuff).

[Kronos]

A JIT in C++ ? I doubt that  ;-)

A JIT has to be handcrafted to every single target-CPU, and
somehow I doubt that SUN would just hand out a 68k-version ....

There is simply no market to raise a eyebrow in one of those companies.

[Karlos]

Kronos wrote:
A JIT in C++ ? I doubt that  ;-)

A common misconception. You can do anything in C++ that  you can do in C. That includes using hand coded assembly, low level pointer manipulation ect.
I know, I have done so myself, plenty of times.

A JIT has to be handcrafted to every single target-CPU, and
somehow I doubt that SUN would just hand out a 68k-version ....

Correct. You need to emit machine native opcodes. You also need to be able to manipulate data caches and the like (to properly flush the emitted opcodes).

Most of the high level interface could be written portably in C++. The low level back end that generates the code can be as target dependent as you like. You then create and use the appropriate back end for each system.

Take a look at the Kaffe sources to get an idea.

[Kronos]

@Karlos

Yes, I know, but IMO using inline asm and that stuff in a C++
means it ain't C++ but asm .....

Same goes for the old C-tricks.

If you want to write a efficient JIT, you will have to go down
to asm, there is simply no other way.

[Karlos]

Kronos wrote:
@Karlos

Yes, I know, but IMO using inline asm and that stuff in a C++
means it ain't C++ but asm .....

Well, I would never, ever use inline asm in the C++ part of a project. The asm keyword should be dropped! I only do low level stuff deep in the implementation dependent part of a project. That's the only way to avoid dependencies.
For example, I basically declare methods empty in C++ code to get their signature from the generated asm source. I then write the asm implementation of the function myself.

Same goes for the old C-tricks.

Agreed. I don't use use them either, I was just pointing out for the bebefit of other people that you can if you wish to do so.

If you want to write a efficient JIT, you will have to go down to asm, there is simply no other way.

I don't think thats true, exactly. Is your C++ compiler written in asm? Or is it written in C++ itself? It's the efficiency of the generated code that's most important. A good JIT should be fast at generating code (such that generation times are small compared to load/setup), but it doesn't have to be written in asm. Just look at the 68040 JIT emulation that comes with UAE. Java bytecode is an order of magnitude simpler than any real CPU.

For Java, where code only exists inside methods (except static class code), my preference is for function based transcription. Whenever the VM first invokes a method, the JIT kicks in, transcripts the code and caches it for later.