harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elena Semukhina" <elena.semukh...@gmail.com>
Subject Re: [drlvm]kernel test
Date Tue, 28 Nov 2006 07:04:35 GMT
On 11/28/06, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
>
> Elena,
> As far as I understand from your letter the implementation is still to
> be fixed. Could you please file a JIRA about it?


I'm not sure that the implementation is to be fixed as it does not
contradict the spec for now :)
Possibly we should fix the test so that it waits e.g. 10% less. Anyway, I've
filed http://issues.apache.org/jira/browse/HARMONY-2204 some time ago for
this problem. The patch I suggested is invalid because the test continues
failing with new timing numbers (I gave 1 ms of freedom but this was not
enough).

Geir,
> As for the best of my knowledge there are no reliability runs for
> kernel tests. This case proves that trying to run these tests in a
> loop, especially in one JVM could be useful for detecting new
> implementation flaws.


It is me who runs these tests iteratively for the last week. The runs proved
that ThreadTest fails sporadically on waiting in join() and sleep() methods
on Windows and in yield() on linux. I'll file aJIRA issue for the latter.

Thanks,
Elena

--
> Thank you,
> Alexei
>
>
> On 11/27/06, Elena Semukhina <elena.semukhina@gmail.com> wrote:
> > On 11/28/06, Elena Semukhina <elena.semukhina@gmail.com> wrote:
> > >
> > > The problem with ThreadTest has not been fixed yet. I'm running this
> test
> > > iteratively now to see the sporadic failures. Indeed,
> testJoinlongint()
> > > fails rather often. The spec for join() reads that it should wait at
> most
> > > millis milliseconds for this thread to die. But the thread which is
> > > joining in the test does not stop
> > >
> >
> > The obvious typo: I meant "the thread which is joined".
> >
> >
> >  running. Can we allow join() to exit earlier in this case?
> > >
> >
> > I modified the test so that to let join() wait  for10 ms less (which
> > is 0.5%of waiting time) and ran it again iteratively. It failed once
> > with 1972 ms
> > of waiting!
> >
> > I looked through RI's bug database for relevant issues and found the
> > following:
> >
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4132653
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5068368
> >
> > The last comment of the latter says that the spec will be fixed in Java
> SE
> > 6.0!
> >
> > BTW, the test always passes on linux for me.
> >
> > Thanks,
> > Elena
> >
> >
> > > On 11/28/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> > > >
> > > > I may have missed it, it's  very possible, could someone point me to
> the
> > > > fix
> > > > or the thread ? My comments are based on what's in Harmony drlvm
> trunk
> > > > as of
> > > > a few hours ago.
> > > >
> > > > Thanks,
> > > > Rana
> > > >
> > > >
> > > > On 11/27/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> > > > >
> > > > > I thought this exact problem was identified and already fixed...
> > > > >
> > > > > geir
> > > > >
> > > > > Rana Dasgupta wrote:
> > > > > > Hi,
> > > > > >   On Windows XP, java.lang.ThreadTest ( testJoinlongint
> component )
> > > > > keeps
> > > > > > failing for me sporadically. Debugging this, I saw that the
> problem
> > > > was
> > > > > > with
> > > > > > the expiry interval on thread.join(millis, nanos ). Tests based
> on
> > > > timed
> > > > > > waits are somewhat unpredictable on most platforms.
> > > > > >  In condvar_wait_impl(), we seem to set up the timeout interval
> in
> > > > > > microseconds before calling apr_thread_cond_timeout(). On
> Windows,
> > > > > > apr_thread_cond_timeout() implements using WaitForSingleObject(
> > > > event,
> > > > > > timeout )....but the Windows timeout is in milliseconds, as
far
> as I
> > > >
> > > > > know.
> > > > > > Is this not an error, or am I missing something? I did not want
> to
> > > > > change
> > > > > > anything since condvar_wait_impl() is on the code path of
> several
> > > > timed
> > > > > > waits.
> > > > > >  Also, on a less important note, the tests testJoinLong() and
> > > > > > testJoinLongint() seem to test to see that the thread.join
> (milli,
> > > > nano)
> > > > > > timeout is "at least" equal to the specified interval. My
> > > > understanding
> > > > > is
> > > > > > that this should be "at most" the specified interval. Any ideas?
> > > > > >
> > > > > > Thanks,
> > > > > > Rana
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Thanks,
> > > Elena
> >
> >
> >
> >
> > --
> > Thanks,
> > Elena
> >
> >
>
>
> --
> Thank you,
> Alexei
>



-- 
Thanks,
Elena

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message