Re: JVM as UNCOL, was ANDF/TDF

vbdis@aol.com (VBDis)
13 Oct 2001 23:12:21 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: JVM as UNCOL, was ANDF/TDF joachim_d@gmx.de (Joachim Durchholz) (2001-10-12)
Re: JVM as UNCOL, was ANDF/TDF asunil@csa.iisc.ernet.in (Sunil Kumar Anand) (2001-10-12)
Re: JVM as UNCOL, was ANDF/TDF jesper@zuschlag.dk (Jesper Zuschlag) (2001-10-13)
Re: JVM as UNCOL, was ANDF/TDF jesper@zuschlag.dk (Jesper Zuschlag) (2001-10-13)
Re: JVM as UNCOL, was ANDF/TDF David.Chase@naturalbridge.com (David Chase) (2001-10-13)
Re: JVM as UNCOL, was ANDF/TDF joachim_d@gmx.de (Joachim Durchholz) (2001-10-13)
Re: JVM as UNCOL, was ANDF/TDF vbdis@aol.com (2001-10-13)
Re: JVM as UNCOL, was ANDF/TDF fjh@cs.mu.OZ.AU (2001-10-16)
Re: JVM as UNCOL, was ANDF/TDF fjh@cs.mu.OZ.AU (2001-10-16)
Re: JVM as UNCOL, was ANDF/TDF joachim_d@gmx.de (Joachim Durchholz) (2001-10-20)
Re: JVM as UNCOL, was ANDF/TDF vbdis@aol.com (2001-10-20)
Re: JVM as UNCOL, was ANDF/TDF lex@cc.gatech.edu (Lex Spoon) (2001-10-20)
Re: JVM as UNCOL, was ANDF/TDF chase@world.std.com (David Chase) (2001-10-23)
[2 later articles]
| List of all articles for this month |

From: vbdis@aol.com (VBDis)
Newsgroups: comp.compilers
Date: 13 Oct 2001 23:12:21 -0400
Organization: AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com
References: 01-10-051
Keywords: Java
Posted-Date: 13 Oct 2001 23:12:21 EDT

Sunil Kumar Anand <asunil@csa.iisc.ernet.in> schreibt:


>Interesting research area is how best we can exploit the instruction
>set to optimize the code generated by JIT compiler.


IMO this question should read: what is the best combination of
instructions, so that the JITter will be able to recognize our intents
and optimize the code accordingly.


A JITter cannot optimize the code by anything but a peephole
optimizer. Everything else, like loop optimization and common
subexpression elimination, must be done by the primary compiler.


I even doubt that a JITter will recognize and optimize e.g. pre- or
post-increment operations, unless there exists a fixed instruction
pattern for such operations, which is hard coded in the JITter's
recognizer. Some machines have auto-increment/decrement addressing
modes, other (Intel) machines require multiple instructions for the
same task. So the question morphs again, into: what code patterns does
the (which???) JITter recognize? In the next step we'll have to
consider how some code will execute, when optimized for machine and
JITter A, when run on machine B? :-(


Perhaps the MSIL .ann instructions should be converted into the most
important instructions at all, which can tell the JITter directly,
what the purpose of a sequence of instructions really is, or which
language-specific sequences of instructions should be recognized by
the code optimizer?


>>Also how good will the performance of this MSIL when compared to Java
bytecode is still not known.<<


Here I also doubt that we ever get such figures. I remember graphics
benchmarks, which were written to favour a specific (Texas) graphics
card. With benchmarks we only can expect, that all JITters are
optimized to fit the needs of exactly these benchmarks, possibly at
the cost of more practical pieces of code.


DoDi


Post a followup to this message

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