harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm] run of smoke tests on overloaded box
Date Thu, 17 May 2007 18:18:36 GMT
The test does not have a lot of value any more. The only small value
it may have is as a correctness test for the developer that the VM is
actually suspending the threads ( in our case, one suspendable thread
and the other compute intensive but suspended by BBP ), and that his
local change has not broken it. For example the output with RI shows
that the test fails ( even without the parallel CPU loader ) because
with default options the RI probably does not use BBP and the
unsuspendable computation thread does not get suspended( it prints its
completion message ).
I agree that using wall clock time is not a good idea, maybe the test
should check that the worker threads don't need to finish their
computations for gc to complete. Running wall clock based tests ( more
than one of our smoke tests )with a parallel cpu eater is somewhat
pointless.
The SIGSEGV is interesting specially since Vladimir's <system-out>
...PASS...</system-out> shows that the test has passed! I hope this is
not a problem with VM shutdown when multiple jvm instances are
running!

On 5/17/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> A typo below: "The assumption that a computation-intensive loop can be
> GC-safe is already invalid." Should be "The assumption that a
> computation-intensive loop can not be GC-safe is already invalid."
>
> Btw, although I suggest to remove this gc.ThreadSuspend test from test
> suite, I don't know why this "SIGSEGV in VM code" could happen.  Looks
> like all of them (except one) have result code 139, which I assume
> means SIGSEGV.
>
> Thanks,
> xiaofeng
>
> On 5/17/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > I have had a closer look at gc.ThreadSuspension. I have to say this
> > test is not very meaningful now. It depends its behavior on strict
> > timing. That is, the main thread will wait for 3 seconds, then to
> > check if a GC ( invocation of System.gc() ) is finished by another
> > slave thread. If it's not finished, the test fails.
> >
> > This means, it requires the slave thread to finish all its work in 3
> > seconds of wall time. This is not very reasonable because the slave
> > thread may not be able to get any processor cycle  to execute its work
> > during the 3 seconds of wall time. When you have processor cycle eater
> > running aside, it's highly possible to fail this test.
> >
> > The real design intention of this test is to check if the VM can
> > suspend multiple Java threads for GC within a limit period, say, 1
> > second. When it fails, it assumes that's because VM couldn't suspend
> > the Java threads. But this is not the case in your tests.
> >
> > I think this test is not very meaningful currently, since the
> > suspension capability of VM can be ensured by various workloads that
> > require GC. We don't need to ensure it with 3 seconds wall time test.
> >
> > I would suggest to remove this test at all. The assumption that a
> > computation-intensive loop can be GC-safe is already invalid.
> >
> > The test code is pasted below with my comments:
> >
> > public class ThreadSuspension implements Runnable {
> >
> >     static boolean passed = false;
> >
> >     public static void main (String[] args) {
> >
> >        //main thread starts three slave threads
> >
> >         Thread x1 = new Thread(new ThreadSuspension(1));
> >         x1.setDaemon(true); x1.start();
> >         Thread x2 = new Thread(new ThreadSuspension(2));
> >         x2.setDaemon(true); x2.start();
> >         Thread x3 = new Thread(new ThreadSuspension(3));
> >         x3.setDaemon(true); x3.start();
> >         try {
> >             //main thread waits for 3 seconds, assuming a GC will be
> > triggered and finished
> >             synchronized(x1) {
> >                 x1.wait(3000);
> >             }
> >         } catch (Throwable e) {}
> >
> >         //If a GC was finished, it passes.
> >         if (passed) {
> >             trace("PASS");
> >         } else {
> >             trace("FAIL");
> >         }
> >     }
> >
> >     public ThreadSuspension(int n) {
> >         number = n;
> >     }
> >
> >     public void run() {
> >         switch (number) {
> >             case 1:
> >                //Slave thread #1 sleeps for 1 second, then triggers a GC.
> >                 try { Thread.sleep(1000); } catch (Throwable e) {}
> >                 trace("forcing gc after 1 s delay");
> >                 System.gc();
> >                 trace("gc completed");
> >                 //set the flag to indicate the finish of GC.
> >                 passed = true;
> >                 synchronized (this) {
> >                     notify();
> >                 }
> >                 break;
> >             case 2:
> >                 // slave thread 2 is designed to be un-suspensible,
> > because it has only intensive computation. This is wrong with BBP.
> >                 int j =0;
> >                 trace("-- starting unsuspendable computation --");
> >                 for (int i=0; i<1000000000; i++) {
> >                     j = 1000 + j/(i+1);
> >                 }
> >                 trace("-- unsuspendable computation finished --");
> >                 break;
> >             case 3:
> >                 // Slave thread 3 is designed to be suspensible.
> >                 trace("-- starting suspendable computation --");
> >                 for (int i=0; i<1000000000; i++) {
> >                     Thread.yield();
> >                 }
> >                 trace("-- suspendable computation finished --");
> >                 break;
> >         }
> >     }
> >
> >     public synchronized static void trace(Object o) {
> >         System.out.println(o);
> >         System.out.flush();
> >     }
> >
> >     int number; // the number of the thread
> > }
> >
> >
> >
> > Thanks,
> > xiaofeng
> >
> > On 5/17/07, Vladimir Ivanov <ivavladimir@gmail.com> wrote:
> > > On 5/17/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > > > I am afraid it's some threading issue that depends on timing (such as
> > > > timedwait). It's interesting to know how RI behaves with those test
> > > > cases.
> > >
> > > Seems, these tests are runtime dependent. The test
> > > gc.ThreadSuspension, for example, always failed on RI:
> > > --output on RI -------------------
> > > >sh run.sh
> > > java version "1.5.0_09"
> > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01)
> > > Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_09-b01, mixed mode)
> > > Thu May 17 10:51:15 NOVST 2007
> > > -- starting unsuspendable computation --
> > > -- starting suspendable computation --
> > > forcing gc after 1 s delay
> > > FAIL
> > > -- unsuspendable computation finished --
> > > gc completed
> > > 0
> > > ------------------------------------
> > >
> > > and passed on DRLVM (non-loaded box):
> > >
> > > -------output on DRLVM---
> > > sh run.sh
> > > Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
> > > Foundation or its licensors, as applicable.
> > > java version "1.5.0"
> > > pre-alpha : not complete or compatible
> > > svn = r538790, (May 17 2007), Linux/em64t/gcc 3.3.3, debug build
> > > http://incubator.apache.org/harmony
> > > Thu May 17 10:55:26 NOVST 2007
> > > -- starting unsuspendable computation --
> > > -- starting suspendable computation --
> > > forcing gc after 1 s delay
> > > gc completed
> > > PASS
> > > 0
> > > ------------------------------------
> > >
> > > thanks, Vladimir
> > >
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > > > On 5/17/07, Vladimir Ivanov <ivavladimir@gmail.com> wrote:
> > > > > On 5/16/07, Gregory Shimansky <gshimansky@apache.org> wrote:
> > > > > > Vladimir Ivanov wrote:
> > > > > > > Hello everyone,
> > > > > > > today I ran the DRLVM smoke tests on the SUSE 9 Linux x86_64
in
> > > > > > > parallel with stressing class (run 4 thread with infinite
increment
> > > > > > > into cycle).
> > > > > >
> > > > >
> > > > > > Do you mean the machine was out of virtual memory? If yes, it
is
> > > > > > possible that VM crashed on malloc returning NULL, there are
many places
> > > > > > where pointer returned by malloc is not checked (in debug mode
usually
> > > > > > there is an assertion, but this assertion is a noop in release).
> > > > >
> > > > > No, my process load CPU only. I run it as: java -cp . Stress
> > > > > ---------------- Stress.java ---------------------------
> > > > > public class Stress {
> > > > >     public static void main(String[] args) {
> > > > >         Run[] threads = new Run[4];
> > > > >         for (int i = 0; i < threads.length; i++) {
> > > > >             threads[i] = new Run();
> > > > >             threads[i].start();
> > > > >         }
> > > > >         while (true){}
> > > > >     }
> > > > > }
> > > > > class Run extends Thread {
> > > > >     public void run() {
> > > > >         long i = 0;
> > > > >         try {
> > > > >             while (true) { i++; }
> > > > >         } catch (Exception e) {
> > > > >             System.out.println("Exception:" + e);
> > > > >         }
> > > > >     }
> > > > > }
> > > > > -----------------------------------------------------------------
> > > > >
> > > > > Results for DRLVM+GCv4:
> > > > > "JET" mode
> > > > >      [echo] Running test : gc.ThreadSuspension
> > > > >      [echo] *** FAILED **** : gc.ThreadSuspension (0 res code)
> > > > >
> > > > >      [echo] Running test : stress.Sync
> > > > >      [java] Java Result: 139
> > > > >      [echo] *** FAILED **** : stress.Sync (139 res code)
> > > > >
> > > > > "OPT" mode
> > > > >      [echo] Running test : gc.Force
> > > > >      [java] Java Result: 139
> > > > >      [echo] *** FAILED **** : gc.Force (139 res code)
> > > > >
> > > > >      [echo] Running test : gc.ThreadSuspension
> > > > >      [echo] *** FAILED **** : gc.ThreadSuspension (0 res code)
> > > > >
> > > > > "DEFAULT" mode
> > > > >      [echo] Running test : gc.ThreadSuspension
> > > > >      [echo] *** FAILED **** : gc.ThreadSuspension (0 res code)
> > > > >
> > > > >      [echo] Running test : util.Prop
> > > > >      [java] Java Result: 139
> > > > >      [echo] *** FAILED **** : util.Prop (139 res code)
> > > > >
> > > > > "SERVER" mode
> > > > >      [echo] Running test : gc.ThreadSuspension
> > > > >      [echo] *** FAILED **** : gc.ThreadSuspension (0 res code)
> > > > >
> > > > >
> > > > > >
> > > > > > It would be useful to enable core dumps and at least look at
the stack
> > > > > > trace for crashed tests.
> > > > > >
> > > > > > > I observed following failures (below).
> > > > > > >
> > > > > > > Could someone look at these results?
> > > > > > > Note, I checked the out data for the gc.ThreadSuspension
test and
> > > > > > > found that out has something like that (out for run in
'server' mode):
> > > > > > > <system-out>
> > > > > > > -- starting unsuspendable computation --
> > > > > > > -- starting suspendable computation --
> > > > > > > forcing gc after 1 s delay
> > > > > > > gc completed
> > > > > > > PASS
> > > > > > > </system-out>
> > > > > > > <system-err>
> > > > > > > SIGSEGV in VM code.
> > > > > > > </system-err>
> > > > > > >
> > > > > > > thanks, Vladimir
> > > > > > >
> > > > > > > -------- Results -------------------------------------------
> > > > > > >
> > > > > > > "JET" mode
> > > > > > >     [echo] Running test : gc.RunFinalizersOnExitTest
> > > > > > >     [echo] *** FAILED **** : gc.RunFinalizersOnExitTest
(0 res code)
> > > > > > >
> > > > > > >     [echo] Running test : gc.ThreadSuspension
> > > > > > >     [java] Java Result: 139
> > > > > > >     [echo] *** FAILED **** : gc.ThreadSuspension (139 res
code)
> > > > > > >
> > > > > > >     [echo] Running test : shutdown.TestLock
> > > > > > >     [java] Java Result: 139
> > > > > > >     [echo] *** FAILED **** : shutdown.TestLock (139 res
code)
> > > > > > >
> > > > > > >     [echo] Running test : stress.Sync
> > > > > > >     [java] Java Result: 139
> > > > > > >     [echo] *** FAILED **** : stress.Sync (139 res code)
> > > > > > >
> > > > > > >     [echo] Running test : thread.InfiniteFinalizer
> > > > > > >     [java] Java Result: 139
> > > > > > >     [echo] *** FAILED **** : thread.InfiniteFinalizer (139
res code)
> > > > > > >
> > > > > > > 'OPT' mode
> > > > > > >     [echo] Running test : gc.ThreadSuspension
> > > > > > >     [java] Java Result: 139
> > > > > > >     [echo] *** FAILED **** : gc.ThreadSuspension (139 res
code)
> > > > > > >
> > > > > > > default mode
> > > > > > >     [echo] Running test : shutdown.TestLock
> > > > > > >     [java] Java Result: 139
> > > > > > >     [echo] *** FAILED **** : shutdown.TestLock (139 res
code)
> > > > > > >
> > > > > > >     [echo] Running test : stress.Sync
> > > > > > >     [java] Java Result: 139
> > > > > > >     [echo] *** FAILED **** : stress.Sync (139 res code)
> > > > > > >
> > > > > > >     [echo] Running test : thread.InfiniteFinalizer
> > > > > > >     [java] Java Result: 139
> > > > > > >     [echo] *** FAILED **** : thread.InfiniteFinalizer (139
res code)
> > > > > > >
> > > > > > > Server mode (not finished yet)
> > > > > > >     [echo] Running test : gc.RunFinalizersOnExitTest
> > > > > > >     [echo] *** FAILED **** : gc.RunFinalizersOnExitTest
(0 res code)
> > > > > > >
> > > > > > >     [echo] Running test : gc.ThreadSuspension
> > > > > > >     [java] Java Result: 139
> > > > > > >     [echo] *** FAILED **** : gc.ThreadSuspension (139 res
code)
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Gregory
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > http://xiao-feng.blogspot.com
> > > >
> > >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
>
> --
> http://xiao-feng.blogspot.com
>

Mime
View raw message