Is the JVM low level?

[Fare Rideau]

[Reply to pre-split lispos message]

>>: Paul Prescod
>: Dwight Hughes

>> People are talking as if the JVM is a "low level" VM. I don't see that.
It sure has a few "magic" high-level (I'd rather say bloated) operations,
but that doesn't make it high-level.
But might lead us to a discussion about what "high-level" means.
This is precisely the topic that I want to develop in part II
of my "Why a New OS" article. Not here.

>> What assembly languages do you know of that presume garbage collection?
Lisp Machine asm.
Just GC doesn't make you high-level.
Well, "High-level" has many meaning.
Might mean "costly to implement" or "simple to formalize" (and more things)
The JVM is high-level in the first meaning, not in the second.

>> What assembly language has an "invoke method" primitive?
I wouldn't call, say, ObjC, high-level just because
it has an invoke-method primitive.
Actually, in many aspects, even Lisp is low-level to me.


>> The JVM is actually pretty high level, in my opinion.
>> I would say that it is
>> sufficiently "low level" that it is not tied to a particular language as
>> a VM that just ran "Lisp code" would be (although the JVM is obviously
>> optimized for Java).
Turing tar-pit: with your arguments, I could say that
no Turing-equivalent VM is tied to any particular language!

> JVM is low-level because 90% or more of its byte codes are
> at the level of assembly language for a stack based processor.
Which sucks. I like stack architectures (see MISC),
but efficiently translating code from an abstract stack machine
to a hardware machine is a mess, all the more when real optimization
would involve word sizes, on-chip hardware stack depth limitation, etc.
[Of course, you could include hardware runtime check of stack overflow,
but this would completely defeat the very idea of MISC and the reason why
it's so small&cheap&fast].

Only by keeping VM code high-level, can you postpone all the optimizations
related to ((on-chip resource) allocation) and make the right choices.
Of course, precomputing an abstract high-level analysis of information flow
will greatly speed-up the back-end compilation;
extensive pre-analysis should only needed be for less than 5% of the code.


> And I'm not even getting to the security -
> which is built in at the same low level,
> taking another hit at overall performance on the JVM.
Yeah. Another, very important, reason, why low-level plain sucks,
is that security is a high-level concept not expressible at a low-level.
Note that paranoid checking is NOT security, only blind waste of time.
If our VM is to support any kind of real (as opposed to hype-oriented)
security, it must be high-level.

> A higher level VM would be far easier to extend
> to support new language features or just add  new languages.
Yup. Again, let's just have a compact representation of Lisp's sexps,
that is ADTs, perhaps annotated with optimization info,
as a portable binary code representation.


> Of course care would need to be exercised
> that we not get too high-level and basically wind up with tokenized Lisp.
Why not? We could even have the same binary format
to store compressed source and binaries;
only "binaries" would have been stripped, transformed and optimized,
whereas source would be richly annotated.

> The happy medium rules here.
The dynamic choice rules. By having a generic format,
we allow people to choose just the right kind of code transformation
they want for the code they distribute.
If you want heavily optimized code,
you can send the binary representation of assembly code
in a properly tagged vector (binary-code::i386 "\xe8\x04\x...."),
or even (binary-code::JVM "\x..."), or
(either (binary-code::i386 ....)
        (high-level-lisp-version))
If you want just source, keep your source. Etc.

Why have a stupid static bytecode,
when we can have an extensible dynamic framework?
Ain't "dynamism" the reason why we all love LISP, to begin with?


NB: Dwight, 96-char long lines are better than 110-char long lines.
Just a further effort, and make it 76-char long lines!

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"