hg: jdk7/tl/langtools: 6917130: should test that annotations that have been optimized away are not emitted to classfile

Mahmood Ali mahmood at notnoop.com
Wed Jan 27 07:32:53 PST 2010

Greetings Neal,

> Note that this is testing for "optional" behavior, which is a
> quality-of-implementation issue and not a correctness issue.

> The javac regression suite has been very helpful to me in finding
> bugs in other compilers that were not caught by those other suites.

I think I understand your position here.  I think that even
quality-of-implementation is useful for other compilers, especially as
the JSR 308 specification is vague in this case.

There are two possible concerns here:
1. The test assumes that javac optimizes dead-code away, so the test
verifies that the annotations were optimized away as well.  A more
proper test would be to actually check if the dead-code was optimized
away, and then check for the presence of annotations.  This makes the
test a bit more robust and more portable to other compilers as well.
When we get around to writing a testing utility for method bodies and
their annotation info, the test will definitely be updated (or more
tests will be added).

2. That the JSR 308 is vague, and allows for annotations to exist,
even as the dead code is optimized away, as it states "If the compiler
optimizes away an expression, then it may also optimize away the
annotation" [JSR 308, S 3].  However, in reality that given that the
spec doesn't specify what the possible annotation description
(reference_info) values in this case, a compiler that optimizes away
deadcode without annotations will most likely generate unexpected
classfile that would break classfile analyzers.  A compiler failing
this test (after it is updated) should seriously be updated to be more
standard compliant.

Do you agree with my analysis?  Would updating the test to check for
deadcode elimination mitigate your concerns?


More information about the compiler-dev mailing list