On external_word_Relocation and StubCodeDesc
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)
>> I don't think it is always the case, e.g:
>> * many stubs are referenced as ExternalAddress (e.g. );
> It is table in C-heap and not a stub in codecache. It is not on
Yes, you are right.
>> * range_check  issues external addresses, but
>> SharedRuntime::gen_i2c_adapter passes in addresses within the code
>> cache .
> 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.:
> 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.
More information about the hotspot-compiler-dev