Re: Java compiler optimizations?

>"Ian L. Kaplan" wrote:
>> For a given class of compiler, I suspect that there is no difference
>> between Java optimization and C++ optimization, for example.


Eliot Miranda <eliotm@pacbell.net> wrote, in reply:
>IMO, this is very far from the truth. But it is not the source to
>bytecode compiler that typically does "exotic" optimizations.
>Instead, there are Just-In-Time Java, Self and Smalltalk bytecode to
>native code "compilers" that perform optimizations not seen in static
>C++ compilers. These are virtual machines that include optimizing
>compilers used at run-time. The basic strategy is for the JIT to
>quickly generate unoptimized code that includes profiling facilities.
>Based on profiles the JIT then aggressively optimizes code that is
>found to be long running via profiling. Visit the Self compiler pages
>at Sun (http://www.sun.com/research/self/). See proceedings of
>SIGPLAN PLDI over the past 5 years, especially on Java virtual
>machines. See the Proceedings of the ACM SIGPLAN Workshop on Dynamic
>and Adaptive Compilation and Optimization (Dynamo '00). January 18,
>2000, Boston, Massachusetts, a.k.a. SIGPLAN vol. 35, no 7.
>--


    The point another poster made about optimizing range checks and null
    pointer references is a valid difference between C++ optimization
    and Java optimization. The issue of optimization in the presence of
    threads is another important difference and a big challenge in
    Java compilation.


    But trace or profile driven optimization is hardly new. In fact
    this is an active area for IA64 optimization as well. Many of the
    techniques that were used on systems like the Multiflow super-
    computer (almost twenty years ago) are now being applied in IA64
    compilers.


    JIT optimization is probably different from normal compiler
    optimization since the JIT has to be designed with performance in
    mind. Some algorithms may be considered too time consuming. I
    think that you'll find that the "agressive optimization" that JIT
    native compilers apply is classical optimization.


    I consider the applications that can benifit from JIT compilation a
    fraction of those that could benifit from Java. Not all
    applications are long running servers. The issue of JIT compilation
    to native code is a side issue in this discussion. This is not what
    I understood the topic to be. The issue that I was trying to
    address was Java optimization, especially in the context of static
    compilation.


    Optimization in the presence of exceptions (e.g., how should control
    flow graphs be built in the presence of exceptions) is an important
    issue shared by both Java and C++. This, and the issue mentioned
    above with threads, is a complex problem. Unlike classical
    optimization which is well covered in books like Robert Morgan's
    "Building an Optimizing Compiler", optimization in the presence of
    exceptions and threads is harder to find material on. Most compiler
    groups seem to solve these problems a new every time. Since they
    are working on commercial products, there is less material in print.


    Java is a complex language compared to C, but it is far simpler than
    C++. I have been a heavy user of C++ for many years and I still
    find the complexity of the language staggering. The compiler
    support needed for C++'s object model and features like operator
    overloading is subtle. Then there are templates, etc...


    Java provides an interesting model for modern optimization since it
    is simpler than C++ but still preserves much of C++'s power.


    I find it sad that the Java language definition remains in control
    of Sun, rather than an open committee (and I don't think that the
    "community process" is really an open committee, since Sun has final
    veto and control of the pace at which Java changes). It will be
    interesting to see what effect Microsoft's C# has. This language
    is, more or less, Java. As I understand it, Microsoft has submitted
    the language to a standards committee. From what I have seen of C#
    there is no bias or prohibition against static compilation. In
    fact, from what I have seen, C# does not include features that make
    static compilation impossible.


    Ian Kaplan
    iank@bearcave.com

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