checkcast elimination

[David Holmes - Sun Microsystems]

But in this case I think Tom D. is hoping for something the other way 
around. As bar takes an Object and whatever comes back from get(i) is an 
Object then there's no need to check if it is a myClass. In short the 
code could be treated as:

bar(aList.get(i));

and the type of the actual object is immaterial. Now javac won't do this 
itself, but could the JIT?

Cheers,
David Holmes

Tom Rodriguez said the following on 01/15/09 08:08:
> It's never ok to elide work that throws an exception unless you can 
> prove that it won't occur.  The general rule for optimization in hotspot 
> is that the JVM can do anything it wants as long as you can't write a 
> program that can detect the difference, other than performance or 
> limits.  In the case below a very clever JVM might able prove that only 
> myClass'es were ever inserted into aList but because generics are based 
> on type erasure we can't assume it's true.
> 
> tom
> 
> On Jan 14, 2009, at 12:25 PM, Deneau, Tom wrote:
> 
>> In the following method foo, an entry is being pulled from a Collection
>> class, in this case an ArrayList, and then being passed to another
>> method which takes an Object.  The programmer stores the ArrayList
>> return in a myClass reference but never really uses it as a myClass
>> object.  The javac compiler generates a "checkcast" bytecode and the
>> HotSpot JVM generates code for the checkcast.
>>
>> Question: is it legal for the JVM to eliminate this cast check or is the
>> semantics of this code such that the JVM is required to generate an
>> exception if the cast fails (even though the reference is never really
>> used as a myClass) ?
>>
>> -- Tom
>>
>> =================
>>     ArrayList<myClass> aList;
>>
>>     void foo(int i) {
>>         myClass myc = aList.get(i);
>>         bar(myc);
>>     }
>>
>>     void bar(Object x) {
>>      ...
>>      }
>>
>