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 Thu, 09 Nov 2006 05:50:06 GMT
On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote:
> I don't care about "cool", nor do I have any urge to separate jet if
> it's not separable.
> 
> That said, I care about portability.

> How hard will it be to port jet and opt to a new chip - say PPC?

Experience shows that JET is much easier to port. 

Some interesting offtopic: OPT would have to acquire one more code
generator, which is a long story (you can watch how IPF is developing
to make sure how much work it is). Setting aside the Optimizer
tuning...

With current structure, there is no problem to enable JET only. Just
write an .emconf file. That is, I do not see any portability issue here.

> geir
> 
> 
> Egor Pasko wrote:
> > 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