Skip to content

Cache compInfoPT in JITServer deserializer SCC interface - #19101

Merged
mpirvu merged 1 commit into
eclipse-openj9:masterfrom
cjjdespres:deserializer-in-thread
Mar 28, 2024
Merged

Cache compInfoPT in JITServer deserializer SCC interface#19101
mpirvu merged 1 commit into
eclipse-openj9:masterfrom
cjjdespres:deserializer-in-thread

Conversation

@cjjdespres

Copy link
Copy Markdown
Contributor

The TR::CompilationInfoPerThread is now cached in TR_J9DeserializerSharedCache to avoid the use of TR::compInfoPT. The handling of the TR_J9DeserializerSharedCache object itself has changed to accommodate this - there is now a _deserializerSharedCache in TR_J9VMBase (to have these objects be exclusive to one compilation thread) and the _deserializerSharedCache in TR::CompilationInfo has been removed.

Related: #18990

@cjjdespres
cjjdespres requested a review from dsouzai as a code owner March 7, 2024 17:14
@cjjdespres

Copy link
Copy Markdown
Contributor Author

Attn @mpirvu.

@mpirvu mpirvu self-assigned this Mar 7, 2024
@mpirvu mpirvu added the comp:jitserver Artifacts related to JIT-as-a-Service project label Mar 7, 2024

@mpirvu mpirvu left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread runtime/compiler/env/VMJ9.cpp Outdated
@cjjdespres
cjjdespres force-pushed the deserializer-in-thread branch from a7e19d3 to c384bb4 Compare March 22, 2024 14:53
@cjjdespres

Copy link
Copy Markdown
Contributor Author

I have moved the deserializer SCC initialization to TR_J9VMBase::get, at the point where we know that the frontend being fetched is for a compilation thread. I also added a check just before we use the deserializer SCC for relocation that fails the compilation if it's NULL (in the unlikely case where we failed to allocate it).

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>
@cjjdespres
cjjdespres force-pushed the deserializer-in-thread branch from c384bb4 to 51e54c8 Compare March 22, 2024 15:32

@mpirvu mpirvu left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mpirvu

mpirvu commented Mar 25, 2024

Copy link
Copy Markdown
Contributor

jenkins test sanity plinuxjit,xlinuxjit,zlinuxjit,alinux64jit jdk17

@mpirvu

mpirvu commented Mar 26, 2024

Copy link
Copy Markdown
Contributor

aarch64 had one failure:

Testing: Create CRIU checkpoint image and restore three times - testSystemNanoTimeJitPostCheckpointCompile
Test start time: 2024/03/26 03:49:35 Coordinated Universal Time
Running command: bash /home/jenkins/workspace/Test_openjdk17_j9_sanity.functional_aarch64_linux_jit_Personal_testList_0/aqa-tests/TKG/../../jvmtest/functional/cmdLineTests/criu/criuScript.sh /home/jenkins/workspace/Test_openjdk17_j9_sanity.functional_aarch64_linux_jit_Personal_testList_0/aqa-tests/TKG/../../jvmtest/functional/cmdLineTests/criu /home/jenkins/workspace/Test_openjdk17_j9_sanity.functional_aarch64_linux_jit_Personal_testList_0/jdkbinary/j2sdk-image/bin/java "-XX:+UseJITServer -Xjit:count=0 -XX:+CRIURestoreNonPortableMode " "org.openj9.criu.TimeChangeTest testSystemNanoTimeJitPostCheckpointCompile" 3 3 false false
Time spent starting: 3 milliseconds
***[TEST INFO 2024/03/26 03:54:35] ProcessKiller detected a timeout after 300000 milliseconds!***
***[TEST INFO 2024/03/26 03:54:35] executing /usr/bin/gdb -batch -x /tmp/debugger983743307752920562.txt bash 3700555***
GDB OUT No shared libraries loaded at this time.
INFO: Running '/usr/bin/gdb' failed with rc = 1
GDB ERR Could not attach to process.  If your uid matches the uid of the target
GDB ERR process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
GDB ERR again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
GDB ERR ptrace: Inappropriate ioctl for device.
GDB ERR /home/jenkins/workspace/Test_openjdk17_j9_sanity.functional_aarch64_linux_jit_Personal_testList_0/aqa-tests/TKG/output_17114212823109/cmdLineTester_criu_nonPortableRestore_4/3700555: No such file or directory.
GDB ERR /tmp/debugger983743307752920562.txt:2: Error in sourced command file:
GDB ERR The program has no registers now.

@mpirvu

mpirvu commented Mar 26, 2024

Copy link
Copy Markdown
Contributor

Retrying the aarch test here: https://openj9-jenkins.osuosl.org/job/Grinder/3419/

@mpirvu

mpirvu commented Mar 27, 2024

Copy link
Copy Markdown
Contributor

jenkins test sanity alinux64jit jdk17

@mpirvu

mpirvu commented Mar 28, 2024

Copy link
Copy Markdown
Contributor

aarch64 had a failure due to port being busy:

cmdLineTester_criu_jitserverPostRestore_0 Start Time: Wed Mar 27 20:00:44 2024 Epoch Time (ms): 1711584044613
variation: -Xjit
JVM_OPTIONS: -XX:+UseJITServer -Xjit 

...
Testing: Test -Xjit:exclude={*}
Test start time: 2024/03/27 20:01:14 Eastern Standard Time
Running command: bash /home/jenkins/workspace/Test_openjdk17_j9_sanity.functional_aarch64_linux_jit_Personal_testList_1/aqa-tests/TKG/../../jvmtest/functional/cmdLineTests/criu/criuJitServerScript.sh /home/jenkins/workspace/Test_openjdk17_j9_sanity.functional_aarch64_linux_jit_Personal_testList_1/aqa-tests/TKG/../../jvmtest/functional/cmdLineTests/criu /home/jenkins/workspace/Test_openjdk17_j9_sanity.functional_aarch64_linux_jit_Personal_testList_1/jdkbinary/j2sdk-image/bin "-XX:+UseJITServer -Xjit " org.openj9.criu.OptionsFileTest "JitOptionsTest -XX:+UseJITServer -Xjit:exclude={*}" 1 false false
Time spent starting: 5 milliseconds
Time spent executing: 2063 milliseconds
Test result: FAILED
Output from test:
 [OUT] start running script
 [OUT] export GLIBC_TUNABLES=glibc.cpu.hwcaps=-XSAVEC,-XSAVE,-AVX2,-ERMS,-AVX,-AVX_Fast_Unaligned_Load
 [OUT] export LD_BIND_NOT=on
 [OUT] Starting /home/jenkins/workspace/Test_openjdk17_j9_sanity.functional_aarch64_linux_jit_Personal_testList_1/jdkbinary/j2sdk-image/bin/jitserver -XX:JITServerPort=40050 -XX:JITServerHealthProbePort=38600 
 [OUT] JITSERVER DOES NOT EXIST

Interestingly, the health probe is exactly the default value, while it should have been a randomly chose one.

@mpirvu

mpirvu commented Mar 28, 2024

Copy link
Copy Markdown
Contributor

Given that the failure is not due to this PR and all the other tests passed, I am going to merge it.

@mpirvu
mpirvu merged commit d3d128a into eclipse-openj9:master Mar 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp:jitserver Artifacts related to JIT-as-a-Service project

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants