harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Strigun" <vstri...@gmail.com>
Subject Re: [drlvm][jit][opt][abcd] Two-state Inequality Graph for both Lower and Upper problems
Date Wed, 18 Jul 2007 10:04:06 GMT
On 18 Jul 2007 13:58:46 +0400, Egor Pasko <egor.pasko@gmail.com> wrote:
> On the 0x317 day of Apache Harmony Vladimir Strigun wrote:
> > Egor,
> >
> > On 17 Jul 2007 02:44:25 +0400, Egor Pasko <egor.pasko@gmail.com> wrote:
> > > Guys,
> > >
> > > I am not very stuck with ABCD. I am not. Not at all. Not am I.
> > > Ehm.
> > >
> > > Lickily, I finished digging into the implementation and making sure it
> > > is correct. Now I am pretty confident that classic_abcd does the right
> > > thing! (no guarantees, you know, it's software) Had to refactor the
> > > code a bit to fill in the gaps of my poor understanding. I think, we
> > > should commit the changes...
> > >
> > > featuring:
> > > * two-state Inequality Graph, dot printing is just beautiful
> > > * better readability
> > > * unit-like-tests against the new functionality
> > > * option: -XX:jit.arg.dump_abcd_stats=true to dump stats (total/eliminated)
> > > * same amount of checks eliminated as before
> > > * well-known tests breaking oldish ABCD _passed_, of course
> > >
> > > in all, HARMONY-4476 (more details in JIRA)
> > >
> > > Given that Windows is not what I am lucky with today, if a JIT guru
> > > (Pavel, Mikhail, George?) had time to take a look at the patch and run
> > > 'build test' on Windows that would be really-really great!
> > >
> > > And now the ugly porn:
> > >
> > > 1. I could not run almost all of DaCapo benches for various reasons, so
> > >   tested only on hsqldb, wow, anybody aware of it or is it just me
> > >   ugly little creature? had little time, sorry
> >
> > Could you please describe what problems do you have with running Dacapo?
>
> for example:
>
> [pasko 13:51:19 dacapo]$ $HARMONY -showversion -XX:jit.arg.dump_abcd_stats=true -Xem:server
-jar dacapo-2006-10-MR2.jar antlr
> Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software Foundation or
its licensors, as applicable.
> java version "1.5.0"
> pre-alpha : not complete or compatible
> svn = r554009, (Jul 17 2007), Linux/ia32/gcc 4.0.3, debug build
> http://harmony.apache.org
> ===== DaCapo antlr starting =====
> Running antlr on grammar antlr/cpp/calc.g
> ANTLR Parser Generator   Version 2.7.5 (20050128)   1989-2005 jGuru.com
> [pasko 13:52:03 dacapo]$
>
> this is a failure ("PASSED" was not printed)
> ..but the version is rather old.
>
> I am going to file the bugs as soon as I manage to check the latest version.

Yes, it's well known issue (HARMONY-1906). The problem here that
Dacapo uses patched version of antlr, while antlr.jar included to
bootclasspath for vm. So, the workaround here is to remove antlr.jar
from bootclasspath.properties file.


Thanks.
Vladimir.

> > I've checked your patch on all dacapo benches and I haven't see any
> > boost or degradation (release build rev 556923).
>
> That is good! There should be no boost or degradation. These changes
> were made for better maintainability and to more or less prove
> correctness of the optimization.
>
> > Thanks.
> > Vladimir.
> >
> > > 2. ~10% bounds checks removed in hot methods and 8% in total, with
> > >   ABCD innocent and many other optimizations very very guilty or
> > >   absent. OMG!
> > >
> > > 3. "memopt" is probably the ugliest!! In my example:
> > >   1. array A lies in a non-volatile field
> > >   2. A.length is computed right in the method entrance
> > >   3. A is then loaded via "ldfield" bytecode instruction in the
> > >      middle of the method
> > >   4. nothing writes to the field, just accesses elements of A
> > >
> > >   And who could imagine that A.length would be computed twice with
> > >   "memopt" having nothing to do with second appearance A.length?
> > >   Thus, not eliminating the second appearance of this sequence:
> > >
> > >   I9:ldflda    [t1.BidirectionalBubbleSort2::a] -) t4:ref:int32[]
> > >   I10:ldind.unc:[]  [t4] ((t2,t3)) -) t5:int32[]
> > >   I11:chknull   t5 -) t6:tau
> > >   I12:tauhastype      t5,int32[] -) t7:tau
> > >   I13:arraylen  t5 ((t6,t7)) -) t8:int32
> > >
> > >   this is what should be optimized out definitely! and the thing that
> > >   breaks two A.length-s apart killing the idea of ABCD.
> > >
> > > 4. "loop versioning" is not implemented, and this is what I would like
> > >   to take. I already wrote some 2-component-nullstone-like
> > >   performance tests to detect how good a JVM deals with loop
> > >   versioning. Will post the bunch of them soon.
> > >
> > > JIT gurus,
> > >
> > > given the ugly (1) - (4), rather critical for performance do you like
> > > the idea to fight them in a high priority? Could you share your
> > > vision, please?
> > >
> > >
> > > --
> > > Egor Pasko
> > >
> > >
> >
>
> --
> Egor Pasko
>
>

Mime
View raw message