harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Wu" <wuyue...@gmail.com>
Subject Re: [classlib]remove the duplicate locale data
Date Wed, 30 Jan 2008 08:41:55 GMT
Thanks. It will be helpful if you can give me some clue on this problem.

It's true that I can revert it this time and every time in future, but
it does not solve the problem. What I want is to find the root cause
and fix it rather than worm out of.

On 1/30/08, Aleksey Shipilev <aleksey.shipilev@gmail.com> wrote:
> Tony,
>
> Rustem had an input on stability earlier.  My runs show that there's
> different types of intermittent hang-ups on SPECjbb2005, presumably
> with this commit, since manual reverting of 612718 commit helps to
> solve this problem.
>
> More to follow.
>
> Thanks,
> Aleksey.
>
> On Jan 30, 2008 11:12 AM, Tony Wu <wuyuehao@gmail.com> wrote:
> > Could you please give me more infomation on the stability? I'd like to
> > help on this.
> >
> >
> > On 1/30/08, Tony Wu <wuyuehao@gmail.com> wrote:
> > > Hi,
> > >
> > > what do you mean about the great reduce on stability?
> > >
> > > I noticed 2 JIRAs here, HARMONY-5436 is a minor difference between RI
> > > and ICU's MessageFormat, I can work around it in 1 minute.
> > >
> > > And HARMONY-5435 is an  intermittent crash but I haven't got any crash
> > > on my winxp desktop when running specJBB for a whole day.
> > >
> > > On 1/30/08, Aleksey Shipilev <aleksey.shipilev@gmail.com> wrote:
> > > > Tony,
> > > >
> > > > Since this patch is known to greatly reduce stability, can we revert
> > > > it for a while?
> > > >
> > > > Thanks,
> > > > Aleksey.
> > > >
> > > > On Jan 28, 2008 7:34 PM, Ilya Berezhniuk <ilya.berezhniuk@gmail.com>
wrote:
> > > > > Hi Tony,
> > > > >
> > > > > I've found yet another issue in EUT caused by r612718.
> > > > > ("Invalid name specified: {0}" is returned instead of "Invalid name
> > > > > specified: null")
> > > > >
> > > > > Issue is filed as HARMONY-5436.
> > > > >
> > > > > Thanks,
> > > > > Ilya.
> > > > >
> > > > > 2008/1/28, Tony Wu <wuyuehao@gmail.com>:
> > > > >
> > > > > >
> > > > > > Ok, investigating.
> > > > > >
> > > > > > On 1/28/08, Rustem Rafikov <r.v.rafikov@gmail.com> wrote:
> > > > > > > Hi Tony,
> > > > > > >
> > > > > > > Please look at another issue connected with the ICU commit.
> > > > > > > https://issues.apache.org/jira/browse/HARMONY-5435
> > > > > > > It has not been investigated deeply yet.
> > > > > > >
> > > > > > > --Rustem
> > > > > > >
> > > > > > >
> > > > > > > On Jan 28, 2008 6:49 AM, Tony Wu <wuyuehao@gmail.com>
wrote:
> > > > > > >
> > > > > > > > They are all caused by different implementation of
DateFormat, which
> > > > > > > > I've recorded on wiki. I think they are acceptable
unless it breaks
> > > > > > > > some real product.  See following output, they have
the same meaning
> > > > > > > > but don't exactly equal on text.
> > > > > > > >
> > > > > > > > Result:   'text here 12:17:01 PM GMT+00:00 and here'
> > > > > > > > Expected: 'text here 12:17:01 UTC PM and here'
> > > > > > > >
> > > > > > > > Result:   'text here 3:16:03 PM GMT+00:00 and here'
> > > > > > > > Expected: 'text here 3:16:03 o'clock PM UTC and here'
> > > > > > > >
> > > > > > > > Result:   'text here 00-04-05 and here'
> > > > > > > > Expected: 'text here 05/04/00 and here'
> > > > > > > >
> > > > > > > > I'll open another thread to ask people's opinions
on this difference.
> > > > > > > >
> > > > > > > > On 1/25/08, Andrey Pavlenko <andrey.a.pavlenko@googlemail.com>
wrote:
> > > > > > > > > Tony,
> > > > > > > > >
> > > > > > > > > It looks like this commit caused a regression.
Could you take a look
> > > > > > at
> > > > > > > > > HARMONY-5430, please?
> > > > > > > > >
> > > > > > > > > On Jan 21, 2008 10:17 AM, Tony Wu <wuyuehao@gmail.com>
wrote:
> > > > > > > > >
> > > > > > > > > > Thanks, Aleksey and all
> > > > > > > > > >
> > > > > > > > > > patch committed at r612718. Then I'm going
to deal with the
> > > > > > non-bug
> > > > > > > > > > difference. Hopefully many legcy bugs/differences
can be fixed
> > > > > > this
> > > > > > > > > > time.
> > > > > > > > > >
> > > > > > > > > > On 1/17/08, Aleksey Shipilev <aleksey.shipilev@gmail.com>
wrote:
> > > > > > > > > > > Hi, guys!
> > > > > > > > > > >
> > > > > > > > > > > Sure, correctness is important, but
performance is important
> > > > > > too. I
> > > > > > > > > > > had profiled both versions (clean and
patched) and see no
> > > > > > > > significant
> > > > > > > > > > > difference there: there are more GC
happens what I believe
> > > > > > connected
> > > > > > > > > > > to internal ICU object creation and
such. So, there are no
> > > > > > obvious
> > > > > > > > way
> > > > > > > > > > > to maintain the same performance level,
and may be we will try
> > > > > > again
> > > > > > > > > > > to eliminate ICU usage from the hotpath
of frequently used
> > > > > > workloads
> > > > > > > > -
> > > > > > > > > > > but previous investigation shows it's
not that simple.
> > > > > > > > > > >
> > > > > > > > > > > Tony, please go ahead with committing
this patch, we will deal
> > > > > > with
> > > > > > > > > > > ICU performance issues a little later.
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Aleksey.
> > > > > > > > > > >
> > > > > > > > > > > On Jan 15, 2008 1:52 PM, Tony Wu <wuyuehao@gmail.com>
wrote:
> > > > > > > > > > > > Hi Aleksey,
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for you help.
> > > > > > > > > > > >
> > > > > > > > > > > > I've proved there is no performance
degradation on my machine
> > > > > > > > > > > > mentioned in my previous mail.
I suppose the different result
> > > > > > on
> > > > > > > > your
> > > > > > > > > > > > machine is caused by different
options to SpecJBB. Anyway, my
> > > > > > POV
> > > > > > > > is
> > > > > > > > > > > > that we should be willing to pay
for the adoption of ICU if we
> > > > > > > > have
> > > > > > > > > > > > to. All of us should be positive
on this point. I'd like to
> > > > > > > > clarify
> > > > > > > > > > > > the factors I'm facing below.
> > > > > > > > > > > >
> > > > > > > > > > > > Firstly, the original implementation
of harmony is faster but
> > > > > > > > > > > > incorrect. It is not reasonable
to keep the code as is and
> > > > > > refuse
> > > > > > > > to
> > > > > > > > > > > > correct it just because the bad
version has better
> > > > > > performance.
> > > > > > > > IMHO
> > > > > > > > > > > > performance is nothing if there
is no correctness.
> > > > > > > > > > > >
> > > > > > > > > > > > Secondly, we adopt ICU through
delegation which involves extra
> > > > > > > > method
> > > > > > > > > > > > calls than we implement it by
ourselves, it does harm to
> > > > > > > > performance
> > > > > > > > > > > > and can not be worked around.
But please do not forget we
> > > > > > benefit
> > > > > > > > from
> > > > > > > > > > > > ICU in bug fixing, maintenance,
smaller code size and so on.
> > > > > > > > > > > >
> > > > > > > > > > > > Lastly, branching does not make
sense to me. My fix is very
> > > > > > > > separate
> > > > > > > > > > > > in luni and text, I can not guarantee
that there is no
> > > > > > > > modification
> > > > > > > > > > > > during my work, so the synchronization
between HEAD and my
> > > > > > branch
> > > > > > > > is
> > > > > > > > > > > > required. Actually only I myself
am working on the development
> > > > > > > > work
> > > > > > > > > > > > (Surely, Aleksey is very helpful
on testing), this
> > > > > > synchronization
> > > > > > > > > > > > might be a nightmare to me. Furthermore,
the code on branch
> > > > > > will
> > > > > > > > not
> > > > > > > > > > > > be automatically tested by continuous
integration system and
> > > > > > BTI,
> > > > > > > > I do
> > > > > > > > > > > > not want to work without collaboration,
that's not an open
> > > > > > source
> > > > > > > > > > > > style, right? Will you ask a contributor
to create a branch
> > > > > > and
> > > > > > > > play
> > > > > > > > > > > > with himself whenever he wants
to contribute?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On 1/15/08, Mark Hindess <mark.hindess@googlemail.com>
wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 14 January 2008 at 16:21,
Tim Ellison <
> > > > > > t.p.ellison@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > > > > Aleksey Shipilev wrote:
> > > > > > > > > > > > > > > Yep, Tim, you're
right. I believe that new
> > > > > > implementation
> > > > > > > > fixes
> > > > > > > > > > a
> > > > > > > > > > > > > > > number of bugs
and will try to get it not degrading. I
> > > > > > just
> > > > > > > > want
> > > > > > > > > > to
> > > > > > > > > > > > > > > maintain the performance
level of current trunk on the
> > > > > > same
> > > > > > > > > > level,
> > > > > > > > > > > > > > > gradually fixing
functional bugs. I don't like to
> > > > > > sacrifice
> > > > > > > > > > > > > > > performance of
HEAD revision for non-critical bugfix.
> > > > > > That
> > > > > > > > is, I
> > > > > > > > > > want
> > > > > > > > > > > > > > > to see HEAD changes
like this:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > "high performance,
minor bug -> high performance, no
> > > > > > bugs"
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > rather than
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > "high performance,
minor bug -> low performance, no bugs
> > > > > > ->
> > > > > > > > high
> > > > > > > > > > > > > > > performance, no
bugs"
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > ...because anyone
could get the HEAD Harmony revision
> > > > > > for
> > > > > > > > > > > > > > > performance measurements
at any time.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Couldn't someone also get
the HEAD Harmony revision and
> > > > > > suffer
> > > > > > > > from
> > > > > > > > > > the
> > > > > > > > > > > > > known/fixable-with-Tony's-patch
bugs at any time?
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > What do you think?
> > > > > > > > > > > > >
> > > > > > > > > > > > > > For sure, improving
performance and fixing the bugs is the
> > > > > > > > most
> > > > > > > > > > > > > > desirable state.  I
actually don't mind some minor
> > > > > > performance
> > > > > > > > > > > > > > regression on HEAD between
releases provided it is an area
> > > > > > > > being
> > > > > > > > > > > > > > actively worked upon.
> > > > > > > > > > > > >
> > > > > > > > > > > > > +1 especially if it fixes
bugs
> > > > > > > > > > > > >
> > > > > > > > > > > > > > I'd also like to get
to 4.2Mb source code reduction too
> > > > > > ;-)
> > > > > > > > > > > > >
> > > > > > > > > > > > > Me too.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > If you and Tony are
happy to work on the patch to get it
> > > > > > > > perfect
> > > > > > > > > > then
> > > > > > > > > > > > > > go ahead.  I hope it
is not too troublesome to keep it in
> > > > > > > > synch.
> > > > > > > > > >  You
> > > > > > > > > > > > > > could also consider
a branch in SVN.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This bothers me too.  Firstly,
while it is being developed
> > > > > > in
> > > > > > > > patch
> > > > > > > > > > > > > on JIRA, it is likely only
Tony and Aleksey will really look
> > > > > > at
> > > > > > > > it.
> > > > > > > > > > > > > Secondly, that progress will
be slow because of the cost of
> > > > > > > > keeping
> > > > > > > > > > in
> > > > > > > > > > > > > sync - this applies to an
SVN branch too.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I can't help thinking we'll
make more progress if we apply
> > > > > > the
> > > > > > > > patch
> > > > > > > > > > to
> > > > > > > > > > > > > HEAD now.  We'll get wider
visibility of problems with the
> > > > > > new
> > > > > > > > code
> > > > > > > > > > -
> > > > > > > > > > > > > and there are likely issues
beyond the performance problems
> > > > > > that
> > > > > > > > > > have
> > > > > > > > > > > > > been the focus so far - and
more people will see the benefit
> > > > > > of
> > > > > > > > Tony
> > > > > > > > > > > > > (and Aleksey's) hard work
in getting us to this point.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I certainly don't want all
this work to be completed outside
> > > > > > svn
> > > > > > > > > > HEAD
> > > > > > > > > > > > > and committed a week or two
before the freeze for next
> > > > > > > > milestone.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Regards,
> > > > > > > > > > > > >  Mark.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > >
> > > > > > > > > > > > Tony Wu
> > > > > > > > > > > > China Software Development Lab,
IBM
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Tony Wu
> > > > > > > > > > China Software Development Lab, IBM
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Tony Wu
> > > > > > > > China Software Development Lab, IBM
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Tony Wu
> > > > > > China Software Development Lab, IBM
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Tony Wu
> > > China Software Development Lab, IBM
> > >
> >
> >
> > --
> >
> > Tony Wu
> > China Software Development Lab, IBM
> >
>


-- 
Tony Wu
China Software Development Lab, IBM

Mime
View raw message