Hello, JIT & GC gurus!
I'd like to share my observations on HARMONY-1862 and move the
discussion from JIRA. Mikhail, Ivan, your opinions are extremely
valuable!
> Mikhail Fursov commented on HARMONY-1682:
> -----------------------------------------
>
> Ivan, I checked the test you sent
> The test fails and GC runs only once before the failure.
> I moved all methods except the problem one to Jitrino.JET and
> Jitrino.OPT reports only 2 items: one object and one [mptr,
> object] pair with a small offset.
Mikhail,
a small offtopic: do you use debugger to detect that one object is
reported? I cannot see it in the logs. I can see only "pairs dump":
========================================================================
__IR_DUMP_BEGIN__: pairs dump
========================================================================
inst=1 num_pairs=0
inst=8 num_pairs=0
inst=18 num_pairs=1
mptr=19 base=-1 offset=2147483647
inst=26 num_pairs=1
mptr=19 base=-1 offset=2147483647
inst=35 num_pairs=1
mptr=19 base=-1 offset=2147483647
inst=38 num_pairs=0
inst=48 num_pairs=1
mptr=19 base=-1 offset=2147483647
inst=49 num_pairs=1
mptr=19 base=-1 offset=2147483647
inst=50 num_pairs=1
mptr=19 base=-1 offset=2147483647
inst=51 num_pairs=1
mptr=19 base=-1 offset=2147483647
inst=52 num_pairs=1
mptr=19 base=-1 offset=2147483647
inst=55 num_pairs=1
mptr=19 base=-1 offset=2147483647
inst=57 num_pairs=1
mptr=19 base=-1 offset=2147483647
inst=59 num_pairs=1
mptr=19 base=-1 offset=2147483647
inst=67 num_pairs=0
inst=70 num_pairs=0
inst=80 num_pairs=0
inst=84 num_pairs=0
inst=94 num_pairs=0
inst=96 num_pairs=0
inst=99 num_pairs=0
inst=102 num_pairs=0
========================================================================
__IR_DUMP_END__: pairs dump
========================================================================
it should be slightly deferrent from yours because I turned off some
preliminary optimizations ("devirt","inline") to have a smaller IR, so
inst IDs are different, and this is OK.
My suspicious place in the IR looks like:
----------------------------------------------------------------------
BB_12
PersistentId = 20
ExecCnt = 473637
Loop: Depth=2, !hdr, hdr=BB_11
Predcessors: BB_11
Successors: BB_13 [Prob=1] UN_48 [Prob=1e-07](loopexit)
I22: (AD:t32:cls:ClTest$MyObject) =CopyPseudoInst (AU:t31[t19]:object)
BB_13
PersistentId = 21
ExecCnt = 473637
Loop: Depth=2, !hdr, hdr=BB_11
Predcessors: BB_12
Successors: BB_15 [Prob=1] UN_48 [Prob=1e-07](loopexit)
I24: (AD:t33:vtb:cls:ClTest$MyObject) =CopyPseudoInst
(AU:t35[t32+t34(0:vtao)]:vtb:cls:ClTest$MyObject)
I25: t37:method:getPackages (ID:v8(EFLGS):uint32) =ADD
t33:vtb:cls:ClTest$MyObject,t36(0:vtso:ClTest$MyObject.getPackages):int32
I26: (AD:t39:cls:ClTest$Package[]) =CALL t38[t37]:ptr:uintptr
(AU:t32:cls:ClTest$MyObject)
----------------------------------------------------------------------
"I22" is the memory read of "acl[i]". (Here "acl" is the name of
original array from the test) The address is composed from the array's
base, plus the loop invariant index. It was optimized out by "memopt"
to become a simple memory read (bounds checks were also aggressively
eliminated by "memopt")
"I26" is the corresponding safepoint. An I right?
Another "acl[i]" follows this point. (insts I31, I63 for me)
My question here is: "t19 is the mem address, but why is it itself
considered as a managed pointer?" In my opinion, correct reporting
would make "acl" a base pointer, "t19" as the final address, and "t19
- acl" as offset.
What I suspect here to happen. We stop on "I26" with GC. GC moves
"acl" array to another address, while "t19" becomes invalid, because
it was not reported as an interior to "acl" (was it?)
I can stick to this place in GDB and detect what really happens, but a
proof of concept from someone would be, anyway, useful for my
understanding. Can an array be moved like this in current
implementation? Is it really no relation between "acl" and "t19"
reported by JIT? If the last assumption is true, behaviour is quite
predictable. "t19" address is not updated, and the next mem read
from "[t19]" leads to SEGV.
Without memopt, "t19" is composed as "base + offset", the
corresponding memread looks like this:
----------------------------------------------------------------------
BB_14
PersistentId = 20
ExecCnt = 473626
Loop: Depth=2, !hdr, hdr=BB_11
Predcessors: BB_12
Successors: BB_15 [Prob=1] UN_52 [Prob=1e-07](loopexit)
Layout Succ: BB_15
I31: (AD:t43(EAX):cls:ClTest$MyObject) =CopyPseudoInst
(AU:t42[t4(ESI)+t31(EBX)*t40(4)+t38(12)]:object)
BB_15
PersistentId = 21
ExecCnt = 473626
Loop: Depth=2, !hdr, hdr=BB_11
Predcessors: BB_14
Successors: BB_17 [Prob=1] UN_52 [Prob=1e-07](loopexit)
Layout Succ: BB_17
I33: (AD:t44(ECX):vtb:cls:ClTest$MyObject) =CopyPseudoInst
(AU:t46[t43(EAX)+t45(0:vtao)]:vtb:cls:ClTest$MyObject)
I35: (AD:t50(EAX):cls:ClTest$Package[]) =CALL
t49[t44(ECX)+t47(88:vtso:ClTest$MyObject.getPackages)]:ptr:uintptr
(AU:t43(EAX):cls:ClTest$MyObject)
I125: GCInfoPseudoInst (AU:t4(ESI):cls:ClTest$MyObject[])
[phase:gcpoints]([t4,0])
----------------------------------------------------------------------
And "pairs dump" is always zero:
inst=18 num_pairs=0
What we can do here within Jitrino is another story:
* disable "memopt"
* disable "addindex" optimization in "memopt", that would lead to
explicit "+" operation on each access.
* make "memopt" mark "t19" as a "base + offset", support in GC may be required
> According to the IR I have this is OK.
> The GC enumeration point is:
> I36: (AD:t54(EAX):cls:ClTest$Package[]) =CALL
> t53(-390:m:ClTest$MyObject.getPackages):int32
> (AU:t43(EAX):cls:ClTest$MyObject)
>
> I can help you to add more logging into Jitrino.OPT GCMap
> algorithms. Can you imagine the logging that will help?
--
Egor Pasko, Intel Managed Runtime Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
