harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [drlvm][kernel & exception handling] several issues
Date Tue, 03 Oct 2006 14:29:39 GMT
Sure, this can wait - say, until classlib tests 100% pass on DRLVM, -
just to let current pace of major changes slow down.
Other than that, I see no compelling reasons to maintain duplicate
impl in DRLVM.
And you bet the reference impl in classlib is mature enough to not
affect VM stability ;)

--
Alexey

2006/10/3, Geir Magnusson Jr. <geir@pobox.com>:
> I tend to agree. I think that it's a good idea to consider for the
> future, but right now, if the fixes help stabilize, great.  I think that
>  stabilization is key right now.
>
> geir
>
>
> Serguei Zapreyev wrote:
> > On 10/3/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> >>
> >> 2006/10/3, Serguei Zapreyev <sergueiszapreyev@gmail.com>:
> >> > Dear committers,
> >> >
> >> >
> >> >
> >> > I filed recently the HARMONY-1573, -1650, -1651, -1654 issues with the
> >> > suggested patches.
> >> >
> >> > So, to avoid redoubling efforts or superposition of commits because of
> >> delay
> >> >
> >> > could somebody take them under a control to estimate and apply if it is
> >> > necessary?
> >> >
> >> > All the more, the 1650 and 1573 issues seem to be able to upset somehow
> >> the
> >> > execution stability of a big application.
> >>
> >> Serguei,
> >>
> >> the HARMONY-1573 is mostly about j.l.Process impl. I believe we shoud
> >> consider reusing
> >> org\apache\harmony\luni\internal\process\SystemProcess.java available
> >> in luni rather than fixing alternative impl in DRLVM.
> >> What do you think?
> >
> >
> > Alexey,
> >
> > I guess few items should be took into consideration before doing some
> > conclusions here.
> >
> > First, DRLVM's implementation of Runtime has been checked during a lot of
> > testing milestones.
> > Second, its code is well known for DRLVM developers, so it's easy to
> > maintain it in this hot time.
> > Third, we have no good test set (like TCK) to compare the discussed impls.
> > Forth, we have no methods to estimate performance of impls.
> > ...
> >
> > So, I think your suggestion isn't too actual just now and may be considered
> > some later.
> > There is no need to upset the current stability just now.
> > I think the attached patches should be applayed in the nearest time to
> > improve the
> > used code. All the more, this patch combines some issues apart from the
> > Process.
> >
> > Thanks,
> > Serguei
> >
> > --
> >> Regards,
> >> Alexey
> >>
> >> >
> >> > Great thanks in advance,
> >> >
> >> > Serguei
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message