OK, I'll check :-) On 5/17/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
On 5/18/07, Vladimir Ivanov <[EMAIL PROTECTED]> wrote: > On 5/18/07, Rana Dasgupta <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > On 5/17/07, Xiao-Feng Li <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > > > On 5/16/07, Gregory Shimansky <[EMAIL PROTECTED]> 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 > > > > > > > >
