[drlvm] run of smoke tests on overloaded box

[Vladimir Ivanov <iv...@gmail.com>]

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

Re: [drlvm] run of smoke tests on overloaded box

[Rana Dasgupta <rd...@gmail.com>]

I added the modified test under 3962 to remove dependency on wall
clock time. While doing this, I noticed that the RI often raises
spurious wakeups with notify(), whereas we take care to wake up a
single waiter waiting on the same object monitor. I remember that we
had decided to do this to fix a test case, but I wonder now if that
was a good decision.


On 5/17/07, Rana Dasgupta <rd...@gmail.com> wrote:
> OK, I will also try to change this test to make it more meaningful
> than it is now. We can then decide if we want to keep it or lose it?
>
> On 5/17/07, Pavel Rebriy <pa...@gmail.com> wrote:
> > May be better modify tests to the correct way?
> > The test gc.ThreadSuspension check suspension model during garbage
> > collection. It is a very useful test for VM.
> > --
> > Best regards,
> > Pavel Rebriy
> >
>

Re: [drlvm] run of smoke tests on overloaded box

[Gregory Shimansky <gs...@apache.org>]

Rana Dasgupta wrote:
> I could repro a couple of these cases finally( on Linux x64 ) and I
> think that this problem is happening because of the known weakness in
> shutdown of daemon threads.  gdb shows a SIGSEGV in the cancel
> handler, usually reporting a zombie thread.
> 
> In the current shutdown we register safepoint shutdown callbacks and
> do timed joins, waiting for the daemon threads to exit. We make some
> reasonable guess on the join timeout interval. After this, we kill the
> threads ( on Linux with a pthread_cancel ). When the cycle eater runs
> in the background, the join interval we have chosen is not enough. But
> sometimes, between the time we give up on the joins and before we post
> the cancel signals, the thread( default attribute is joinable and not
> detached thread ) finally completes the safepoint shutdown callback
> and exits. It is now a zombie or whatever, and would release all

Could it be that some additional synchronization of thread state would 
help here? I mean there should be some safe way of termination threads 
that might be finishing at the same time.

Or it could possibly also be a bug in pthread_cancel implementation in 
glibc version on the system that you are using. Which Linux version do 
you have?

> resources on join. But in shutdown we have given up on join and has
> started pthread_cancel(). The CANCEL signal fails to handle on the
> zombie thread and raises SIGSEGV. I don't know Linux well enough to
> know the exact dynamics of zombies.
> 
> I multiplied the join timeout interval by a factor of 100 and the
> errors went away, with cycle eater running in the background. I don't
> think we want to make changes like this in the VM. This is not a good
> way to tune wall clock times ( some of which need to exist in the
> implementation ).
> 
> I also have some concern about how we are choosing to create these
> test scenarios. Artificial severe stress conditions can be simulated
> in tests creating failures that are time consuming to debug. But I
> don't know how much extra information they give us. For example, we
> already known that daemon thread shutdown is not perfect. If we choose
> to create stresses, I think that it is better to use real applications
> or well known workloads. In that case, failures would be more
> meaningful and would give us some good guidance on tuning things.
> 
> On6/6/07, Vladimir Ivanov <iv...@gmail.com> wrote:
>> issue HARMONY-4080 was created to track it.
>>
>>  thanks, Vladimir
>>
>> On 5/18/07, Vladimir Ivanov <iv...@gmail.com> wrote:
>> > The CC/CI report failures just now on linux x86_64 in default mode:
>> > -----------------------------
>> > Running test : thread.ThreadInterrupt
>> > *** FAILED **** : thread.ThreadInterrupt (139 res code)
>> > -----------------------------
>> >
>> >  thanks, Vladimir
>> >
>> >
>> > On 5/18/07, Rana Dasgupta <rd...@gmail.com> wrote:
>> > > OK, I will also try to change this test to make it more meaningful
>> > > than it is now. We can then decide if we want to keep it or lose it?
>> > >
>> > > On 5/17/07, Pavel Rebriy <pa...@gmail.com> wrote:
>> > > > May be better modify tests to the correct way?
>> > > > The test gc.ThreadSuspension check suspension model during garbage
>> > > > collection. It is a very useful test for VM.
>> > > > --
>> > > > Best regards,
>> > > > Pavel Rebriy
>> > > >
>> > >
>> >
>>
> 


-- 
Gregory

Re: [drlvm] run of smoke tests on overloaded box

[Evgueni Brevnov <ev...@gmail.com>]

On 6/16/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> On 6/16/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > I could repro a couple of these cases finally( on Linux x64 ) and I
> > think that this problem is happening because of the known weakness in
> > shutdown of daemon threads.  gdb shows a SIGSEGV in the cancel
> > handler, usually reporting a zombie thread.
> >
> > In the current shutdown we register safepoint shutdown callbacks and
> > do timed joins, waiting for the daemon threads to exit. We make some
> > reasonable guess on the join timeout interval. After this, we kill the
> > threads ( on Linux with a pthread_cancel ). When the cycle eater runs
> > in the background, the join interval we have chosen is not enough. But
> > sometimes, between the time we give up on the joins and before we post
> > the cancel signals, the thread( default attribute is joinable and not
> > detached thread ) finally completes the safepoint shutdown callback
> > and exits. It is now a zombie or whatever, and would release all
> > resources on join. But in shutdown we have given up on join and has
> > started pthread_cancel(). The CANCEL signal fails to handle on the
> > zombie thread and raises SIGSEGV. I don't know Linux well enough to
> > know the exact dynamics of zombies.
>
> Very interesting study. This situation happens not only here but also
> finalizer threads shutdown. We have test case that creates infinite
> loop execution in a finalizer (or waiting on a lost socket), requiring
> the system can shutdown correctly by sort of figuring out this
> situation and not waiting for the (dead) finalizer's finish. At the
> same time, we have test case that lets the finalizer to run lots of
> heavy duty work, and requiring the system to figure out this situation
> and waiting for the finalizer's finish.
>
> In GCv5, we solved the problem (or passed the tests anyway) by letting
> the system to timed wait on the finalizers. If at the timeout event we
> detect there is at least one finalizer is executed, we will loop back
> timed waiting again, since in this case it means the finalizers are
> still making progress. If at a timeout event we find the finalizers
> number is unchanged, we decide the finalizers are dead and will go on
> to exit.

Does the spec require to wait for finalizer thread completion? My
understanding is that finalizer thread should be treated as general
daemon thread until runFinalizationOnExit requested. That means that
we should not wait for finalize thread completion and can shutdown it
at any time.

Evgueni

>
> The problem is, we don't know which timeout value is reasonable, 1ms
> or 1s. In this case, I personally think a bigger value makes more
> sense. Since in our case, the timed wait doesn't need to wait for
> timeout, it can also be waken up by the finalizers once they are
> finished, so a longer timeout value does not impact the performance
> normally. I guess this is the same case for the thread joining timed
> wait?
>
> Thanks,
> xiaofeng
>
> > I multiplied the join timeout interval by a factor of 100 and the
> > errors went away, with cycle eater running in the background. I don't
> > think we want to make changes like this in the VM. This is not a good
> > way to tune wall clock times ( some of which need to exist in the
> > implementation ).
> >
> > I also have some concern about how we are choosing to create these
> > test scenarios. Artificial severe stress conditions can be simulated
> > in tests creating failures that are time consuming to debug. But I
> > don't know how much extra information they give us. For example, we
> > already known that daemon thread shutdown is not perfect. If we choose
> > to create stresses, I think that it is better to use real applications
> > or well known workloads. In that case, failures would be more
> > meaningful and would give us some good guidance on tuning things.
> >
> > On6/6/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > > issue HARMONY-4080 was created to track it.
> > >
> > >  thanks, Vladimir
> > >
> > > On 5/18/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > > > The CC/CI report failures just now on linux x86_64 in default mode:
> > > > -----------------------------
> > > > Running test : thread.ThreadInterrupt
> > > > *** FAILED **** : thread.ThreadInterrupt (139 res code)
> > > > -----------------------------
> > > >
> > > >  thanks, Vladimir
> > > >
> > > >
> > > > On 5/18/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > > OK, I will also try to change this test to make it more meaningful
> > > > > than it is now. We can then decide if we want to keep it or lose it?
> > > > >
> > > > > On 5/17/07, Pavel Rebriy <pa...@gmail.com> wrote:
> > > > > > May be better modify tests to the correct way?
> > > > > > The test gc.ThreadSuspension check suspension model during garbage
> > > > > > collection. It is a very useful test for VM.
> > > > > > --
> > > > > > Best regards,
> > > > > > Pavel Rebriy
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> http://xiao-feng.blogspot.com
>

Re: [drlvm] run of smoke tests on overloaded box

[Rana Dasgupta <rd...@gmail.com>]

On 6/15/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> Very interesting study. This situation happens not only here but also
> finalizer threads shutdown. We have test case that creates infinite
> loop execution in a finalizer (or waiting on a lost socket), requiring
> the system can shutdown correctly by sort of figuring out this
> situation and not waiting for the (dead) finalizer's finish. At the
> same time, we have test case that lets the finalizer to run lots of
> heavy duty work, and requiring the system to figure out this situation
> and waiting for the finalizer's finish.
>
> In GCv5, we solved the problem (or passed the tests anyway) by letting
> the system to timed wait on the finalizers. If at the timeout event we
> detect there is at least one finalizer is executed, we will loop back
> timed waiting again, since in this case it means the finalizers are
> still making progress. If at a timeout event we find the finalizers
> number is unchanged, we decide the finalizers are dead and will go on
> to exit.

For the finalizers that we want to allow to complete, we can
reasonably expect that they will all end at some point( except for
those in error situations like infinite loops ). For shutdown, there
is no contract like runFinalizersOnExit etc. that requires us to allow
all the daemon threads to finish. So we attach a callback that fires
at the next thread safepoint and expect the thread to correctly
release all locks, memory etc. resources before exiting. This is hard
to do( eg., in our implementation, at the next safepoint callback, we
just exit ). This means that currently every time a thread exits and
joins successfully, we are sort of increasing the probability that
some other thread(s) would be hung. So I am not sure how to converge
using an interative approach. I can try a couple of ways. That's why
we need the realistic scenarios.

>
> The problem is, we don't know which timeout value is reasonable, 1ms
> or 1s. In this case, I personally think a bigger value makes more
> sense. Since in our case, the timed wait doesn't need to wait for
> timeout, it can also be waken up by the finalizers once they are
> finished, so a longer timeout value does not impact the performance
> normally. I guess this is the same case for the thread joining timed
> wait?

It is a little different ( as above ), in the timeout we are trying to
guess when the running thread's next safepoint will be taken. The
blocked threads of course cannot execute the callbacks. In theory if
all the threads that are running, correctly release resources and exit
at the next safepoint, the blocked threads should become unblocked and
also exit correctly unless there are deadlocks already. So some form
of iteration could help, but for this the safepoint callback has to be
really good.

>
> Thanks,
> xiaofeng
>

Re: [drlvm] run of smoke tests on overloaded box

[Xiao-Feng Li <xi...@gmail.com>]

On 6/16/07, Rana Dasgupta <rd...@gmail.com> wrote:
> I could repro a couple of these cases finally( on Linux x64 ) and I
> think that this problem is happening because of the known weakness in
> shutdown of daemon threads.  gdb shows a SIGSEGV in the cancel
> handler, usually reporting a zombie thread.
>
> In the current shutdown we register safepoint shutdown callbacks and
> do timed joins, waiting for the daemon threads to exit. We make some
> reasonable guess on the join timeout interval. After this, we kill the
> threads ( on Linux with a pthread_cancel ). When the cycle eater runs
> in the background, the join interval we have chosen is not enough. But
> sometimes, between the time we give up on the joins and before we post
> the cancel signals, the thread( default attribute is joinable and not
> detached thread ) finally completes the safepoint shutdown callback
> and exits. It is now a zombie or whatever, and would release all
> resources on join. But in shutdown we have given up on join and has
> started pthread_cancel(). The CANCEL signal fails to handle on the
> zombie thread and raises SIGSEGV. I don't know Linux well enough to
> know the exact dynamics of zombies.

Very interesting study. This situation happens not only here but also
finalizer threads shutdown. We have test case that creates infinite
loop execution in a finalizer (or waiting on a lost socket), requiring
the system can shutdown correctly by sort of figuring out this
situation and not waiting for the (dead) finalizer's finish. At the
same time, we have test case that lets the finalizer to run lots of
heavy duty work, and requiring the system to figure out this situation
and waiting for the finalizer's finish.

In GCv5, we solved the problem (or passed the tests anyway) by letting
the system to timed wait on the finalizers. If at the timeout event we
detect there is at least one finalizer is executed, we will loop back
timed waiting again, since in this case it means the finalizers are
still making progress. If at a timeout event we find the finalizers
number is unchanged, we decide the finalizers are dead and will go on
to exit.

The problem is, we don't know which timeout value is reasonable, 1ms
or 1s. In this case, I personally think a bigger value makes more
sense. Since in our case, the timed wait doesn't need to wait for
timeout, it can also be waken up by the finalizers once they are
finished, so a longer timeout value does not impact the performance
normally. I guess this is the same case for the thread joining timed
wait?

Thanks,
xiaofeng

> I multiplied the join timeout interval by a factor of 100 and the
> errors went away, with cycle eater running in the background. I don't
> think we want to make changes like this in the VM. This is not a good
> way to tune wall clock times ( some of which need to exist in the
> implementation ).
>
> I also have some concern about how we are choosing to create these
> test scenarios. Artificial severe stress conditions can be simulated
> in tests creating failures that are time consuming to debug. But I
> don't know how much extra information they give us. For example, we
> already known that daemon thread shutdown is not perfect. If we choose
> to create stresses, I think that it is better to use real applications
> or well known workloads. In that case, failures would be more
> meaningful and would give us some good guidance on tuning things.
>
> On6/6/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > issue HARMONY-4080 was created to track it.
> >
> >  thanks, Vladimir
> >
> > On 5/18/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > > The CC/CI report failures just now on linux x86_64 in default mode:
> > > -----------------------------
> > > Running test : thread.ThreadInterrupt
> > > *** FAILED **** : thread.ThreadInterrupt (139 res code)
> > > -----------------------------
> > >
> > >  thanks, Vladimir
> > >
> > >
> > > On 5/18/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > > OK, I will also try to change this test to make it more meaningful
> > > > than it is now. We can then decide if we want to keep it or lose it?
> > > >
> > > > On 5/17/07, Pavel Rebriy <pa...@gmail.com> wrote:
> > > > > May be better modify tests to the correct way?
> > > > > The test gc.ThreadSuspension check suspension model during garbage
> > > > > collection. It is a very useful test for VM.
> > > > > --
> > > > > Best regards,
> > > > > Pavel Rebriy
> > > > >
> > > >
> > >
> >
>


-- 
http://xiao-feng.blogspot.com

Re: [drlvm] run of smoke tests on overloaded box

[Rana Dasgupta <rd...@gmail.com>]

I could repro a couple of these cases finally( on Linux x64 ) and I
think that this problem is happening because of the known weakness in
shutdown of daemon threads.  gdb shows a SIGSEGV in the cancel
handler, usually reporting a zombie thread.

In the current shutdown we register safepoint shutdown callbacks and
do timed joins, waiting for the daemon threads to exit. We make some
reasonable guess on the join timeout interval. After this, we kill the
threads ( on Linux with a pthread_cancel ). When the cycle eater runs
in the background, the join interval we have chosen is not enough. But
sometimes, between the time we give up on the joins and before we post
the cancel signals, the thread( default attribute is joinable and not
detached thread ) finally completes the safepoint shutdown callback
and exits. It is now a zombie or whatever, and would release all
resources on join. But in shutdown we have given up on join and has
started pthread_cancel(). The CANCEL signal fails to handle on the
zombie thread and raises SIGSEGV. I don't know Linux well enough to
know the exact dynamics of zombies.

I multiplied the join timeout interval by a factor of 100 and the
errors went away, with cycle eater running in the background. I don't
think we want to make changes like this in the VM. This is not a good
way to tune wall clock times ( some of which need to exist in the
implementation ).

I also have some concern about how we are choosing to create these
test scenarios. Artificial severe stress conditions can be simulated
in tests creating failures that are time consuming to debug. But I
don't know how much extra information they give us. For example, we
already known that daemon thread shutdown is not perfect. If we choose
to create stresses, I think that it is better to use real applications
or well known workloads. In that case, failures would be more
meaningful and would give us some good guidance on tuning things.

On6/6/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> issue HARMONY-4080 was created to track it.
>
>  thanks, Vladimir
>
> On 5/18/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > The CC/CI report failures just now on linux x86_64 in default mode:
> > -----------------------------
> > Running test : thread.ThreadInterrupt
> > *** FAILED **** : thread.ThreadInterrupt (139 res code)
> > -----------------------------
> >
> >  thanks, Vladimir
> >
> >
> > On 5/18/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > > OK, I will also try to change this test to make it more meaningful
> > > than it is now. We can then decide if we want to keep it or lose it?
> > >
> > > On 5/17/07, Pavel Rebriy <pa...@gmail.com> wrote:
> > > > May be better modify tests to the correct way?
> > > > The test gc.ThreadSuspension check suspension model during garbage
> > > > collection. It is a very useful test for VM.
> > > > --
> > > > Best regards,
> > > > Pavel Rebriy
> > > >
> > >
> >
>

Re: [drlvm] run of smoke tests on overloaded box

[Vladimir Ivanov <iv...@gmail.com>]

issue HARMONY-4080 was created to track it.

 thanks, Vladimir

On 5/18/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> The CC/CI report failures just now on linux x86_64 in default mode:
> -----------------------------
> Running test : thread.ThreadInterrupt
> *** FAILED **** : thread.ThreadInterrupt (139 res code)
> -----------------------------
>
>  thanks, Vladimir
>
>
> On 5/18/07, Rana Dasgupta <rd...@gmail.com> wrote:
> > OK, I will also try to change this test to make it more meaningful
> > than it is now. We can then decide if we want to keep it or lose it?
> >
> > On 5/17/07, Pavel Rebriy <pa...@gmail.com> wrote:
> > > May be better modify tests to the correct way?
> > > The test gc.ThreadSuspension check suspension model during garbage
> > > collection. It is a very useful test for VM.
> > > --
> > > Best regards,
> > > Pavel Rebriy
> > >
> >
>

Re: [drlvm] run of smoke tests on overloaded box

[Vladimir Ivanov <iv...@gmail.com>]

The CC/CI report failures just now on linux x86_64 in default mode:
-----------------------------
Running test : thread.ThreadInterrupt
*** FAILED **** : thread.ThreadInterrupt (139 res code)
-----------------------------

 thanks, Vladimir


On 5/18/07, Rana Dasgupta <rd...@gmail.com> wrote:
> OK, I will also try to change this test to make it more meaningful
> than it is now. We can then decide if we want to keep it or lose it?
>
> On 5/17/07, Pavel Rebriy <pa...@gmail.com> wrote:
> > May be better modify tests to the correct way?
> > The test gc.ThreadSuspension check suspension model during garbage
> > collection. It is a very useful test for VM.
> > --
> > Best regards,
> > Pavel Rebriy
> >
>

Re: [drlvm] run of smoke tests on overloaded box

[Rana Dasgupta <rd...@gmail.com>]

OK, I will also try to change this test to make it more meaningful
than it is now. We can then decide if we want to keep it or lose it?

On 5/17/07, Pavel Rebriy <pa...@gmail.com> wrote:
> May be better modify tests to the correct way?
> The test gc.ThreadSuspension check suspension model during garbage
> collection. It is a very useful test for VM.
> --
> Best regards,
> Pavel Rebriy
>

Re: [drlvm] run of smoke tests on overloaded box

[Pavel Rebriy <pa...@gmail.com>]

May be better modify tests to the correct way?
The test gc.ThreadSuspension check suspension model during garbage
collection. It is a very useful test for VM.
-- 
Best regards,
Pavel Rebriy

Re: [drlvm] run of smoke tests on overloaded box

[Rana Dasgupta <rd...@gmail.com>]

OK, I'll check :-)

On 5/17/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> On 5/18/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> > On 5/18/07, Rana Dasgupta <rd...@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 <xi...@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 <xi...@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 <iv...@gmail.com> wrote:
> > > > > > On 5/17/07, Xiao-Feng Li <xi...@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 <iv...@gmail.com> wrote:
> > > > > > > > On 5/16/07, Gregory Shimansky <gs...@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
> > > > > > > > >
>

Re: [drlvm] run of smoke tests on overloaded box

[Xiao-Feng Li <xi...@gmail.com>]

On 5/18/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> On 5/18/07, Rana Dasgupta <rd...@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 <xi...@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 <xi...@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 <iv...@gmail.com> wrote:
> > > > > On 5/17/07, Xiao-Feng Li <xi...@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 <iv...@gmail.com> wrote:
> > > > > > > On 5/16/07, Gregory Shimansky <gs...@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
> > > > > > > >

Re: [drlvm] run of smoke tests on overloaded box

[Vladimir Ivanov <iv...@gmail.com>]

On 5/18/07, Rana Dasgupta <rd...@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.

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

The parallel cpu eater was ran on RI. So I had only one harmony VM on this box.
 thanks, Vladimir

>
> On 5/17/07, Xiao-Feng Li <xi...@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 <xi...@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 <iv...@gmail.com> wrote:
> > > > On 5/17/07, Xiao-Feng Li <xi...@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 <iv...@gmail.com> wrote:
> > > > > > On 5/16/07, Gregory Shimansky <gs...@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
> >
>

Re: [drlvm] run of smoke tests on overloaded box

[Rana Dasgupta <rd...@gmail.com>]

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 <xi...@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 <xi...@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 <iv...@gmail.com> wrote:
> > > On 5/17/07, Xiao-Feng Li <xi...@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 <iv...@gmail.com> wrote:
> > > > > On 5/16/07, Gregory Shimansky <gs...@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
>

Re: [drlvm] run of smoke tests on overloaded box

[Xiao-Feng Li <xi...@gmail.com>]

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 <xi...@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 <iv...@gmail.com> wrote:
> > On 5/17/07, Xiao-Feng Li <xi...@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 <iv...@gmail.com> wrote:
> > > > On 5/16/07, Gregory Shimansky <gs...@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

Re: [drlvm] run of smoke tests on overloaded box

[Xiao-Feng Li <xi...@gmail.com>]

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 <iv...@gmail.com> wrote:
> On 5/17/07, Xiao-Feng Li <xi...@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 <iv...@gmail.com> wrote:
> > > On 5/16/07, Gregory Shimansky <gs...@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

Re: [drlvm] run of smoke tests on overloaded box

[Vladimir Ivanov <iv...@gmail.com>]

On 5/17/07, Xiao-Feng Li <xi...@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 <iv...@gmail.com> wrote:
> > On 5/16/07, Gregory Shimansky <gs...@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
>

Re: [drlvm] run of smoke tests on overloaded box

[Xiao-Feng Li <xi...@gmail.com>]

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.

Thanks,
xiaofeng

On 5/17/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> On 5/16/07, Gregory Shimansky <gs...@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

Re: [drlvm] run of smoke tests on overloaded box

[Vladimir Ivanov <iv...@gmail.com>]

On 5/16/07, Gregory Shimansky <gs...@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
>
>

Re: [drlvm] run of smoke tests on overloaded box

[Gregory Shimansky <gs...@apache.org>]

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

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