harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm][jit] Moving jet to the top level of drlvm...
Date Thu, 09 Nov 2006 01:30:15 GMT
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?

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
>>>>
>>>>
> 


Mime
View raw message