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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
