[JSR308] Resolution of optimization issue

[Michael Ernst]

Neal-

Thanks for your message.  And, thanks to everyone who made helpful
comments, either on the mailing list or in private email, to improve the
document.  I have attached another draft below.


I agree with some of your points.

> annotations in dead code [need not be preserved]

Good point.  I have amended the text accordingly.

> the specification should provide an extension of the reflective ... API

Agreed, assuming that extension is for publicly-visible locations like type
parameters and the receiver.  This has been in the to-do list for some
time.  Repeating a known to-do item adds no new information.  Unless are
volunteering to write this, of course!

> we will necessarily have to specify formats for storing the
> annotations as well.

Agreed.  But this is already specified in the design document at
http://pag.csail.mit.edu/jsr308/, so there's no need to raise it as a to-do
item.  Are you volunteering to translate it into the format used in the
JVMS, or make other needed adjustments?  That would be welcome.


I disagree with some other points, however.

> 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.

There are at least three problems here, from my point of view.

1. Choosing between high-level intuition and low-level details is a false
dichotomy.  Both are required.  Ignoring the first is an easy mistake to
make, but it yields an unreadable specification that is very hard for a
human to appreciate, evaluate, or verify.  I would like to have both, but
it makes sense to start with the high-level one.

Not everything can get done simultaneously or instantly -- that's why there
is a to-do list!  Feel free to pitch in, and we will finish faster.

2. Contrary to your suggestion, the mirror API should not be updated.  Joe
Darcy's blog posting, "So you want to change the Java Programming
Language..."  (http://blogs.sun.com/darcy/entry/so_you_want_to_change),
states:

  The com.sun.mirror.* API has been superseded by JSR 269 as of JDK 6 and
  will not be updated for any JDK 7 or later language changes.

3. Your testing suggestion doesn't address the issue I raised.  My message
was about compiler optimizations, such as common subexpression elimination.
Your suggestion of requiring that the reflective APIs "work" (in some
yet-to-be-defined sense; would you like to formalize it?) is good for other
reasons, as I noted above.  However, it is not effective for testing
compiler optimizations or many other aspects of code generation, because
the reflective APIs provide no access method bodies, only to the public
elements of a class.

                    -Mike


Here is another draft of the design document section on compiler
optimizations.

  The compiler is required to preserve annotations in the class file.  More
  precisely, if a programmer places an annotation (with class file or runtime
  retention) on the type of an expression, then the annotation must be
  present, in the compiled class file, on the type of the compiled
  representation of that expression.  This may change the compiler
  implementation of certain optimizations, such as common subexpression
  elimination, but this restriction on the compiler implementation is
  unobjectionable for three 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.  Thus, the restriction will not
  affect most compilers.

  Second, the compiler workarounds are simple.  Suppose that two expressions
  that are candidates for common subexpression elimination have different
  type annotations.  A compiler could:  not perform the optimization when the
  annotations differ; create a single expression whose type has both of the
  annotations; or create an unannotated expression and copy its value into
  two variables with differently-annotated types.

  Third, it seems unlikely that two identical, non-trivial expressions would
  have differently-annotated types.  Thus, any compiler restrictions will
  have little or no effect on most compiled programs.