On external_word_Relocation and StubCodeDesc

[Vladimir Ivanov]

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