[GR-64584] Base-relative code pointers in vtables for non-layered images. #11150
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Relocation entries for pointers in the virtual dispatch tables (vtables) of DynamicHub objects require additional space in position-independent executables and shared libraries, cause delays during startup when processed at runtime by the dynamic linker, and decrease sharing between instances of the same image because memory pages must be copied (by the OS) when adjusting pointers. This is magnified with layered images where the base layer(s) in particular are expected to contain large number of methods which may be used in virtual dispatch.
The task at hand is to, as a first step, eliminate relocation entries in vtables for non-layered images, by introducing the notion of a code base and changing vtable entries to be offsets relative to that code base. Therefore, for dispatching a virtual call, it becomes necessary to add the code base to the vtable entry each time.
For prudence and because there will be some initial limitations (PLT/GOT dispatch, LLVM backend, layers), this is an option that is turned off by default.
This will also not eliminate relocation entries outside of vtables, such as in reflection accessors or JNI dispatch records. However, these can typically be assumed to be few compared to those in vtables.