[drlvm][jit] Moving jet to the top level of drlvm...

[Pavel Pervov <pm...@gmail.com>]

Hello, community,

Working through DRLVM sources I (once again) looked at organization of
jitrino code.

Actually, there are two JITs hidden inside "jitrino": JET and OPT.

As far as I may observe - these two are code-independent from each other.

JIT-guys, could you comment?

If I'm right here I would vote for moving them to top level of
drlvm/trunk/vm directory to clearly indicate we have two JITs in DRLVM.

-- 
Pavel Pervov,
Intel Enterprise Solutions Software Division

Re: [drlvm][jit] Moving jet to the top level of drlvm...

[Xiao-Feng Li <xi...@gmail.com>]

Ok, thanks for the info. :-) -xiaofeng

On 11/7/06, Mikhail Fursov <mi...@gmail.com> wrote:
> On 11/7/06, Xiao-Feng Li <xi...@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.
> >
>
> Xiao-Feng,
> This is offtopic, but I want to notice that EM does not distinguish OPT
> instances too: see server.emconf it has 2 Jitrino.OPT JITs. They are all
> separate and independent JIT instances for for EM.
>
> --
> Mikhail Fursov
>
>

Re: [drlvm][jit] Moving jet to the top level of drlvm...

[Mikhail Fursov <mi...@gmail.com>]

On 11/7/06, Xiao-Feng Li <xi...@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.
>

Xiao-Feng,
This is offtopic, but I want to notice that EM does not distinguish OPT
instances too: see server.emconf it has 2 Jitrino.OPT JITs. They are all
separate and independent JIT instances for for EM.

-- 
Mikhail Fursov

Re: [drlvm][jit] Moving jet to the top level of drlvm...

[Egor Pasko <eg...@gmail.com>]

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 <xi...@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 <pm...@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

Re: [drlvm][jit] Moving jet to the top level of drlvm...

["Geir Magnusson Jr." <ge...@pobox.com>]

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 <xi...@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 <pm...@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
>>>>
>>>>
> 

Re: [drlvm][jit] Moving jet to the top level of drlvm...

[Egor Pasko <eg...@gmail.com>]

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 <xi...@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 <pm...@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

Re: [drlvm][jit] Moving jet to the top level of drlvm...

[Pavel Ozhdikhin <pa...@gmail.com>]

-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 <xi...@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 <pm...@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
> >
> >
>

Re: [drlvm][jit] Moving jet to the top level of drlvm...

[Xiao-Feng Li <xi...@gmail.com>]

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 <pm...@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
>
>

Re: [drlvm][jit] Moving jet to the top level of drlvm...

[Pavel Pervov <pm...@gmail.com>]

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

Re: [drlvm][jit] Moving jet to the top level of drlvm...

[Rana Dasgupta <rd...@gmail.com>]

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.
Also, Mikhail and Alex are the best people to decide on this.They are
literally the two people who know this code best :-)

Re: [drlvm][jit] Moving jet to the top level of drlvm...

[Alex Astapchuk <al...@gmail.com>]

Geir Magnusson Jr. wrote:
> 
> 
> Alex Astapchuk wrote:
>> Pavel Pervov wrote:
>>> Hello, community,
>>>
>>> Working through DRLVM sources I (once again) looked at organization of
>>> jitrino code.
>>>
>>> Actually, there are two JITs hidden inside "jitrino": JET and OPT.
>>>
>>> As far as I may observe - these two are code-independent from each 
>>> other.
>>>
>>> JIT-guys, could you comment?
>>>
>>> If I'm right here I would vote for moving them to top level of
>>> drlvm/trunk/vm directory to clearly indicate we have two JITs in DRLVM.
>>
>> There are no two JITs, actually. We call them 'compilation paths'.
>> 'jet' here stands for 'Jitrino Express compilation paTh'.
>>
>> As Mikhail already mentioned they share significant parts like
>> logging, PMF, multi-threaded stuff, guard locks, etc.
>>
>> The difference in codebases, came from their targets - the .jet was 
>> heavily tuned for very fast compilation, resulting to that many virtual
>> interfaces used in .opt were substituted with direct calls to VM.
>>
>> Personally, I don't see any *practical* reason to separate .jet and .opt.
>>
> 
> The practical reason is to start convincing ourselves of the modularity.

Ugh. 'Modularity' is good word, I like it.
Especially taking into account that no one can measure it. Can you? :-)

Moving jet around will give nothing useful. Neither in a short-term nor 
in a longer perspective. But will take an efforts and add a mess and 
maybe code duplicate from Jitrino codebase.

Jitrino itself is modular enough - again, the JET was not intended as a 
separate JIT. It's only purpose was (and still is) to be a front-line 
for Jitrino's main engine - to speed up client apps startup.

Absolutely no reason to have it separately.

-- 
Thanks,
   Alex

Re: [drlvm][jit] Moving jet to the top level of drlvm...

["Geir Magnusson Jr." <ge...@pobox.com>]

Alex Astapchuk wrote:
> Pavel Pervov wrote:
>> Hello, community,
>>
>> Working through DRLVM sources I (once again) looked at organization of
>> jitrino code.
>>
>> Actually, there are two JITs hidden inside "jitrino": JET and OPT.
>>
>> As far as I may observe - these two are code-independent from each other.
>>
>> JIT-guys, could you comment?
>>
>> If I'm right here I would vote for moving them to top level of
>> drlvm/trunk/vm directory to clearly indicate we have two JITs in DRLVM.
> 
> There are no two JITs, actually. We call them 'compilation paths'.
> 'jet' here stands for 'Jitrino Express compilation paTh'.
> 
> As Mikhail already mentioned they share significant parts like
> logging, PMF, multi-threaded stuff, guard locks, etc.
> 
> The difference in codebases, came from their targets - the .jet was 
> heavily tuned for very fast compilation, resulting to that many virtual
> interfaces used in .opt were substituted with direct calls to VM.
> 
> Personally, I don't see any *practical* reason to separate .jet and .opt.
> 

The practical reason is to start convincing ourselves of the modularity.

geir

> 

Re: [drlvm][jit] Moving jet to the top level of drlvm...

[Alex Astapchuk <al...@gmail.com>]

Pavel Pervov wrote:
> Hello, community,
> 
> Working through DRLVM sources I (once again) looked at organization of
> jitrino code.
> 
> Actually, there are two JITs hidden inside "jitrino": JET and OPT.
> 
> As far as I may observe - these two are code-independent from each other.
> 
> JIT-guys, could you comment?
> 
> If I'm right here I would vote for moving them to top level of
> drlvm/trunk/vm directory to clearly indicate we have two JITs in DRLVM.

There are no two JITs, actually. We call them 'compilation paths'.
'jet' here stands for 'Jitrino Express compilation paTh'.

As Mikhail already mentioned they share significant parts like
logging, PMF, multi-threaded stuff, guard locks, etc.

The difference in codebases, came from their targets - the .jet was 
heavily tuned for very fast compilation, resulting to that many virtual
interfaces used in .opt were substituted with direct calls to VM.

Personally, I don't see any *practical* reason to separate .jet and .opt.


-- 
Thanks,
   Alex

Re: [drlvm][jit] Moving jet to the top level of drlvm...

[Pavel Pervov <pm...@gmail.com>]

It was Class.h actually... :)

I'm afraid if I do that, those supporting JITs will come after me, and I
won't write any more to this list.

P.S. It might be not that bad from someones POV, but I would prefer staying
alive...

On 11/3/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
>
> Pavel Pervov wrote:
> > Hello, community,
> >
> > Working through DRLVM sources I (once again) looked at organization of
> > jitrino code.
> >
> > Actually, there are two JITs hidden inside "jitrino": JET and OPT.
> >
> > As far as I may observe - these two are code-independent from each
> other.
> >
> > JIT-guys, could you comment?
> >
> > If I'm right here I would vote for moving them to top level of
> > drlvm/trunk/vm directory to clearly indicate we have two JITs in DRLVM.
> >
>
> That's cool, and helps show that the jit is pluggable.  But lets not go
> through the same saga as the jni.h cleanup :)
>
> before you submit a big patch, lets sketch it out, and maybe it's
> something someone can "just do".
>
> geir
>
>


-- 
Pavel Pervov,
Intel Enterprise Solutions Software Division

Re: [drlvm][jit] Moving jet to the top level of drlvm...

["Geir Magnusson Jr." <ge...@pobox.com>]

Pavel Pervov wrote:
> Hello, community,
> 
> Working through DRLVM sources I (once again) looked at organization of
> jitrino code.
> 
> Actually, there are two JITs hidden inside "jitrino": JET and OPT.
> 
> As far as I may observe - these two are code-independent from each other.
> 
> JIT-guys, could you comment?
> 
> If I'm right here I would vote for moving them to top level of
> drlvm/trunk/vm directory to clearly indicate we have two JITs in DRLVM.
> 

That's cool, and helps show that the jit is pluggable.  But lets not go 
through the same saga as the jni.h cleanup :)

before you submit a big patch, lets sketch it out, and maybe it's 
something someone can "just do".

geir

Re: [drlvm][jit] Moving jet to the top level of drlvm...

[Mikhail Fursov <mi...@gmail.com>]

On 11/3/06, Pavel Pervov <pm...@gmail.com> wrote:
>
> Hello, community,
>
> Working through DRLVM sources I (once again) looked at organization of
> jitrino code.
>
> Actually, there are two JITs hidden inside "jitrino": JET and OPT.
>
> As far as I may observe - these two are code-independent from each other.
>
> JIT-guys, could you comment?


These JITs were written  independently, it's true. But they use common staff
like PMF, logging, EM abstraction. And day after day these JITs have more
interrelationship.
It's always a good idea to make components independent. And it's prematurely
to do it with Jitrino today: you will have a lot of design problems to solve
about stuff I listed above and spend a lot of time for it. So I'm +1 to do
it someday, but -1 to do it this year.  Because you can break more then get
here.



-- 
Mikhail Fursov