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
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.