RFR: 8333819: Move embedded external addresses from relocation info into separate global table

[Vladimir Kozlov]

On Thu, 13 Jun 2024 21:24:26 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Currently we have oops and metadata in nmethod's local data sections which are referenced by index from relocation info.
>> On other hand external addresses (declared with `ExternalAddress` in assembler code) are embedded into relocation info data because they don't need to be patched during normal execution.
>> 
>> But based on my experiments we usually use the same external addresses in generated code.  JavacBanch runs with product VM show about 4000 C1 and C2 compiled nmethods reference only 11 external addresses during execution. Which means these addresses are duplicated in a lot of relocation info data.
>> 
>> There is also issue with embedded addresses in relocation info in Leyden project. Because these VM external addresses can change between runs we have to update/patch them when we load cached code and its relocation info.  But because addresses are packed (compressed) the number of bytes used for it in relocation info may be not enough to pack new address. So we have to throw out such cached code.
>> 
>> I suggest to move external addresses from  relocation info into separate global table and use indexes to access it.
>> It is similar to what we do for oops and metadata addresses so I used similar to OopRecorder but simplified mechanism.
>> The results show that relocation info is reduced by 10% in product VM and by 32% in debug vm (which shared 145 external addresses). Which is few % reduction in nmethod size - more compact CodeCache.
>> 
>> This should not affect generated code performance but only slightly compilation time (I need to use lock to access table) because we only modify how `external_data_relocation` is processed.
>> 
>> Tested tier1-5,stress,xcomp
>> Performance testing.
>
> It might make sense to use ExternalsRecorder for runtime_call_w_cp_type as well.

Thank you, @dean-long 

> Looks good. However, I suspect that all the external addresses are known early, at ExternalsRecorder_init time, so we could consider adding them all early, then do a lock-free lookup later.

Yes, it is @rose00's proposal: create big enough (different size for product and debug VMs) constant table and populate it with runtime addresses we know are used. Keep this table unchanged - no need locks. And, as fall back, use current proposed changes if we find some address which is not in this constant table.

There few issues there:
- in debug VM we have about >100 external address, initialize  all addresses of them is tedious
- In debug VM a lot of addresses are constant string for bailouts. It will be difficult to get addresses for them - they use local variables

I plan to file a separate RFE to investigate this proposal.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19703#issuecomment-2181611702