Currently we have oops and metadata data sections in nmethod which are referenced by index from relocation info. That data can be patched by VM when they are changed.
External addresses usually embedded into relocation info data because they don't need to be patched during normal execution. But for Leyden we need to patch them when we load AOT code and related data because external addresses are different.
I suggest to move external data into new nmethod's data sections to make relocation info immutable even for Leyden.
I also want to experiment with moving relocation info from CodeCache into nmethod's immutable data section. But it depends on performance results.
External addresses usually embedded into relocation info data because they don't need to be patched during normal execution. But for Leyden we need to patch them when we load AOT code and related data because external addresses are different.
I suggest to move external data into new nmethod's data sections to make relocation info immutable even for Leyden.
I also want to experiment with moving relocation info from CodeCache into nmethod's immutable data section. But it depends on performance results.
- relates to
-
JDK-8334691 Optimize access to global table of relocation external addresses
-
- Open
-
-
-
- In Progress
-
-
JDK-8334779 Test compiler/c1/CanonicalizeArrayLength.java is timing out
-
- Resolved
-
