Well, it’s taken a month and a half — and over 2000 lines of code — but I finally got a method out of Shark.

I made a chart showing which bytecodes are implemented, which I’ll keep updated as I progress. The estimated total coverage of 18% is slightly fanciful as it treats all bytecodes as equally complex, with nop having the same weight as new for example. Some codes are marked as complete but untested too. The way the compiler is structured means that in simple cases I can copy and paste whole blocks of bytecodes from the server compiler, so where I was doing one bytecode in a block I’ve copied the lot across. Most of them ought to be fine, but a couple are dubious. I’m still shuffling things around to try and make things less so.

Onwards…

Syndicated 2008-05-09 12:25:55 from gbenson.net

Shark just JITted its first bytecode:

load i32* %local0               ; :15 [#uses=1]
inttoptr i32 %sp to i32*        ; :16 [#uses=1]
store i32 %15, i32* %16
%sp1 = sub i32 %sp, 4           ;  [#uses=2]
</pre>
Ladies and gentlemen, it is aload_0!

Syndicated 2008-04-11 15:16:39 from gbenson.net

Yesterday I had a mini-milestone in that I got enough bits and pieces written to have HotSpot call my JIT’s compile_method() method. The next trick will be to get a piece of code back into HotSpot without it being relocated on the way.

Of course, the zero interpreter doesn’t have profiling, so it only works if you force it with -Xcomp at the moment.

Also, I disabled InlineIntrinsics, which reminded me that there was some kind of fast accessor thing for JNI that I disabled in the original ppc port. I should fix that at some point.

Syndicated 2008-04-01 08:15:12 from gbenson.net

Towards the end of last week I started trying to figure out how to slot an LLVM-based JIT into IcedTea. I had a vague idea that I could simply port C1 to it, but I’m not sure that would work so well. Both existing JITs expect to manage register allocation, for example, which LLVM will have to do. So I started hacking at the build system to have it build an entirely new JIT. I called it “shark” — I was going to call it C0 what with the other JITs being called C1 and C2, but I didn’t like the mild confusion that having them named and numbered causes, and shark was too good a name to waste on a one-off dummy architecture.

And speaking of one-off dummy architectures, my “if I can build on a platform that doesn’t even exist then I can build on anything” proved short lived — it doesn’t help on architectures that do exist but have really stupid unames that need truncating. I’m talking about ARM, of course, uname freak of the cosmos. So I’m going to try and get that working this week too.

Syndicated 2008-03-31 09:29:43 from gbenson.net

As of about an hour ago it should be possible to build icedtea6 on any Linux system with no more effort than ./configure and make.

Syndicated 2008-03-26 12:06:56 from gbenson.net