harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: how to get the time used by the OPT, JET?
Date Thu, 25 Jan 2007 08:59:52 GMT
Hi Rana,

On 1/25/07, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>
> Hi,
> For the jit guys, I have a somewhat (?) related question.
> When looking at the jit logs for tight loops like:
>
> for( indx = 0; indx < 1000; indx++)
> {
>    afrom[indx] = afrom[indx + 1];
> }
>
> which is fairly common in Spec sequences, sorts, etc.....
> there are of course three checks during the assignmnet ...null check, type
> check and bounds check. I wanted to make sure that for the above pattern of
> code, the type check was being optimized away. Though is is more potent in
> the jet compiler which I think calls a helper for this, I wanted to
> check this in the opt  compiler. I am quite new to jitrino's logs.
>

I have 2 comments here:
1) Let's avoid any optimizations in JET and leave it as simple as possilble.
Reasons: a) all hotstops are Jitrino.OPT targets b) Jitrino.JET is already ~
10 times faster then SUN interpreter.

2) I tried the method:
    public static int foo6(String[] afrom) {
        for( int indx = 0; indx < 1000; indx++) {
            afrom[indx] = afrom[indx + 1];
        }
        return 0;
    }

The complete IR is:
--------  irDump: Test::foo6  --------
Block ENTRY:
  Predecessors:
  Successors: L1
  I0:--- MethodEntry(Test::foo6): ()
  I4:defarg -) g1:cls:java/lang/String[]
  I6:ldci4     #0 -) g3:int32
  I7:stvar     g3 -) v1:int32
  GOTO L1

Block L1:
  Predecessors: ENTRY L10
  Successors: L3 L2
  I1:L1:
  I8:ldvar     v1 -) t4:int32
  I9:ldci4     #1000 -) t5:int32
  I10:if cge.i4  t4, t5 goto L3
  GOTO L2

Block L2:
  Predecessors: L1
  Successors: L8 UNWIND
  I2:L2:
  I11:ldci4     #1 -) t6:int32
  I12:add   t4, t6 -) t7:int32
  I13:chknull   g1 -) t8:tau
  GOTO L8

Block L8:
  Predecessors: L2
  Successors: L9 UNWIND
  I34:L8:
  I14:tauhastype      g1,cls:java/lang/String[] -) t9:tau
  I15:arraylen  g1 ((t8,t9)) -) t10:int32
  I16:chkbounds t7 .lt. t10 -) t11:tau
  GOTO L9

Block L9:
  Predecessors: L8
  Successors: L10 UNWIND
  I35:L9:
  I17:tauand       t9, t11 -) t12:tau
  I18:ldbase    g1 -) t13:ref:cls:java/lang/String
  I19:addindex  t13, t7 -) t14:ref:cls:java/lang/String
  I20:ldind.unc:str [t14] ((t8,t12)) -) t15:cls:java/lang/String
  I21:chkbounds t4 .lt. t10 -) t16:tau
  GOTO L10

Block UNWIND:
  Predecessors: L2 L8 L9
  Successors: EXIT
  I32:L6:
  GOTO EXIT

Block L10:
  Predecessors: L9
  Successors: L1
  I36:L10:
  I22:tauand       t9, t16 -) t17:tau
  I23:tauexacttype      g1,cls:java/lang/String[] -) t18:tau
  I24:addindex  t13, t4 -) t19:ref:cls:java/lang/String
  I25:stind.unc:str t15 ((t8,t17,t18)) -) [t19]
  I26:stvar     t7 -) v1:int32
  GOTO L1

Block L3:
  Predecessors: L1
  Successors: RETURN
  I3:L3:
  I29:return    g3

Block RETURN:
  Predecessors: L3
  Successors: EXIT
  I31:L5:
  GOTO EXIT

Block EXIT:
  Predecessors: RETURN UNWIND
  Successors:
  I33:L7:

Loop exits are:
1)   I10:if cge.i4  t4, t5 goto L3 -> bounds check->OK (a candidate for
unroll optimization I'm finishing now)
2)   I13:chknull   g1 -) t8:tau -> checks that array is not NULL. The
optimization to move this check out of the loop is loop peeling and it is
enabled only in server mode today. However if NullPointerException is not
caught in the same method, Jitrino.OPT does not generate null-checks and
hardware exception filter is used here.
3)   I16:chkbounds t7 .lt. t10 -) t11:tau and
4)   I21:chkbounds t4 .lt. t10 -) t16:tau are bounds checks for [i], [i+1]
elements. I think it's ok too. We need these checks because loop limit is
not arr.length but some number. May be abcd can help us here?

The taus like
  I14:tauhastype      g1,cls:java/lang/String[] -) t9:tau
and
  I23:tauexacttype      g1,cls:java/lang/String[] -) t18:tau
are assertions(statements) in Jitrino.OPT. No checking code is generated and
these tau can be used as 'true' or 'check was done' flag in a code it
dominates.

But looking at L8, L9, L10, I am not sure that I understand that the type
> check is going away, or what is happening to tauhastype.
>

It's easy to understand with taus if 'tau' is a simple statement or a helper
call. If tau-op finishes the block and you see exception edge -> Jitrino's
optimizer treats it like a helper call (but the call still can be eliminated
in CG!). If tau does not ends a block -> this is a statement and there will
no code generated for it.

Is there a manual on the tau operators that the non jitrino people can read
> ?
>

I've never seen this manual. I've learned taus from the code and IR by
myself. But I'm going to ask this question and will send a reply if the
manual exists :)

-- 
Mikhail Fursov

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message