RFR(S): 8046542: [I.finalize() calls from methods compiled by C1 do not cause IllegalAccessError on Sparc

[Roland Westrelin]

> It seems reasonable. Could you please add a comment similar to your explanation below to the resolve_vtable_index() call and the optimize_virtual_call() ones?

Thanks for the review, Igor.

What about these comments?
http://cr.openjdk.java.net/~roland/8046542/webrev.01/

Roland.

> 
> igor
> 
> On Jun 18, 2014, at 6:13 AM, Roland Westrelin <roland.westrelin at oracle.com> wrote:
> 
>> The bug occurs with UseInlineCaches off (default on ultra sparc T machines). The calls are then compiled to vtable calls rather than ic calls. The logic that does the call resolution in c1 allows the call to finalize() with a receiver of type array in vtable calls. It shouldn’t. In the current code, the vtable index lookup is done on the Object type obtained from the array type by a call to ciEnv::get_instance_klass_for_declared_method_holder() which is why the finalize() call is allowed to proceed. The fix I propose uses the initial type for the vtable index lookup. As a consequence a small subset of methods (at least Object.clone()) called on arrays won’t be compiled as vtable calls but as ic calls which I think is a minor issue.
>> 
>> A similar problem exists with c2: it allows inlining of the finalize() call on an array. I changed Compile::optimize_inlining() so that the finalize method is filtered out. With this bug fix, the same problem with vtable calls to finalize() exist so I applied the fix I used for c1 to c2.
>> 
>> http://cr.openjdk.java.net/~roland/8046542/webrev.00/
>> 
>> Roland.
>> 
>