Given by Zoran Budimlic at Java for CSE Meeting on Dec 16 1996. Foils prepared Jan 12 1997
Outside Index
Summary of Material
Based on Summer work by Zoran Budimlic at JavaSoft and Collaboration with Ken Kennedy |
Java bytecodes are at a higher level than ordinary assembly code |
Exceptions greatly reduce code movement opportunities |
OOP style (lots of method calls) reduces the data flow information available |
No knowledge about the whole program at compile time |
Standard trilema: functionality vs. portability vs. performance |
Adopt the current javac strategy: one class at a time, no changes to VM, lowest performance |
Or sacrifice some portability and functionality for better optimization |
Or sacrifice a lot of portability and functionality for best performance |
Outside Index Summary of Material
Zoran Budimlic |
Rice University |
Java bytecodes are at a higher level than ordinary assembly code |
exceptions greatly reduce code movement opportunities |
OOP style (lots of method calls) reduces the data flow information available |
no knowledge about the whole program at compile time |
standard trilema: functionality vs. portability vs. performance |
adopt the current javac strategy: one class at a time, no changes to VM, lowest performance |
sacrifice some portability and functionality for better optimization |
sacrifice a lot of portability and functionality for best performance |
based on summer work in JavaSoft |
standalone, cross-bytecode, one class at a time |
local and peephole optimizations
|
SSA construction |
simple SSA optimizations
|
requires no changes to VM |
insensitive to the choice of source compiler and interpreter/JIT compiler |
no interprocedural optimizations |
low performance gain |
space for some additional, though limited improvements |
Java doesn't have registers |
local variables are not the same:
|
operand stack should be used to shorten the bytecode sequence
|
interprocedural optimizations of the part of the program that is available |
make some assumptions about the code at a compile time, pass the information about it to the run-time |
OOP Style
|
inheritance
|
limited analysis
|
inlining has to preserve field privacy |
simple idea: inline both methods and data |
we can only inline objects that we instantiated
|
preliminary experiments (Linpack by hand) give ~2 times speed increase, with 20-30% code size increase |
compile and optimize classes assuming static intraclass calls |
have two versions of each class, one for instantiation, one for inheritance |
requires the run-time environment to know about this and have appropriate behavior |
duplicates the code size |
wait until the whole program is available at the client's side |
perform the full range of heavy-duty optimizations, generate native code |
high performance, loss of portability |
ongoing research ("classical" optimizations, Jeff Dean's thesis) |
many Java instructions can cause an exception |
exact exception model |
no appropriate model for methods with exception handlers yet |
greatly reduces code movement opportunities |
determine instructions that will not cause exceptions
|
enclose the whole method code in a try
|
some portability and functionality has to be sacrificed for high performance |
within factor 2 of native C expected for Web based programs |
with native-code, whole program optimizing Java compiler, very limited use of exceptions in user programs, we should expect getting very close to native C performance |
Java is becoming the language of choice in many applications, from WWW to scientific code |
it has many appealing features |
unfortunately, it is very hard to optimize |
fortunately, it is very hard to optimize, so I can get my thesis out of it |