JVM misconceptions (Re: [Mono-list] Re: can you explain what you mean?)

[Tom]

Thanks, Jeffery, for digging up the URL; I had just
been going by the printed information (yes, there 
still is some information in books and on paper :-).

> This is, however, all written from the perspective
> of the verifier, so
> it isn't obvious what restrictions this puts on the
> code generator.

I don't see any significant difference between the
verifier conditions for the JVM and the relevant
sections of the ECMA CIL standard (section 1.8 and
the "verifiability" headings under individual
instructions). Even the terminology is very
similar. If you know of any differences, can you
point them out?

It has been my experience that if you write a reverse
translator for Java, or a JIT compiler, you'll find
that the verifiability conditions make it particularly
easy to do so (the kind of property Miguel was after),
although it should be pointed out that even
non-verifiable code can be compiled efficiently using
other techniques.

Note that neither the JVM nor the CLI can be
considered merely postfix representations of the parse
tree. That is because both replace structured control
structures with branches. This leads to the need for
slightly more complex dataflow analysis than might
otherwise be necessary. The CLI shares this
(mis-)feature with the JVM.  I think it also differs 
from some of the research papers that Microsoft cites 
when talking about CLR.  But we are talking
trivial vs. simple here.

Altogether, I still don't see any fundamental
difference between the JVM bytecodes and the CLI
bytecodes. CLI has a few more useful instructions,
that's all. If true, there are some implications:

-- Don't expect a fast CLR to be easier to
implement than a fast JVM/JIT; in fact, it's likely
to be harder because of some tricky additional
functionality in the CLR (structures, references,
etc.).

-- Don't dismiss Java completely; it might be worth
aiming for a dual CLR/JVM and/or doing a lot more
of the Mono project in Java than anticipated
right now.

-- A JVM/JIT may be a better starting point for
a CLR implementation than the current thinking
seems to be (this is likely what Microsoft did).
Of course, all of the open source JVM/JIT
compilers do need a significant amount of work
(Kaffe, Intel Open Runtime, OpenJIT, etc.).

On the other hand, if people really feel up to
implementing a high-performance CLR from scratch,
that's great: it would be useful both for its own
sake, and, as far as I can tell, it could also
easily be turned into a high-performance JVM/JIT,
serving both communities and providing
interoperability.

Tom.





__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/