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
> > > > > > >
