Cache compInfoPT in JITServer deserializer SCC interface - #19101
Conversation
|
Attn @mpirvu. |
mpirvu
left a comment
There was a problem hiding this comment.
This solution creates an object of type TR_J9DeserializerSharedCache for every frontend. Each thread (either compilation or not) has a frontend (which is allocated on demand), so all threads will allocate a TR_J9DeserializerSharedCache object. It may better to restrict such object to compilation threads, because I think only the compilation threads will need it.
In all cases (I think) we allocate a frontend with TR_J9VMBase::get(J9JITConfig * jitConfig, J9VMThread * vmThread, VM_TYPE vmType) . If not, we can enforce it by making the constructor private.
For a J9_VM frontend (which is the one we care about in this case), immediately after constructing the object we determine whether this is associated with a compilation thread and set _vmThreadIsCompilationThread and _compInfoPT:
if (alloc)
{
vmWithThreadInfo = new (alloc) TR_J9VM(jitConfig, vmWithoutThreadInfo->_compInfo, vmThread); // allocate the frontend
}
if (vmWithThreadInfo)
{
vmThread->jitVMwithThreadInfo = vmWithThreadInfo; // cache it
// Cache ths compilation thread as well
if (vmWithoutThreadInfo->_compInfo)
{
TR::CompilationInfoPerThread *compInfoPT = vmWithoutThreadInfo->_compInfo->getCompInfoForThread(vmThread);
vmWithThreadInfo->_vmThreadIsCompilationThread = (compInfoPT ? TR_yes : TR_no);
vmWithThreadInfo->_compInfoPT = compInfoPT;
}
}
I think this is the right place to construct and attach a TR_J9DeserializerSharedCache object.
Maybe we can actually push all this code into the constructor.
We should also account for the possibility of not having enough memory to allocate a TR_J9DeserializerSharedCache object. At the point where we need to use the TR_J9DeserializerSharedCache object (before calling prepareRelocateAOTCodeAndData()) we can test if the object is null and fail the compilation. This is very unlikely to happen though.
a7e19d3 to
c384bb4
Compare
|
I have moved the deserializer SCC initialization to |
Caching the per-thread compilation thread info saves looking it up every time the TR_J9DeserializerSharedCache needs to obtain the current compilation object. To support this caching, there is now a TR_J9DeserializerSharedCache in TR_J9VMBase, which is initialized when a frontend is created for a particular compilation thread. Signed-off-by: Christian Despres <despresc@ibm.com>
c384bb4 to
51e54c8
Compare
|
jenkins test sanity plinuxjit,xlinuxjit,zlinuxjit,alinux64jit jdk17 |
|
aarch64 had one failure: |
|
Retrying the aarch test here: https://openj9-jenkins.osuosl.org/job/Grinder/3419/ |
|
jenkins test sanity alinux64jit jdk17 |
|
aarch64 had a failure due to port being busy: Interestingly, the health probe is exactly the default value, while it should have been a randomly chose one. |
|
Given that the failure is not due to this PR and all the other tests passed, I am going to merge it. |
The
TR::CompilationInfoPerThreadis now cached inTR_J9DeserializerSharedCacheto avoid the use ofTR::compInfoPT. The handling of theTR_J9DeserializerSharedCacheobject itself has changed to accommodate this - there is now a_deserializerSharedCacheinTR_J9VMBase(to have these objects be exclusive to one compilation thread) and the_deserializerSharedCacheinTR::CompilationInfohas been removed.Related: #18990