From dev-return-33278-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Sat Apr 05 16:02:50 2008 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 57556 invoked from network); 5 Apr 2008 16:02:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Apr 2008 16:02:50 -0000 Received: (qmail 25776 invoked by uid 500); 5 Apr 2008 16:02:49 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 25749 invoked by uid 500); 5 Apr 2008 16:02:49 -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 25740 invoked by uid 99); 5 Apr 2008 16:02:49 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Apr 2008 09:02:49 -0700 X-ASF-Spam-Status: No, hits=1.6 required=10.0 tests=RCVD_IN_DNSWL_LOW,RCVD_NUMERIC_HELO,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gcjhd-harmony-dev@m.gmane.org designates 80.91.229.2 as permitted sender) Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Apr 2008 16:01:56 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JiAqH-0000Hj-GM for dev@harmony.apache.org; Sat, 05 Apr 2008 16:02:09 +0000 Received: from 89.175.165.2 ([89.175.165.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Apr 2008 16:02:09 +0000 Received: from egor.pasko by 89.175.165.2 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Apr 2008 16:02:09 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: dev@harmony.apache.org From: Egor Pasko Subject: Re: [general] GSoC 2008 Refactor Java Bytecode Translator Date: 05 Apr 2008 20:01:57 +0400 Lines: 89 Message-ID: <0vqod8onvd6.fsf@gmail.com> References: <884d1faa0803192322o7b9f58dfja181970fbe2f882e@mail.gmail.com> <884d1faa0803300533h181c323cv4a8d5ee9875ff059@mail.gmail.com> <884d1faa0803301138v1e84b867wfcc907cf86ccd20c@mail.gmail.com> <0vq4panf42u.fsf@gmail.com> <884d1faa0803310936i5703e01ck71798eff11a88993@mail.gmail.com> <0vqmyoeeca5.fsf@gmail.com> <884d1faa0804010847m1b0ad0a9v3b58360cf6037d90@mail.gmail.com> <0vq8wzxdyy9.fsf@gmail.com> <884d1faa0804020307m5abcdaa4waac3916bf6e8bff1@mail.gmail.com> <0vqtzikc6u8.fsf@gmail.com> <884d1faa0804041100j1cdf65c4j771a0203ce4aa4c5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89.175.165.2 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 Sender: news X-Virus-Checked: Checked by ClamAV on apache.org On the 0x41C day of Apache Harmony Okonechnikov Konstantin wrote: > Continue working on removing SCE. Have some questions: > What are "tau operations"? What does "tau prefix" mean? > And what about those nasty > warnings (necessary simplification) in genTauCheckNull etc? Oh, yeah, this is a big story :)) Everybody asks me about it, and I often forget the tricky details, so, referring to some explanations back in time sounds reasonable to me. Here the references are. One short explanation of TauDiv: [1]. Patent application for the tau framework [2] is more interesting. It is easy to explain the situation using chknull instruction (Op_TauCheckNull) as an example. suppose we have invokevirtual bytecode instruction. When invoked it should throw a NullPointerException if the class is null, you know. Here how it is represented in Jitrino HIR: chknull class1 -) tau1 ldvtable ((tau1)) class1 -) vtable1 ldvfnslot ((tau1)) vtable1::method -) address1 call ((tau1)) address1 params ldvtable and ldvfnslot abstract away the means to get the address of the method. chknull is of course at the end of the basic block, it throws the exception if class1 is null. so, why tau? suppose we want to move instructions in HIR to optimize the code. But we need to somehow keep in mind what instructions can be moved and how far. Here call instruction has a tau source operand produced by chknull ensuring that call is not moved above the definition of tau1, which is _exactly_ the same semantics as "nullcheck has to precede the call". Thus it is the way to describe such precedence rules in HIR. another example: ----------------------- chknull class1 -) tau1 ... call ((tau1)) ... chknull class2 -> tau2 ... call ((tau2)) ... ----------------------- CSE converts it to: ----------------------- chknull class1 -) tau1 ... call ((tau1)) ... ... call ((tau1)) ... ----------------------- which is a magic. Nullcheck was eliminated with CSE without prior knowledge about semantics of the nullchecks. The idea was invented specifically for such things: describing control flow dependencies using data flow dependencies. In the code you are referring to translator tries to optimise on the fly. For example, replacing code like this: MyClass m = null; m.run(); with: throw new NullPointerException(); And this is not a job of translator to do things like that. Simplifier does that, actually. TauSafe means that you canmove your instruction anywhere. TauUnsafe pins the instruction position. There are also tauedge and taupoint, I tend to forget these details, you can find more info in [2]. [1] http://thread.gmane.org/gmane.comp.java.harmony.devel/24471/focus=24474 [2] http://www.google.com/patents?id=Ht-XAAAAEBAJ&printsec=abstract&zoom=4&dq=tau+operations+compiler -- Egor Pasko