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

[Roland Westrelin]

> I'd add comment to the following change:
> !         callee->holder() == env()->Object_klass()) {
> !         callee->holder() == env()->Object_klass() &&
> +         callee->name() != ciSymbol::finalize_method_name()) {
> 
> Otherwise, looks good.

Thanks for the review. I will add a comment before I push this.

Roland.

> 
> Best regards,
> Vladimir Ivanov
> 
> On 7/2/14 12:53 PM, Roland Westrelin wrote:
>>> 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.
>>>> 
>>> 
>>