On external_word_Relocation and StubCodeDesc

[Vladimir Ivanov]

On 2/16/16 12:17 AM, Dean Long wrote:
> How many unique external addresses do we typically have?  If we really
> want to conserve footprint, would it make sense to store them all in a
> table, and not just stub addresses?
As I mentioned, my quick experiment [1] demonstrated that most of the 
addresses are heavily used: there are 11 unique addresses used in 12k 
relocations. So, interning them in a table should work.

> However, aren't external_word relocations rare?  It may not be worth it
> to encode the address as an index, or even to encode a 64-bit address as
> something smaller using deltas.  Do you have any statistics on the
> effect of external_word relocations on footprint?
Well, I haven't done any extensive measurements, but I observe thousands 
(3k-12k) of external_word relocations on Octane benchmarks. Saving 
half-word on every relocation sums up to 12-46Kb savings in ideal case. 
But it is far from reality: (1) I track relocations across application 
lifetime, so their number should be much smaller at every moment in 
time; (2) actual savings can be levelled by alignment.

So, it doesn't look very attractive.

Best regards,
Vladimir Ivanov

[1] 5628 0x0000000102601396
       16 0x00000001027cba58
       20 0x00000001027cba60
       85 0x00000001027cc198
      110 0x00000001027d82a2
       55 0x00000001027ee720
      351 0x00000001027eea80
        9 0x0000000102814380
       41 0x00000001028143a0
        2 0x0000000103246460
     3812 0x0000000103246480

>
> dl
>
> On 2/15/2016 7:37 AM, Vladimir Ivanov wrote:
>> While working on JDK-8138922 [1], I noticed that
>> StubCodeDesc::desc_for is called for every external address embedded
>> in the code [2]. It is done to save some space on relocations (record
>> an index in the stub list instead of full address).
>>
>> StubCodeDesc::desc_for does linear search over the list and there are
>> around 100 stubs registered on x64.
>>
>> The problem is that the hit rate is very low. My experiments (on
>> Octane [3]) show that there are thousands of requests with 0% hit rate.
>>
>> So, instead of speeding up the search (switch to array, sort it and do
>> binary search to compute the index or lookup the address by index), I
>> suggest to completely remove that logic and always record the address
>> for external_word relocations.
>>
>> What's your take on that?
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> PS: there are some prospects in compacting some "well-known" addresses
>> [4], but it seems stubs aren't good candidates for that.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8138922
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-February/021702.html
>>
>>
>> [2] hotspot/src/share/vm/code/relocInfo.cpp:
>> void external_word_Relocation::pack_data_to(CodeSection* dest) {
>>   short* p = (short*) dest->locs_end();
>>   int32_t index = runtime_address_to_index(_target);
>>
>> where runtime_address_to_index looks for the _target among stubs
>> registered in StubCodeDescs::_list:
>>
>> int32_t Relocation::runtime_address_to_index(address runtime_address) {
>>   assert(!is_reloc_index((intptr_t)runtime_address), "must not look
>> like an index");
>>
>>   if (runtime_address == NULL)  return 0;
>>
>>   StubCodeDesc* p = StubCodeDesc::desc_for(runtime_address);
>>   if (p != NULL && p->begin() == runtime_address) {
>>     assert(is_reloc_index(p->index()), "there must not be too many
>> stubs");
>>     return (int32_t)p->index();
>>
>> [3] perf counters:
>> sun.ci.stubCodeDesc::total_reqs=11788
>> sun.ci.stubCodeDesc::total_reqs_hit=0
>>
>> sun.ci.stubCodeDesc::total_reqs=4117
>> sun.ci.stubCodeDesc::total_reqs_hit=0
>>
>> sun.ci.stubCodeDesc::total_reqs=3270
>> sun.ci.stubCodeDesc::total_reqs_hit=0
>>
>> sun.ci.stubCodeDesc::total_reqs=5183
>> sun.ci.stubCodeDesc::total_reqs_hit=0
>>
>> sun.ci.stubCodeDesc::total_reqs=7001
>> sun.ci.stubCodeDesc::total_reqs_hit=0
>>
>> sun.ci.stubCodeDesc::total_reqs=2909
>> sun.ci.stubCodeDesc::total_reqs_hit=0
>>
>> sun.ci.stubCodeDesc::total_reqs=10335
>> sun.ci.stubCodeDesc::total_reqs_hit=0
>>
>> sun.ci.stubCodeDesc::total_reqs=4698
>> sun.ci.stubCodeDesc::total_reqs_hit=0
>>
>> sun.ci.stubCodeDesc::total_reqs=5059
>> sun.ci.stubCodeDesc::total_reqs_hit=0
>>
>> sun.ci.stubCodeDesc::total_reqs=2763
>> sun.ci.stubCodeDesc::total_reqs_hit=0
>>
>> sun.ci.stubCodeDesc::total_reqs=3035
>> sun.ci.stubCodeDesc::total_reqs_hit=0
>>
>> sun.ci.stubCodeDesc::total_reqs=7244
>> sun.ci.stubCodeDesc::total_reqs_hit=0
>>
>> [4] Box2D external addresses stats:
>> 5628 0x0000000102601396
>>   16 0x00000001027cba58
>>   20 0x00000001027cba60
>>   85 0x00000001027cc198
>>  110 0x00000001027d82a2
>>   55 0x00000001027ee720
>>  351 0x00000001027eea80
>>    9 0x0000000102814380
>>   41 0x00000001028143a0
>>    2 0x0000000103246460
>> 3812 0x0000000103246480
>