Allow SCC to be overridden during relocation - #18878
Conversation
An alternate SCC frontend may now be passed to the relocation runtime, which will be used for the duration of relocation. Signed-off-by: Christian Despres <despresc@ibm.com>
|
Attn @mpirvu. |
mpirvu
left a comment
There was a problem hiding this comment.
The changes look ok. The code assumes that during relocation we will always use the sharedCache coming from the frontend associated with a particular reloRuntime in play. If there are parts of the code that obtain the frontend or sharedCache differently than going reloRuntime-->fe-->sharedCache, things will start to break.
|
jenkins test sanity plinuxjit,xlinuxjit,zlinuxjit,alinux64jit,zlinux jdk17 |
|
|
|
|
|
Failure in sanity zlinuxjit jdk17 was: This might be the same kind of failure as #18839 (comment) (which I haven't seen before). The only issue with this test I can see is #18670, but it doesn't seem like the same type of failure. |
|
jenkins test sanity zlinuxjit jdk17 |
|
Tests have passed, hence merging. |
An alternate SCC frontend may now be passed to the relocation runtime, which will be used for the duration of relocation. This isn't directly useful, but #18301 will need this to override the shared class cache interface used during relocation.