Re: Why Virtual Machines? (was: C++ -> Java VM compiler)

Joe Hummel <jhummel@esp.ICS.UCI.EDU>
30 Jan 1997 22:27:17 -0500

          From comp.compilers

Related articles
Why Virtual Machines? (was: C++ -> Java VM compiler) p.froehlich@link-m.de (1997-01-25)
Re: Why Virtual Machines? (was: C++ -> Java VM compiler) robison@kai.com (Arch Robison) (1997-01-29)
Re: Why Virtual Machines? (was: C++ -> Java VM compiler) albaugh@agames.com (1997-01-29)
Re: Why Virtual Machines? (was: C++ -> Java VM compiler) jhummel@esp.ICS.UCI.EDU (Joe Hummel) (1997-01-30)
Re: Why Virtual Machines? (was: C++ -> Java VM compiler) haahr@netcom.com (1997-02-02)
Re: Why Virtual Machines? (was: C++ -> Java VM compiler) nr@adder.cs.virginia.edu (Norman Ramsey) (1997-02-02)
Re: Why Virtual Machines? (was: C++ -> Java VM compiler) Bronikov@srv2.ic.net (Dmitri Bronnikov) (1997-02-02)
Re: Why Virtual Machines? (was: C++ -> Java VM compiler) apalanis@students.uwf.edu (1997-02-03)
Re: Why Virtual Machines? (was: C++ -> Java VM compiler) robison@kai.com (Arch Robison) (1997-02-03)
Re: Why Virtual Machines? (was: C++ -> Java VM compiler) bothner@cygnus.com (1997-02-07)
[4 later articles]
| List of all articles for this month |
From: Joe Hummel <jhummel@esp.ICS.UCI.EDU>
Newsgroups: comp.compilers
Date: 30 Jan 1997 22:27:17 -0500
Organization: Compilers Central
Keywords: Java, architecture

>In contrast, the Java VM bytecode is simply a compact representation of
>the source, and loses little information that might be useful for
>optimization. (I would argue no useful information is lost, but one
>person's information that is "useful for optimization" is another
>persons "unnecessary crutch" or even "nuisance to maintain".)


I would agree that little info is lost, but it's very hard to say no
info is lost. Sure, the info may be there, but how expensive is it to
recompute? For example, after a fair amount of bytecode optimization,
how easy is it to recompute the original intent of the source program?
Perhaps multidimensional array accesses get optimized into more
complicated accesses of a 1D array, to the point that the index
expressions are no longer analyzable? (sp?)


I do claim to have one example of info loss: eventually, Java
compilers will support compiler options such as -noalias, which assert
to the compiler that arguments to methods will not be aliased. This
is very useful optimization info that would now be available at the
source-level, but would not appear in the bytecodes and thus could not
be reconstructed no matter how hard you try.


I'm interested in other examples of info loss if they exist...
Cheers,


    - joe hummel
        UC-Irvine
--


Post a followup to this message

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