On external_word_Relocation and StubCodeDesc

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Tue Feb 16 18:40:11 UTC 2016


>>> Also stub's address should not be external since stubs are located in
>>> CodeCache. External addresses are used for runtime (or C-heap)
>>> addresses.
>> I don't think it is always the case, e.g:
>>    * many stubs are referenced as ExternalAddress (e.g. [1]);
> It is table in C-heap and not a stub in codecache. It is not on
> StubCodeDesc::_list.
Yes, you are right.

>>    * range_check [2] issues external addresses, but
>> SharedRuntime::gen_i2c_adapter passes in addresses within the code
>> cache [3].
> First, I think it is mistake to use ExternalAddress in range_check.
Do you think we should fix that?

There are other places, e.g.:

   * src/cpu/x86/vm/templateTable_x86.cpp

   * src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp
     __ jump(ExternalAddress(Interpreter::throw_exception_entry()));

> And second none of those addresses are present in StubCodeDesc::_list.
For the following case:
  range_check(masm, rax, r11,

StubRoutines::code1()->code_begin() == entry point for 

So, the first address is replaced with the index. But it's definitely 
not important from footprint POV.

FTR the data I provided on hit rates was gathered with product binaries.

> I think your experiment with hit rate is confirmation that
> StubCodeDesc::desc_for() will find nothing when called from
> external_word_Relocation::pack_data_to(). May be we should path flag as
> parameter to avoid calling StubCodeDesc::desc_for() in such case.
I'm inclined to completely remove Relocation::runtime_address_to_index. 
I'll prepare a webrev and send it out for review.

Best regards,
Vladimir Ivanov

More information about the hotspot-compiler-dev mailing list