Closed mpirvu closed 2 years ago
mpirvu
commented
2 years ago I have reproduced the crash locally and determined that the crash is due to the -XXgc:forcedShiftingCompressionAmount=4 presence on the command line at the client. If this option is removed, the test passes.
mpirvu
commented
2 years ago I have limited the problem to just one method. I can reproduce the issue with
"-Xshareclasses:none -Xjit:disableAsyncCompilation,limit={sun/net/www/ParseUtil.encodePath*},initialOptLevel=cold,disableInlining,traceFull,log=log.txt -XXgc:forcedShiftingCompressionAmount=4 -Xmx512m -XX:+UseJITServer"
mpirvu
commented
2 years ago I used compilation logs and enableJITServerFollowRemoteCompileWithLocalCompile option to perform two back to back compilations with logs, one remote and one local. I compared the two logs and post optimizations tress looks the same.
I see a difference in newarray allocation inlining:
local:
[0x7f457ff7f820] lea GPR_0047, dword ptr [2*GPR_0044+0x10] # LEA4RegMem, SymRef [#404 +16]
[0x7f457ff7f8b0] Label L0052: # label # (Start of internal control flow)
[0x7f457ff821f0] cmp GPR_0047, 0x3fffffff # CMP8RegImm4
[0x7f457ff82280] jae Outlined Label L0054 # JAE4
[0x7f457ff823b0] mov GPR_0048, qword ptr [GPR_0000+0x60] # L8RegMem, SymRef [#405 +96]
[0x7f457ff82440] mov GPR_0045, GPR_0047 # MOV4RegReg
[0x7f457ff824d0] cmp GPR_0045, 0x00000001 # CMP4RegImm4
[0x7f457ff82560] adc GPR_0045, 0x00000000 # ADC4RegImm4
[0x7f457ff825f0] shl GPR_0045, 0x01 # SHL8RegImm1
[0x7f457ff82680] add GPR_0045, 0x0000001f # ADD8RegImm4
[0x7f457ff82710] and GPR_0045, 0xfffffffffffffff0 # AND8RegImm4remote:
[0x7f62c423f820] lea GPR_0080, dword ptr [2*GPR_0060+0x10] # LEA4RegMem, SymRef [#404 +16]
[0x7f62c423f8b0] Label L0080: # label # (Start of internal control flow)
[0x7f62c42421f0] cmp GPR_0080, 0x3fffffff # CMP8RegImm4
[0x7f62c4242280] jae Outlined Label L0082 # JAE4
[0x7f62c42423b0] mov GPR_0081, qword ptr [GPR_0000+0x60] # L8RegMem, SymRef [#405 +96]
[0x7f62c4242440] mov GPR_0064, GPR_0080 # MOV4RegReg
[0x7f62c42424d0] cmp GPR_0064, 0x00000001 # CMP4RegImm4
[0x7f62c4242560] adc GPR_0064, 0x00000000 # ADC4RegImm4
[0x7f62c42425f0] shl GPR_0064, 0x01 # SHL8RegImm1
[0x7f62c4242680] add GPR_0064, 0x00000017 # ADD8RegImm4
[0x7f62c4242710] and GPR_0064, 0xfffffffffffffff8 # AND8RegImm4I traced this code to static void genHeapAlloc2() from J9TreeEvaluator.cpp. It appears that 0x17 from
[0x7f62c4242680] add GPR_0064, 0x00000017 # ADD8RegImm4 is generated from allocationSizeOrDataOffset+disp32 and disp32 is from round-1 and round is from
round = (elementSize >= TR::Compiler->om.objectAlignmentInBytes())? 0 : TR::Compiler->om.objectAlignmentInBytes();
Thus, the remote compiler sees TR::Compiler->om.objectAlignmentInBytes() being 8 while the local compiler sees 16.
Interestingly enough, if I print _vmInfo->_objectAlignmentInBytes at the server, I get 16, so at this point I don't know how the server ends up with 8.
mpirvu
commented
2 years ago It turns out that the codegen uses TR::Compiler->om.getObjectAlignmentInBytes() which is a new implementation from https://github.com/eclipse-openj9/openj9/pull/14110 and is not overridden for JITServer. Thus, the server gets the wrong value of the object alignment.
mpirvu
commented
2 years ago The correct implementation for getObjectAlignmentInBytes() would include a test for JITServer, something along the lines:
int32_t
J9::ObjectModel::getObjectAlignmentInBytes()
{
#if defined(J9VM_OPT_JITSERVER)
if (auto stream = TR::CompilationInfo::getStream())
{
auto *vmInfo = TR::compInfoPT->getClientData()->getOrCacheVMInfo(stream);
return vmInfo->_objectAlignmentInBytes;
}
#endif /* defined(J9VM_OPT_JITSERVER) */
return _objectAlignmentInBytes;
}@cjjdespres Could you please provide a fix for this issue? Thanks
Recently,
jit_jitt_array_compress_3started to fail on all platforms when JITServer is used Example of a failure: https://hyc-runtimes-jenkins.swg-devops.com/job/Test_openjdk8_j9_sanity.functional_x86-64_linux_jit_Personal/838/tapResults/Optional info