harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject [drlvm] Jitrino.OPT performs incorrect GC enumeration in nested loop with array accesses
Date Thu, 05 Oct 2006 10:09:35 GMT
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message