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