harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm][jit] Moving jet to the top level of drlvm...
Date Tue, 07 Nov 2006 07:51:22 GMT
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


Mime
View raw message