harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm] run of smoke tests on overloaded box
Date Thu, 17 May 2007 05:38:25 GMT
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

Mime
View raw message