harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [general] GSoC 2008 Refactor Java Bytecode Translator
Date Thu, 27 Mar 2008 22:10:55 GMT
I'm sorry. Please, disregard the previous letter.

On Fri, Mar 28, 2008 at 1:09 AM, Alexei Fedotov
<alexei.fedotov@gmail.com> wrote:
> And if these baby steps
>
>
>
>  On 27 Mar 2008 21:17:58 +0300, Egor Pasko <egor.pasko@gmail.com> wrote:
>  > On the 0x413 day of Apache Harmony Okonechnikov Konstantin wrote:
>  >  > Well, there are some questions.
>  >  > [IrBuilder]
>  >  >   If we clean out simplification, it wont affect the functionality of
>  >  > instructions, will it? (i.e.will OPT work without these simplifications?
>  >  > I ve tried to clean some instructions, it seems everything is OK (HelloWorld
>  >  > works) )
>  >
>  >  Ideally everything should work if we disable simplification. Although
>  >  I remember some problems running Eclipse solely on OPT with
>  >  simplification disabled. That was a long time ago, and if it appears,
>  >  that's a bug.
>  >
>  >
>  >  > I 've written sort of plan. Check this out.
>  >  > 1) Clean up IRBuilder
>  >  >   -remove Simplifier and its methods
>  >
>  >  sounds good
>  >
>  >
>  >  > 2) Move all simplification to Optimizer stage
>  >  >    (this is quite big task as I suppose, lots of instructions use
>  >  > simplification. Not sure if we should create separate action for every
>  >  > simplification....)
>  >  > 1 and 2 should be implemented concurrently
>  >
>  >  actually there is a stage called 'simplify' already that in fact uses
>  >  the same simplifier. So, it is not a huge work, need to ask somebody
>  >  to check performance of disabling simplification in translator and
>  >  running it from HLO right after the translator (with dead code
>  >  eliminator, blablabla).
>  >
>  >
>  >  > 3) Develop the translator
>  >  >     -  new PrePass (maybe from Jet?)
>  >  >
>  >  >     - implement data analisys, parser etc...
>  >  >
>  >  > Where am I mistaken? I will appreciate any additions and(or) corrections.
>  >
>  >  Kostya, thanks a lot for the draft plan! I have been quite busy and
>  >  could not discuss it with you earlier. Sorry for that. I like your
>  >  pro-active approach very much, please continue behave like that :)
>  >
>  >  Although, I have somewhat different views on the plan, those views are
>  >  more like discussable than final :) So, plz, do not take personally if
>  >  I just ruined your best dreams about the process))
>  >
>  >  TA-DAA! Here my suggestion goes..
>  >
>  >  I would recomend to hack the whole code starting from a small and
>  >  limited implementation and grow functionality doing small baby
>  >  steps. So, you would not need to implement the rock solid data flow
>  >  analysis at once. Just write one that looks beautiful by design, does
>  >  not support non-interesting instructions as well as difficult stuff
>  >  like exceptions, loops and JSR/RET, put asserts in places, where you
>  >  do not support something.
>  >
>  >  Then grow functionality until you can run HelloWorld. Constantly
>  >  ensuring that the code looks good and we love it.
>  >
>  >  This can be split into several sub-steps:
>  >
>  >  0. move simplifier out of IRBuilder, basically fix HARMONY-5500 or
>  >    determine that it is not a part of our work if it unexpectedly
>  >    wants to eat too much time :)
>  >
>  >  1. draft code that does prepass and data flow analysis in code _without_
>  >    loops, exceptions, call instructions
>  >  1.1. prepass
>  >  1.2. data flow analysis
>  >  1.3. bytecode mapping
>  >
>  >  2. support call instructions and lazy resolution
>  >
>  >  3. with loops
>  >
>  >  4. with exceptions and loops
>  >
>  >  5. make sure Hello World works and fix bugs when it does not ;)
>  >
>  >  6. JSR/RET support
>  >
>  >  7. inliner support
>  >
>  >  8. make sure all tests and eclipse work in -Xem:opt mode
>  >  8.1. bytecode without JSR/RET
>  >  8.2. bytecode obtained by ECJ (with JSR/RET)
>  >
>  >  9. write barriers (?), other features...
>  >
>  >  10. what I forgot
>  >
>  >  (I am yet not sure about the order, though, pick what you want to do
>  >  first)
>  >
>  >  Let's review the code between steps, speak about it, think what we do
>  >  next and how. It also makes sense to review the code more often, once
>  >  noticeable features are implemented or code is refactored.
>  >
>  >  My picture is that we will commit it into a separate directory, your
>  >  code can be running via tweaked emconf file. That is because I do not
>  >  like branches :)
>  >
>  >  I separated exceptions, loops, resolution stuff because I think it
>  >  will let us better concentrate on coding in the early stages (what
>  >  else to separate?). Additionally, I think, exception support needs
>  >  little change. It has been completely rewritten once, looks not so bad
>  >  (although scattered around) and no bugs were found in it since
>  >  then. So, just move the code carefully. Same picture with JSR/RET
>  >  support. Looks like no need to rewrite.
>  >
>  >  Why is this approach worth trying? Because you can test the code while
>  >  writing. Make an emconf that uses your code on methods with supported
>  >  bytecodes and use JET or older OPT for others.
>  >
>  >  Sounds good?
>  >
>  >  --
>  >  Egor Pasko
>  >
>  >
>
>
>
>  --
>  With best regards,
>  Alexei
>



-- 
With best regards,
Alexei

Mime
View raw message