Open dylanjtuttle opened 1 year ago
This assert lives inside the constructor to the common code generator class RegisterDependencyMap
. The assertion fails because numDeps
, the second parameter passed into the constructor, is larger (256) than SENTINEL
, a constant holding the value 255
.
The path we take to get to the fateful execution of this constructor is:
OMR::Power::RegisterDependencyConditions::assignPostConditionRegisters
OMR::Power::RegisterDependencyGroup::assignRegisters
and the value that ends up becoming numDeps
is originally _addCursorForPost
, a member variable of RegisterDependencyConditions
. It is initialized to zero, and then incremented once in addPostCondition
, which makes sense because addPostCondition
calls setDependencyInfo
to add a register dependency.
Therefore, in order for _addCursorForPost
to hold the value 256 by the time it's passed into RegisterDependencyMap
, we must call addPostCondition
exactly 256 times, meaning we're calling addPostCondition
(or adding register dependencies) at least one too many times. There are 143 different places in omr/compiler/p/codegen
where we call addPostCondition
, and somewhere in that list is likely an edge case where that extra call comes from.
@bhavanisn please take this over (at lower priority)
Looking further at the addPostCondition
the assert in there which checks with value _numPostConditions
for an overflow which is not triggerred, which means that _numPostConditions
could be set to value higher than 255.
{
TR_ASSERT(_addCursorForPost < _numPostConditions, " Post Condition array bounds overflow");
_postConditions->setDependencyInfo(_addCursorForPost++, vr, rr, flag);
}
Added asserts in RegisterDependencyConditions
constructors led to assert being taken which trace back to OMR::Power::Machine::createCondForLiveAndSpilledGPRs
called from TR_OutOfLineCodeSection::assignRegisters
.
https://github.com/eclipse/omr/blob/master/compiler/p/codegen/OMRMachine.cpp#L1826-L1852
In the above code, the spilledRegisterList (231) + RealRegister
count turns out to be >= 255, which inturn led to hit the assert in RegisterDependencyMap
.
Either SENTINEL
set to 255 might be outdated or spilledRegisterList + RealRegister
should not exceed 255 which is what is causing this issue and need to be investigated further.
Attached the trace of the method SystemModules$default.moduleHashes
:
Though there are only 5 basic blocks, in BBStart <block_2>
, there is a large number of stores:
14027, JBbipush 28
14029, JBbipush 11
14031, JBbastore
treetop [ 0x7a4070d29ec0] bci=[-1,6,-] rc=0 vc=34 vn=- li=- udi=- nc=1
n12n new jitNewObject[#91 helper Method] [flags 0x400 0x0 ] (X!=0 ) [ 0x7a4070d29e70] bci=[-1,6,-] rc=147 vc=34 vn=- li=- udi=- nc=1 flg=0x4
n10n ==>loadaddr
n14n allocationFence on n12n (X==0 X>=0 X<=0 ) [ 0x7a4070d29f10] bci=[-1,6,-] rc=0 vc=34 vn=- li=- udi=- nc=0 flg=0x302
n16n ResolveCHK [#325] [ 0x7a4070d29fb0] bci=[-1,10,-] rc=0 vc=34 vn=- li=- udi=- nc=1
n15n aload <string>[#406 unresolved Static +962232920] [flags 0x80000307 0x0 ] [ 0x7a4070d29f60] bci=[-1,10,-] rc=2 vc=34 vn=- li=- udi=- nc=0
n19n ResolveCHK [#32] [ 0x7a4070d2a0a0] bci=[-1,15,-] rc=0 vc=34 vn=- li=- udi=- nc=1
n18n call jdk/internal/module/ModuleHashes$Builder.<init>(Ljava/lang/String;I)V[#407 unresolved notAccessed special Method] [flags 0x400 0x0 ] () [ 0x7a4070d2a050] bci=[-1,15,-] rc=1 vc=34 vn=- li=- udi=- nc=3 flg=0x20
n12n ==>new
n15n ==>aload
n17n iconst 95 (X!=0 X>=0 )
Below segment Live regs
the count is 168
.
n2945n ( 0) bstorei <array-shadow>[#249 Shadow] [flags 0x80000601 0x0 ] [ 0x777a954a8840] bci=[-1,1611,-] rc=0 vc=164 vn=- li=2 udi=- nc=2
n2944n ( 0) aladd (X>=0 internalPtr ) [ 0x777a954a87f0] bci=[-1,1611,-] rc=0 vc=164 vn=- li=2 udi=- nc=2 flg=0x8100
n2932n ( 32) ==>newarray (in &GPR_0565) (highWordZero Unsigned X!=0 allocationCanBeRemoved )
n39n ( 63) ==>lconst 8 (highWordZero X!=0 X>=0 )
n2937n ( 11) bconst 13 (in GPR_0579) (X!=0 X>=0 ) [ 0x777a954a85c0] bci=[-1,1611,-] rc=11 vc=164 vn=- li=2 udi=57200 nc=0 flg=0x104
------------------------------
[ 0x777a95c6dfe0] 1611 li GPR_0579, 000000000000000D
[ 0x777a95c6e0f0] 1611 stb [&GPR_0565, 8], GPR_0579 # SymRef <array-shadow>[#249 Shadow] [flags 0x80000601 0x0 ]
============================================================
; Live regs: GPR=167 FPR=0 CCR=0 VRF=0 VSX_SCALAR=0 VSX_VECTOR=0 {GPR_0579, &GPR_0565, &GPR_0553, GPR_0539, GPR_0538, GPR_0537, GPR_0536, GPR_0535, GPR_0534, GPR_0533, GPR_0532, GPR_0531, GPR_0529, GPR_0528, GPR_0527, GPR_0526, GPR_0525, GPR_0524, GPR_0523, GPR_0522, GPR_0482, GPR_0481, GPR_0480, GPR_0479, GPR_0478, GPR_0477, GPR_0476, GPR_0475, GPR_0474, GPR_0473, GPR_0472, GPR_0432, GPR_0431, GPR_0430, GPR_0429, GPR_0428, GPR_0427, GPR_0426, GPR_0425, GPR_0424, GPR_0423, GPR_0422, GPR_0421, GPR_0420, GPR_0419, GPR_0418, GPR_0417, GPR_0377, GPR_0376, GPR_0375, GPR_0374, GPR_0373, GPR_0372, GPR_0371, GPR_0370, GPR_0369, GPR_0368, GPR_0367, GPR_0366, GPR_0365, GPR_0364, GPR_0363, GPR_0362, GPR_0322, GPR_0321, GPR_0320, GPR_0319, GPR_0318, GPR_0317, GPR_0316, GPR_0315, GPR_0314, GPR_0313, GPR_0311, GPR_0310, GPR_0309, GPR_0308, GPR_0307, GPR_0306, GPR_0305, GPR_0304, GPR_0303, GPR_0302, GPR_0262, GPR_0261, GPR_0260, GPR_0259, GPR_0258, GPR_0257, GPR_0256, GPR_0255, GPR_0254, GPR_0253, GPR_0252, GPR_0251, GPR_0250, GPR_0249, GPR_0248, GPR_0247, GPR_0246, GPR_0245, GPR_0244, GPR_0243, GPR_0242, GPR_0241, GPR_0240, GPR_0239, GPR_0199, GPR_0198, GPR_0197, GPR_0196, GPR_0195, GPR_0194, GPR_0193, GPR_0192, GPR_0191, GPR_0190, GPR_0189, GPR_0188, GPR_0187, GPR_0186, GPR_0185, GPR_0184, GPR_0183, GPR_0182, GPR_0181, GPR_0180, GPR_0179, GPR_0178, GPR_0177, GPR_0176, GPR_0175, GPR_0135, GPR_0134, GPR_0133, GPR_0132, GPR_0131, GPR_0130, GPR_0129, GPR_0128, GPR_0127, GPR_0126, GPR_0125, GPR_0124, GPR_0123, GPR_0122, GPR_0121, GPR_0120, GPR_0119, GPR_0118, GPR_0117, GPR_0116, GPR_0115, GPR_0114, GPR_0113, GPR_0112, GPR_0111, GPR_0110, GPR_0109, GPR_0108, GPR_0107, GPR_0106, GPR_0105, GPR_0081, GPR_0080, &GPR_0052, &GPR_0037}
-------------------------
So, in this case, there are dependencies which can reach max of 255.
To test this, increased the value of SENTINEL=65535
. The test passes with this.
The assertion at
/home/jenkins/workspace/Build_JDK11_ppc64le_linux_Personal/omr/compiler/codegen/OMRRegisterDependency.hpp:273: numDeps <= SENTINEL
fires in
sanity.functional
test casecmdLineTester_callsitedbgddrext_openj9_0
onppc64le_linux
for Java 11.Link to Jenkins job.
Stack trace: