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

>In contrast, the Java VM bytecode is simply a compact representation of
>the source, and loses little information that might be useful for
>optimization. [...]


Joe Hummel <jhummel@esp.ICS.UCI.EDU> wrote:
> 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.


Why can't it appear at the bytecode (or, rather, class file) level,
too? There's no current way to specify noalias for Java to either the
source or VM layer, but there's nothing that precludes it either. One
of the things the designers of the class file format did well is leave
room for extensions. In fact, the Java VM admits to extension better
than the language itself does, because ``Java Virtual Machine
implementations are required to silently ignore attributes they do not
recognize.'' [1]


For example, let's suppose some future Java compiler+vm vendor wanted
to add noalias. Inventing suitably awful syntax for it at the Java
source level, let's use a pragma:


    static void fastAsFortran(double a[], double b[], double c[])
        pragma noalias(a, b, c)
    {
        ... body ...
    }


Note that only this vendor's Java compiler will be able to deal with
such source; it's a syntax error for other compilers.


This vendor could also invent a corresponding attribute, potentially
included in a Code attribute, for the Java VM, hypothetically called
``NoAlias.'' A simple-minded format, using the notation from the
spec, would be something like:


    NoAlias_attribute {
        u2 attribute_name_index;
        u4 attribute_length;
        u2 number_of_variables;
        u2 variable_index_table[number_of_variables];
    }


which would indicate that the local variables or parameters at the
given indices would all refer to distinct objects.


Note that while initially only this vendor's native compiler (i.e.,
their virtual machine implementation) might do optimizations based on
the NoAlias attribute, the class files are usable with all Java VMs,
which must ignore the new attribute if they don't understand it.


(As an aside, I suspect a VM which trusted such an attribute without
verifying it with a dynamic check might create some concerns if one
were depending on Java's security model.)


[1] Tim Lindholm and Frank Yellin, _The Java Virtual Machine
Specification_, Addison Wesley, 1996. Section 4.7.1, page 107.
--

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