harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [general] GSoC 2008 Refactor Java Bytecode Translator
Date Sat, 05 Apr 2008 15:13:39 GMT
On the 0x41A day of Apache Harmony Alexei Fedotov wrote:
> Egor, Kostya,
> 
> Let me make my point a bit more precise: I'm afraid that the abstract
> grammar is the only thing we may reuse among components efficiently.
> So, reusability and generators are not two different tasks: generator
> is a possible approach to reusability.
> 
> From a technical point of view ASN.1 is used for parsing a binary
> stream in runtime. It is quite efficient to populate C structures with
> data.

in case of bytecode ASN.1 structures will be linear cequences. No
tricky nested structures like those ASN.1 is good to parse. I see no
point in ASN.1 here. But you still have a chance to onvince me
otherwise :)

> Thanks!
> 
> On 02 Apr 2008 11:52:25 +0400, Egor Pasko <egor.pasko@gmail.com> wrote:
> >
> > On the 0x41A day of Apache Harmony Okonechnikov Konstantin wrote:
> >  > On 4/2/08, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> >  > >
> >  > > One more idea on further rewriting.
> >  > > 1. An old verifier built some IR on the top of bytecode.
> >  > > 2. A new verifier also does parsing, but is more like JET.
> >  > >
> >  > > You may think of building a reusable component. I wonder if
> >  > > conventional parser generators or ASN.1 are applicable here. Note,
> >  > > thinking is different from starting doing, there are cases when a
> >  > > specific solution is better than reusable.
> >  > >
> >  > >
> >  > >
> >  > > On Wed, Apr 2, 2008 at 3:02 AM, Alexei Fedotov <alexei.fedotov@gmail.com>
> >  > > wrote:
> >  > > > Hello, Kostya,
> >  > > >
> >  > > >  Do you think it would be good to reflect Egor's (and mine) idea
of an
> >  > > >  evolutionary path during learning period during the first step
of your
> >  > > >  plan? Namely, incremental approach to IR separation are subsequent
> >  > > >  patches to the existing code base. Each of the patches does the
> >  > > >  following:
> >  > > >  1. Removes some optimization from the parsing stage.
> >  > > >  2. Adds necessary infrastructure to HIR.
> >  > > >  3. Adds or ensures that the optimization is done on HIR.
> >  > > >
> >  > > >  This would help attacking the problem and learning a parser, HIR
and
> >  > > >  tools incrementally. On completion of this step you would have
your
> >  > > >  code committed to Harmony and get more confidence. Moreover the
code
> >  > > >  which enhances HIR would be close to final. In process you will
learn
> >  > > >  why the existing IR builder is bad and grow a desire to attack
it
> >  > > >  fully rewriting the code.
> >  > > >
> >  > > >  What do you think?
> >  > > >
> >  > >
> >  > > Hi, Alexei!
> >  > I like this approach with "first steps".
> >  > Actually I have already started with IRBuilder refactoring and completely
> >  > removed Simplifier from the code, tested on HelloWorld. (maybe I
> >  > should try more complicated tests) Now
> >  > I work on  removing SCE now. Then there will be the first patch.
> >  > But it suprises me that IRBuilder should be completely rewritten!
> >
> >  I did not see anybody say so. I do not think that IRBuilder should be
> >  rewritten. As you figured out, removing CSE and Simplifier from
> >  IRBuilder makes IRBuilder better. So, let's do just that.
> >
> >
> >  > I thought the problem was only with translator... I suppose when I am
> >  > finished with IRBuilder refactoring, to start prepass and data analisys (as
> >  > Egor advised), so on... and later to use IRBuilder in new translator.
> >
> >  sounds like a plan :)
> >
> >
> >  > P.S. About verifier and parser generators: I will ivestigate this
> >  > problem carefully.
> >
> >  My opinion on parser generators: Java bytecode structure was
> >  specifically designed for the ease and speed of parsing. Parser
> >  generators are usually used to parse tricker and much tricker
> >  grammars. Sounds like an overkill to use them.
> >
> >  --
> >  Egor Pasko
> >
> >
> 
> 
> 
> -- 
> With best regards,
> Alexei
> 

-- 
Egor Pasko


Mime
View raw message