Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: harmony-dev@incubator.apache.org
From: Egor Pasko <egor.pasko@gmail.com>
Subject: Re: [drlvm][jit] Moving jet to the top level of drlvm...
Date: 07 Nov 2006 13:51:22 +0600
Lines: 90
Message-ID: <uzmb366f9.fsf@gmail.com>
References: <e0f125db0611030431p101cf8f8nd5d57f34a30fc353@mail.gmail.com>
 <eimivi$hr2$1@sea.gmane.org> <454F0CF7.3020702@pobox.com>
 <ein7ev$cch$1@sea.gmane.org>
 <51d555c70611060719o4a26a820p4b7d95eab0a41496@mail.gmail.com>
 <e0f125db0611061124p25098f9fmc6dd5660ffe0497@mail.gmail.com>
 <9623c9a50611061621o28ad2bc2rdbde91b724c1522e@mail.gmail.com>
 <469bff730611062237u156e82a3h5e1cf803a6757ff3@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Sender: news <news@sea.gmane.org>

Refactoring Pros:
* more "logical" structure, looking cool

Refactoring Cons:
* takes time
* "cool" look does not help to read the code
* more interfaces, possible code duplication
* many old patches become outdated because of massive file renaming

So, I am (-1) for that kind of refactoring.

I feel that nobody would benefit from additional "modularity" here
because nobody suffers from it's absence. Let's fix problems as
soon as they become relevant.

Now there is a lot of work on stability, compatibility, etc. Rhetoric:
Did we overcome all these hard issues and got a lot of time to discuss
minor beautifications?

On the 0x21A day of Apache Harmony Pavel Ozhdikhin wrote:
> -1 to separating Jitrino.JET and Jitrino.OPT.
> As Mikhail and Alex said, JET and OPT share their code in many areas. So, to
> achieve true modularity separating them we'll need either to duplicate
> shared code or "externalize" internal JIT interfaces. The former is
> definitely bad and the latter implies introducing some public JIT-JIT
> interface and putting the shared code top-level as well. This shared
> code actually might not be necessary for other JIT implementations. So I'd
> leave Jitrino dir as a home for the Jitrino family. Any new JIT
> implementation which won't re-use internal Jitrino code may go to the
> top-level dir.
> 
> Thank you,
> Pavel
> 
> 
> On 11/7/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> >
> > Agreed. Without the explanation of JET as only a fast path, I also
> > thought JET and OPT are two different JITs. And actually as I can
> > recall, JET and OPT are indeed treated as two different JITs that the
> > EM can select in the JITs chain.
> >
> > Honestly, "different paths" give me an impression that they are
> > different JITs, unless they share many common compilation steps
> > (passes). If they start from different IR and end in different
> > emitter, it would be hard to convince people they are only different
> > paths of the same JIT.
> >
> > But anyway, this is only my observation. JIT developers decide how to
> > modularize JIT.
> >
> > Thanks,
> > xiaofeng
> >
> > On 11/7/06, Pavel Pervov <pmcfirst@gmail.com> wrote:
> > > >
> > > > Jet is a startup fast compilation path, not a seperate pluggable jit.
> > So,
> > > > while modularity and seperation are important requirements,  they may
> > not
> > > > be
> > > > needed here.
> > >
> > >
> > > JET can work standalone (-Xem:jet specified), OPT can work standalone
> > > (-Xem:opt), so from "outside" POV they are independent. Also, correct me
> > if
> > > I'm wrong, OPT does not reuse the results of JET compilation when
> > > recompiling methods - it has its own completely independent pipeline.
> > >
> > > We have lots of GCs now but we only have one JIT although modularity
> > concept
> > > of DRLVM allows to create different JITs.
> > >
> > > Also, Mikhail and Alex are the best people to decide on this.They are
> > > > literally the two people who know this code best :-)
> > >
> > >
> > > Sure they are. That's why I've asked. They both have opposite POVs
> > though.
> > >
> > > --
> > > Pavel Pervov,
> > > Intel Enterprise Solutions Software Division
> > >
> > >
> >

-- 
Egor Pasko