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 Fri, 18 May 2007 04:04:11 GMT
OK, I'll check :-)

On 5/17/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> On 5/18/07, Vladimir Ivanov <ivavladimir@gmail.com> wrote:
> > On 5/18/07, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> > > 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.
>
> Yes.
>
> > > 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!
>
> I actually have the concern. Seems no one else is taking on this issue
> at the moment, probably Rana, you can help to check it as a known VM
> shutdown expert. :-)
>
> Thanks,
> xiaofeng
>
> > The parallel cpu eater was ran on RI. So I had only one harmony VM on this box.
> >  thanks, Vladimir
>
> In this case, probably we can remove this test.
>
> > >
> > > 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
> > > > > > > > >
>

Mime
View raw message