Given by Zoran Budimlic at Java for CSE Meeting on Dec 16 1996. Foils prepared Jan 12 1997
Abstract * Foil Index for this file
Addon
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 |
This table of Contents
Abstract
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 |