Re: Thoughts on the JVM as a compilation Target?

On 5/22/2012 12:33 PM, Aaron W. Hsu wrote:
> Hey folks:
>
> What are your thoughts on JVM as a compilation target, especially with new
> languages all targeting high performance or multi-core type features?


it likely depends on the language.


Java-like languages can be targeted to the JVM fairly well (especially
if they have less features than Java, or are basically just "Java with
certain syntactic differences" or similar).


some high-level scripting languages can passably compiled to the JVM,
and some newer VM features (such as "invokedynamic") allow making this a
little more efficient (more on-par performance-wise with natively
compiled versions of the VMs).




for much else, the JVM's architecture may be seriously deficient in some
areas, and trying to target code to it is likely to be a major pain (vs,
say, targeting C, or targeting x86 or x86-64 ASM). (consider, for
example, the pain of trying to compile something like C or C++ to the JVM).




this is partly due to the level of abstraction:
in some ways, it is too high-level, offering only a narrowly defined set
of abstractions, which have to be crufted around to build new features
(features need to be built using classes, interfaces, and method calls).


in other ways, it is too low-level, offering no way to work around
arbitrary limitations in the type-system or scoping-model apart from
falling back to high-level mechanisms (such as method calls or
reflection, ...).


some other cases are due to arbitrary limitations, many related to
design choices made in the Java language (such as the lack of
package-scoped functions or variables, lack of either first-class
methods or a way to refer to methods indirectly, ...).


yes, the JVM does have some fairly elaborate optimizations, but when
they are mostly being used to try to optimize around cruft introduced in
trying to fit the language onto the VM, this is not nearly so good.




a lot of these issues could be addressed (and some are apparently being
addressed), but Oracle is very slow-moving about it.




I am feeling rather uncertain as to getting more specific about things I
would change to the JVM architecture if given the choice, as some people
are likely to get rather defensive (note: most were related to the class
file-format and bytecode, note that likely even if a new class-format
and bytecode were introduced, it need not break backwards compatibility).


most changes in general would be related to increasing generality and
orthogonality, and likely introducing more of a "middle layer" regarding
bytecode abstraction.






personally though (at least for now), I would just assume targeting
native code (or maybe targeting C, if writing a static compiler).


in my case, my front-ends tend to compile into bytecode-based formats,
which are then either interpreted, or could be fed through a JIT or
similar. as is, my mainly-used bytecode VM currently uses an interpreter
which converts the bytecode into threaded code and then runs the program
as threaded code.


sadly, this bytecode is itself far from perfect: lots of stale
instructions, non-optimal organization, operation types are typically
encoded as prefixes, ...

Return to the comp.compilers page.
Search the comp.compilers archives again.