RFR 8029567: Clean up linkResolver code

Jiangli Zhou jiangli.zhou at oracle.com
Thu May 28 02:59:46 UTC 2015


Hi Coleen, 

On May 27, 2015, at 12:26 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:

> 
>> 
>> Bytecode_invoke::static_target(), bytecode.cpp:
>> Bytecode_invoke::static_target() originally returns a null handle instead of ‘NULL’ if the method is not resolved. Now that’s changed, however caller of Bytecode_invoke::static_target() still expects null handle instead of ’NULL’.
>> 
>> LinkResolver::lookup_method_in_klasses(), linkResolver.cpp:
>> Same as Bytecode_invoke::static_target(). This now might return ‘NULL’ instead of null handle.
>> 
> https://bugs.openjdk.java.net/browse/JDK-8066624
> 
> This code for CHECK_(nullHandle) is my fault because of an experiment I was doing years ago by disallowing the default conversion from oop to Handle.  The experiment was because when converting to a Handle, the function Thread::current() was being called implicitly when in most cases THREAD is available and showed up in somebody's profiling data.
> 
> Because the conversion from NULL to any Handle does not call Thread::current() and it's allowed, I think CHECK_NULL looks a lot better in the code than CHECK_(methodHandle()).
> 
> I changed the code to this though:
> 
> methodHandle Bytecode_invoke::static_target(TRAPS) {
>   constantPoolHandle constants(THREAD, this->constants());
>                                                   
>   Bytecodes::Code bc = invoke_code();
>   return LinkResolver::resolve_method_statically(bc, constants, index(), THREAD);
> } 
> 
> Because CHECK_NULL in a return statement does something bad that I can't remember.

Thank you for the explanation.

Thanks,
Jiangli





More information about the hotspot-runtime-dev mailing list