On external_word_Relocation and StubCodeDesc
Vladimir Ivanov
vladimir.x.ivanov at oracle.com
Tue Feb 16 18:40:11 UTC 2016
Vladimir,
>>> 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
ExternalAddress(Interpreter::_throw_ArithmeticException_entry));
* src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp
__ jump(ExternalAddress(Interpreter::throw_exception_entry()));
__
jump(ExternalAddress(StubRoutines::throw_StackOverflowError_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(),
StubRoutines::code1()->code_end(),
L_ok);
StubRoutines::code1()->code_begin() == entry point for
StubRoutines::forward_exception.
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