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