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