RFR(S): 8046542: [I.finalize() calls from methods compiled by C1 do not cause IllegalAccessError on Sparc
igor.veresov at oracle.com
Fri Jun 20 18:41:49 UTC 2014
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?
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.
More information about the hotspot-compiler-dev