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][smoke tests] Enabling smoke tests
Date Tue, 12 Dec 2006 12:57:47 GMT
On 12/11/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
>
>
> Elena Semukhina wrote:
> > On 12/8/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> >>
> >> Nice work - I'm testing it now and will commit.  If someone can test
> >> today on x86_64, that would be great, or I will do it tomorrow
> >
> >
> > At last I managed to start the tests on x86_64 and they passed.
> > They still print something like
> >
> > test exception.FinalizeStackTest is skipped due to X_em64t
>
> I thought I fixed those.  Oh!  I may not have committed.
>
> >
> > I'll verify if this is still valid tomorrow.
>
> I found a bunch of tests breaking on x86_64.  Let me double check to see
> if I have all checked in.


Smoke tests look rather unstable today on SUSE 9 x86_64. They pass and fail
alternately.
I observed a number of failures (io.Integers, jni.LoadLibrary, gc.List,
gc.Free) with the same error message:

Assertion failed: 0
LIL INTERNAL ERROR: Not enough temporary registers
java:
/nfs/ins/proj/drl/coreapi/esemukhi/em64/drlvm/trunk/vm/port/src/lil/em64t/pim/lil_code_generator_em64t.cpp:204:
LcgEM64TCodeGen::Tmp_GR_Opnd::Tmp_GR_Opnd(LcgEM64TContext&,
LilInstructionContext*): Assertion `0' failed.
log4cxx: No appender could be found for logger (port.old).
log4cxx: Please initialize the log4cxx system properly.

Elena

geir
>
> >
> >
> > Elena
> >
> > geir
> >>
> >>
> >> Elena Semukhina wrote:
> >> > After a few days of runs I can conclude that almost 40 tests are
> valid
> >> and
> >> > should be removed from the exclude lists. I've prepared a patch to
> >> smoke
> >> > tests: https://issues.apache.org/jira/browse/HARMONY-2543
> >> >
> >> > After it is applied we'll have 3 stable issues:
> >> > 1) gc.Mark craches on Windows
> >> > 2) - 3)  stress.Stack and io.Integers will pass only on linux/JIT and
> >> fail
> >> > on other configurations because of StackOverflowError. Is it a known
> >> issue?
> >> >
> >> > We'll also have four tests failing intermittently. I plan to play
> with
> >> them
> >> > to get more details.
> >> >
> >> > All the above tests remain excluded.
> >> >
> >> > I prepared the update for ia32 platforms only because I don't have
> >> > access to
> >> > x86_64 machines for now. Hope to get it soon.
> >> >
> >> > I updated the http://wiki.apache.org/harmony/DRLVMInternalTests with
> >> new
> >> > details.
> >> >
> >> > Thanks,
> >> > Elena
> >> >
> >> >
> >> > On 12/7/06, Elena Semukhina <elena.semukhina@gmail.com> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On 12/7/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> >> >> >
> >> >> > 2006/12/6, Elena Semukhina <elena.semukhina@gmail.com>:
> >> >> > > On 12/5/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> >> >> > > >
> >> >> > > > How much total additional time would be needed to run
the
> tests
> >> >> that
> >> >> > are
> >> >> > > > excluded for "slowness" only?
> >> >> > >
> >> >> > >
> >> >> > > There are 11 tests marked as slow. They run about 30 sec
in JIT
> >> mode.
> >> >> > Only
> >> >> > > one of them is rather slow: gc.Mark (~15 sec).
> >> >> > >
> >> >> > > I compared the whole run duration on linux (JIT + interpreter).
> >> >> > Currently 26
> >> >> > > tests run for about 3 min 30 sec. Adding 42 tests from exclude
> >> list
> >> >> > > increases duration up to 11 minutes (1 min 40 sec for JIT).
> >> >> > >
> >> >> > > Is this time acceptable?
> >> >> >
> >> >> > Probably yes.Exact timings depend on hardware used; I guess the
> >> >> > figures above are on a laptop?
> >> >>
> >> >>
> >> >> No, 11 minutes are for multiprocessor machines (Windows/linux). On
a
> >> >> single processor desktop the tests run for 24 minutes :(  Most
> >> >> annoying is
> >> >> the interpreter mode. We can agree later that some slow tests
> >> should be
> >> >> excluded for interpreter.
> >> >>
> >> >> Anyway I need a couple of days to run the tests intensively to
> reveal
> >> all
> >> >> unstable issues.
> >> >>
> >> >> Elena
> >> >>
> >> >>
> >> >> Anyway let's try them over! Later if someone analyzed coverage, we
> can
> >> >> > re-balance pre-commit and CI tests.
> >> >> >
> >> >> > >
> >> >> > > Thanks,
> >> >> > > Elena
> >> >> > >
> >> >> > > Thanks,
> >> >> > > > Rana
> >> >> > > >
> >> >> > > >
> >> >> > > > On 12/5/06, Elena Semukhina <elena.semukhina@gmail.com
>
> wrote:
> >> >> > > > >
> >> >> > > > > We currently have more than 40 smoke tests in the
exclude
> >> list.
> >> >> > > > > I tried to run all of them on linux/Windows and
found out
> that
> >> >> > most of
> >> >> > > > > them
> >> >> > > > > stably pass.
> >> >> > > > > Those of them which have been marked with the "slow"
keyword
> >> >> don't
> >> >> > > > > actually
> >> >> > > > > run slow. They are not slower than an average smoke
test.
> Only
> >> >> few
> >> >> > of
> >> >> > > > them
> >> >> > > > > work about 10 seconds (comparing to 1-4 seconds
duration of
> >> any
> >> >> > other
> >> >> > > > > test).
> >> >> > > > >
> >> >> > > > > Only 3 tests stably fail and about 5 tests fail
> >> intermittently.
> >> >> > I've
> >> >> > > > added
> >> >> > > > > the details to the
> >> >> > > > http://wiki.apache.org/harmony/DRLVMInternalTestspage.
> >> >> > > > > I plan to file JIRA issues about failing tests
and to gather
> >> more
> >> >> > > > > statictics
> >> >> > > > > on intermittent failures.
> >> >> > > > >
> >> >> > > > > Does anybody object to removing most tests from
exclude
> lists
> >> and
> >> >> > bring
> >> >> > > > > them
> >> >> > > > > back to runs?
> >> >> > > > >
> >> >> > > > > --
> >> >> > > > > Thanks,
> >> >> > > > > Elena
> >> >> > > > >
> >> >> > > > >
> >> >> > > >
> >> >> > > >
> >> >> > >
> >> >> > >
> >> >> > > --
> >> >> > > Thanks,
> >> >> > > Elena
> >> >> > >
> >> >> > >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Thanks,
> >> >> Elena
> >> >
> >> >
> >> >
> >> >
> >>
> >
> >
> >
>



-- 
Thanks,
Elena

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