Re: Java on the Apple2 and C64

[ol.sc@web.de (Oliver Schmidt)]

Hi,

>>  Looking at the NanoVM 
>> implementation and having looked at the code cc65 generates, I'm 
>> actually amazed and impressed that it works so well.  I bet a hand tuned 
>> 6502 JVM implementation would be close in performance to the 6502 
>> p-machine.  Compiler differences would be interesting.  One would think 
>> compiler technology had advanced in 20 years and the advantage a Java 
>> compiler would have by running on *big iron* vs. a p-system based Pascal 
>> compiler should give the edge to Java.  An intriguing subject.
>
>I would be very surprised to see *any* high-level implementation of
>an interpreter get within a factor of two of the speed of a tuned
>assembly version--particularly if the interpretive operations are
>low semantic level, like "add 16-bit integer".

I don't think that Java byte code is large or "loose", in fact in my
opinion the opposite is true.

Writing a Java interpreter in 6502 assembly would most probably bring
Java close to the p-machine.

>The problem with compiling "all the way" is that it takes a lot more
>space than a compact bytecode.

That's the key! At work I was several years dealing with analyzing and
building Java VMs. The very advanced technology currently is Sun's
HotSpot VM. It's a great example of not compiling all code but mixing
interpretation and JIT compiling. Most people don't know that the
HotSpot VM even 'decompiles' code, which means it throws away compiled
native code and instead uses the interpreter again !

The major two benefits of this approach are:

1. Even with todays large memory areas memory consumption is still a
very important aspect: Because of the hierarchical memory systems -
There a Level 1 cache, a Level 2 cache, a Level 3 cache, the main RAM,
the memory paged to disk. The speed difference between CPUs and main
RAM became larger and larger in the recent years. Today memory
bandwidth is the primary limitation factor. So interpretation of very
compact byte code can be in fact faster than executing large native
code. The threshold depends on the workingset size (i.e. small tight
loop vs. jumping back and forth in large program). So a reason for
decompilation here could be that the code isn't executed often enough
anymore and therefore get's replaced by more "hot" code in the
'compiled code cache'. That cache intentionally doesn't jus grow to
keep it in a certain Level x hardware cache.

2. JIT (aka 'dynamic') compiling allows for quite some optimizations
not possible with Ahead-Of-Time (aka 'static') compiling. I.e. because
it's the default in Java most methods are virtual. But depending on
the currently loaded classes method calls often can only target a
single class thus can be handled as non-virtual. These type of
analysis (and many more) are done my the HotSpot compiler. So a reason
for decompilation here could be that the compiled code got wrong in
the meanwhile due to i.e. additionally loaded classes. In this context
it is obligatory that the VM can decompile code of methods being
actually executed ! In the case of the HotSpot VM that's true as well
for compilation: Just think of the "main loop" of some program. At the
time it becomes clear that it is "hot" enough to be compiled it
doesn't make sense to wait for the next time it's not executed. This
type of compilation/decompilation of running methods is btw called
'on-stack-replacement'.

Best, Oliver