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

[Andrew Dinn]

On Thu, 13 Jun 2024 15:28:34 GMT, Vladimir Kozlov <kvn 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.

src/hotspot/share/code/oopRecorder.cpp line 229:

> 227: void ExternalsRecorder::initialize() {
> 228:   // After Mutex and before CodeCache are initialized
> 229:   _recorder = new ExternalsRecorder();

Can we assert that _recorder is null?

src/hotspot/share/code/oopRecorder.hpp line 254:

> 252:   static ExternalsRecorder* _recorder;
> 253:  public:
> 254:   ExternalsRecorder();

Should this be private?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19703#discussion_r1642623608
PR Review Comment: https://git.openjdk.org/jdk/pull/19703#discussion_r1642621485