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: [vote] HARMONY-3363 - Alternative Bytecode Verifier
Date Thu, 31 May 2007 10:14:37 GMT
Thank you for explanations.

I'm not suggesting to reject a contribution. I like an idea of
Mikhail's algorithm which checks data flow, though I failed to
understand how subroutine boundaries in one pass. I missed any
reference to this in documentation as well.

> Accepting here does not mean this contribution will be the one and only
> bytecode verifier going forward.

We agreed to keep duplication out of Harmony. I personally believe we
need strong arguments for any duplication, and I do not see enough
arguments to have two verifiers.

Honestly, the thing I'm trying to avoid is a loss of my precious life
time. Currently I was looking into bugs in existing verifier, but
there are many other interesting things as well. I would be grateful
if any decision is taken on verifier replacement, merge, or whatever.

On 5/31/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Alexei Fedotov wrote:
> > What do you mean by accepting? Does it mean that you want to commit it?
> Accepting means that
>  - pmc members have had a chance to verify the basis of the contribution
> (through accompanying paperwork that is not generally available to all)
>  - everyone gets a chance to express an opinion about whether the
> contribution is in keeping with the goals of the project
> We are interested in any reason why people think we should not accept
> this code.  The vote is conducted in public so everyone gets a voice.
> We just ask that if you vote 'reject' you also tell us why.
> Once accepted the code can be committed into our SVN repository, but
> that is not the end of the discussion and evaluation.  Collectively we
> may then decide that the contribution is new functionality that simply
> adds to the existing body of code, or that we should replace existing
> functionality with the incoming contribution, or that we maintain it as
> an alternative implementation, etc.
> Accepting here does not mean this contribution will be the one and only
> bytecode verifier going forward.
> Regards,
> Tim

With best regards,
ESSD, Intel

View raw message