[JSR308] Resolution of optimization issue

[Neal Gafter]

I am more concerned with annotations in places that don't directly
correspond to instruction locations in the byte code for one reason or
another. Examples include annotations in dead code ("if (false) ..."), or
annotations on types used as qualifiers. It doesn't make sense for a
specification to require that these annotations be "preserved" without
providing a place for them to be preserved to.

To put my concern another way, instead of making the informal statement that
a compiler is required to preserve annotations (to where?), the
specification should provide an extension of the reflective and mirror APIs
for accessing annotations that have class file and runtime retention, and
require that these APIs "work" for annotations appearing in the source
language. That is a more precise and testable requirement. To implement the
requirement we will necessarily have to specify formats for storing the
annotations as well.

This is a general example of designing the language top-down rather than
bottom-up. We start with our goals. Then we specify a syntax and semantics
that satisfies those goals. Then we specify the technical details that are
required to implement the syntax and semantics. I feel we've skipped the
second step.

Regards,
Neal

On Jun 4, 2007 10:04 AM, Michael Ernst <mernst at csail.mit.edu> wrote:
>
> I had asked whether optimizations by Java-to-bytecode compilers that might
> interfere with retaining, in the class file, all annotations that appear
> in
> the source code.  No one came up with any examples, so I plan to add the
> following text to the JSR 308 working document.
>
>  If a programmer places an annotation (with class file or runtime
>  retention) on the type of a value, then the compiler is required to
>  preserve that annotation in the compiled class file.  This restriction is
>  unobjectionable for several reasons.
>
>  First, Java-to-bytecode compilers rarely perform sophisticated
>  optimizations, since the bytecode-to-native (JIT) compiler is the major
>  determinant in Java program performance.
>
>  Second, it seems unlikely that two identical, non-trivial expressions
>  would be differently annotated.
>
>  Third, the compiler workarounds are simple.  Suppose that a compiler
>  performs common subexpression elimination on two expressions that are
>  identical except for their type annotations.  Three implementation
>  strategies are for the compiler to not perform the optimization when the
>  annotations differ, to create a single expression with both of the
>  annotations, or to create an unannotated expression and copy its value
>  into two variables with differently-annotated types.
>
>                    -Mike
>
> _______________________________________________
> JSR308 mailing list
> JSR308 at lists.csail.mit.edu
> https://lists.csail.mit.edu/mailman/listinfo/jsr308
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308/attachments/20070604/1525f5d0/attachment.htm