From dev-return-28460-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Tue Jul 17 14:00:06 2007
Return-Path:
Delivered-To: apmail-harmony-dev-archive@www.apache.org
Received: (qmail 46962 invoked from network); 17 Jul 2007 13:59:47 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 17 Jul 2007 13:59:47 -0000
Received: (qmail 3499 invoked by uid 500); 17 Jul 2007 12:57:48 -0000
Delivered-To: apmail-harmony-dev-archive@harmony.apache.org
Received: (qmail 3475 invoked by uid 500); 17 Jul 2007 12:57:48 -0000
Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@harmony.apache.org
Delivered-To: mailing list dev@harmony.apache.org
Received: (qmail 3466 invoked by uid 99); 17 Jul 2007 12:57:48 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Jul 2007 05:57:48 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of pavel.ozhdikhin@gmail.com designates 64.233.166.179 as permitted sender)
Received: from [64.233.166.179] (HELO py-out-1112.google.com) (64.233.166.179)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Jul 2007 05:57:44 -0700
Received: by py-out-1112.google.com with SMTP id a73so3013142pye
for ; Tue, 17 Jul 2007 05:57:23 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
d=gmail.com; s=beta;
h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
b=hh5wrDYAY09RbkQdmlH4u896OHVDIelifG4BJJQPi3EqXZB8KGJGqH6sZUMSQGuEdzg4SnQk5ARL3DFFdPe9e0xHU44/8zudVE9S5YX79UMp8/iPu5BpyYfmuABKibE+iY57z/7f/1Er8r/jCFAFxY622q2x8kqKjgT9xqsUuZU=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=beta;
h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
b=apPZpCcE69kTE7V4Pj+TXdCrMXMWIhcMtG0SpYJm2aylLv8ndV5QuEd5z7BemlHNraNNVssnym08bl521TL5FoYojbM5x66t7DPz+MyzS/QoFPFxSTRbkyjJLAL3afizRE3PHcCCOafeE14jd/+apulBDxUdUsdc0e2GBrAs664=
Received: by 10.141.5.3 with SMTP id h3mr97376rvi.1184677042396;
Tue, 17 Jul 2007 05:57:22 -0700 (PDT)
Received: by 10.141.29.20 with HTTP; Tue, 17 Jul 2007 05:57:22 -0700 (PDT)
Message-ID: <469bff730707170557o4a40d1ffi67992145737aa247@mail.gmail.com>
Date: Tue, 17 Jul 2007 19:57:22 +0700
From: "Pavel Ozhdikhin"
To: dev@harmony.apache.org
Subject: Re: [drlvm][jit][opt][abcd] Two-state Inequality Graph for both Lower and Upper problems
In-Reply-To: <0vq4pk4dl4m.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_22403_5191234.1184677042361"
References: <0vq4pk4dl4m.fsf@gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org
------=_Part_22403_5191234.1184677042361
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Egor,
On 17 Jul 2007 02:44:25 +0400, Egor Pasko 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!
I've commented in JIRA and started "build test" with your patch on Win32 -
goes fine so far.
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
I also ran into the several issues trying DaCapo benchmarks. They are caused
by recent commits in JIT and verifier. The JIT issues will be fixed soon,
but feel free to report the so we don't miss one. I'm also looking into the
verifier failure.
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!
Did you compare the numbers before/after your patch? I remember we regressed
a bit in terms of performance after accepting last set of ABCD patches -
this was because of fixing too optimistic bound check removals.
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.
Not good. But if this code is eligible for optimization we should optimize
it. Please file a JIRA issue, the patch would be even better! :)
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?
Assuming we agreed to have a Harmony milstone every 2 month, the next (M3)
should be at the end of August. Now I"m going to fix as many bugs as
possible to raise Linux stability to the same level as Windows before the
milestone. Then I'll get back to performance tasks, including those you
listed above. Still I'm ready to discuss and test any performance patches
from you any time.
Thanks,
Pavel
--
> Egor Pasko
>
>
------=_Part_22403_5191234.1184677042361--