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

Igor Veresov igor.veresov at oracle.com
Wed Jul 2 19:11:29 UTC 2014


Roland,

Thanks for the comments. It looks good.

igor

On Jul 2, 2014, at 1:53 AM, Roland Westrelin <roland.westrelin at oracle.com> 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.
>>> 
>> 
> 



More information about the hotspot-compiler-dev mailing list