Creating a new byte-code compatible java vm

General Discussions
#1

Are there any legal implications if someone creates a new bytecode compatible java vm ?

The java vm is a great thing but there are some things that are being implemented too slowly or probably never will. For example:

=> No problem with size. You distribute it with whatever packages you want.

=> JIT detects machine instructions that can greatly improve vector and matricial calculations.

=> JIT automatically detects the present of a gpu and generates gpu machine instructions when apropriate.

=> Being able to disable array bound checks for some operations.

=> Having a fast and dirty math option.

=> Having a better interface with C native code that will optionaly inline it and removing unnecessary call machine instruction and stack operations.

When i had an Amiga i used to make mini-games entirely in 68000 assembler for the cpu and the fat agnus assembler language for bliting and sprites. It wasn’t that hard. OK so this isn’t exactly the Amiga but how hard could it be making a compatible jvm like this ?

#2

Pretty damn hard :slight_smile: So hard that you’ll soon see Jeff come along and try to explain to you how much magic is involved in a high performance JVM. If I were you, and I really really wanted to create my own jvm, I’d take one of the existing open source JVMs out there and modify them.

To answer your first question - it is perfectly legal to create a byte code compatible VM(*).

  • elias

(*) Barring software patents, of course. Creating a VM could easily stumple upon some lame sw pat. from Kodak or someone else.

#3

So make the VM in the UK then :wink:

It’s legal to do whatever you like with it but you can’t call it Java unless it passes the TCK. And of course it’s such a bloody difficult thing to make.

Take a look at Blackdown.

Cas :slight_smile:

#4

What would be the hardest part to implement for a javavm in terms of algorithms ?

Edit: In the meantime i found an interesting link about the subject

http://orp.sourceforge.net/

#5

All the parts are really hard stuff. I wouldn’t even think of attempting it without a nice big team and a commercial interest.
On the other hand if you just want to write a bytecode interpreter I expect you could get reasonable enough performance from that to run the kinds of games that I write. Hm. (Wanders off to run Ultratron in interpreted mode) Well, blimey, yes, it would seem that interpreted mode is easily fast enough to push a few hundred sprites around at 60fps.

Cas :slight_smile:

#6

That would be a start. How complicated can be writing a c++ program to load a 1.4 class file and interpret it ?

#7

Loading and interpreting a 1.4 class shouldn’t be that hard, however, you won’t get anything useful out of it without the vast standard library. So there are two issues, implementing a VM, and implementing the standard library. If you don’t need anything from the std. library and are happy with interpreted performance, you should be able to manage it.

  • elias
#8

Fortunately the Classpath project addresses that issue reasonably well.

Cas :slight_smile:

#9

Alien Flux + O.S. bytecode interpreter (I suppose there’s several already) + Classpath + (what was the name of that OpenGL-DX wrapper again?) on XBox anyone? :slight_smile:

#10

I’d use Jet to deploy on Xbox.

Cas :slight_smile:

#11

Creating an arbitrary virtual machine is a no brainer (ie easy), but like everybody else said, it won’t do much. Anything other than System.out.println() will be a pita.

#12

I was looking at the ORP page and there are some things that caught my atention:

Open Source

Uses GNU Classpath

Will compile with mingw or cyguns (obviously).

Already comes with a functional JIT

Im going to download this and see if i can compile it. Maybe the source is well organize enough to make some small changes.

The most important thing to me would be adding support for native computation of vectors and matrices and removing those nasty array bounds checks.

Being able to inline native assembler code would be very nice but i don’t know how this could be done without breaking compatibility with the java vm.

#13

I think this gets more attention than it deserves. In a number of important cases the HotSpot server can remove these checks safely (or at least hoist them out of loops). Even when they remain they aren’t as expensive as many people seem to think (and a lot less expensive than overrunning buffers as Microsoft can no doubt attest).

#14

I think Carmack complained about this when in his Java adventure. It may be more important with apps that use physics packages more intensively.

On another note i tried to compile the orp javavm and it didn’t work with mingw lol. Im going to try with cygnus windows later.

#15

Very likely. However I don’t think that just turning of the checks is the correct approach. It would be far preferable to improve the JIT’s ability to tell when the checks weren’t necessary. For example good Pascal compilers were able to eliminate more checks when the integer subrange types were used appropriately.
Could we add attributes to declarations in Java that made similar assertions. Then so long as the assertion was true the JIT could make more aggressive optimizations. If an assertion was found false then either an exception could be thrown, or the optimizations unwound and the application left to continue and fail in the normal manner when the bad value was used.
Also would it be reasonable for a JIT to take notice of assert statements even when they were ‘disabled’ — but of course only when the assert condition is helpful to the optimiser.

#16

Thats a nice idea using the asser clause to provide hints to the vm. It reminds me of a trick used on the new Pentiums where you can insert hint bytes on the machine code to tell the cpu a cycle will succed or fail most of the time.

It’s also very easy to extend this hint trick you mentioned without breacking compatibility. For example:


assert ("opt-hint: safe cycle" != null);

The assert would allways succed of course but the vm would detect this expression (or something similar) as an optimization jint and try to interpret it.

This stuff is very interesting. I wish i had more time to work on this stuff.

#17

Annotations would be better.

Cas :slight_smile: