RFR [S] 8030076:remove unused runtime related code

[Coleen Phillimore]

Bertrand,

This cleanup looks good.  One less inscrutable bit of code for 
deoptimization (I think it was).

Doing archeology, I don't see how the handle_ic_miss() call forced 
initialization that would have called Jvmti code.  It looks like an 
accessor in the old code also.   For what it's worth, there were test 
cases in 6236259 that might still be valid.

Thanks
Coleen


On 6/12/15 10:31 AM, Bertrand Delsart wrote:
> Hi all,
>
> Simple review for some dead code elimination
>
> https://bugs.openjdk.java.net/browse/JDK-8030076
>
> http://cr.openjdk.java.net/~bdelsart/8030076/webrev.00/webrev/
>
> The unused removed methods are:
>  frame::interpreter_frame_equals_unpacked_fp
>  (uselessly implemented on most platforms)
>  MacroAssembler::throw_WrongMethodType_entry
>
> The only non trivial change is the removal of an obsolete comment and 
> assert in hotspot/src/share/vm/runtime/sharedRuntime.cpp :
>
> -  // Get the address of the ic_miss handlers before we grab the
> -  // AdapterHandlerLibrary_lock. This fixes bug 6236259 which
> -  // was caused by the initialization of the stubs happening
> -  // while we held the lock and then notifying jvmti while
> -  // holding it. This just forces the initialization to be a little
> -  // earlier.
> -  address ic_miss = SharedRuntime::get_ic_miss_stub();
> -  assert(ic_miss != NULL, "must have handler");
>
> First the comment is misleading since the call to get_ic_miss_stub (no 
> longer) fixes anything. It is simple read accessor.
>
> If the ic_miss_stub has not yet been generated, the accessor itself 
> contains an assert that will fire if we really need the ic_miss_stub. 
> Hence, the above assert is no longer useful... and we removed it 
> because it did lead to issues with one of our closed extension, which 
> avoided to uselessly generate the ic_miss_handler.
>
> Regards,
>
> Bertrand.
>