Rana,
Can you try MegaSpawn.java that I attached to harmony-2803? Its basically a
version of stress.Mix with all the non-essential stuff removed. I would
like to know if it faithfully reproduces the bug(s) in your environment. It
would be great if this is indeed true since we would have a simple test that
always breaks the jvm. This makes for much easier debug.
I also see what you observe below. I also like the idea of killing the
"occupy" thread. It seems there might be some notion of memory quota --
something for which I have been waiting a long time.
From the below, the hang is observed on both winxp and linux. If this is
correct, we can focus on the OS independent code :)
On 1/5/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
HI Weldon,
On a 2 cpu smp RHEL4 box:
- on RI the modified test always passes
- DRLVM always fails with OOME when trying to spawn threads
On a 2 cpu XP box:
- RI kills the "occupy" thread( I thought this is really smart ), but
passes
- DRLVM sometimes passes, sometimes hangs, occassionally reports invalid
memory references, VM launcher errors etc. etc.
Rana
On 1/5/07, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>
> All,
>
> An update. I think I can cause the bug(s) we are discussing in this
email
> chain to surface 100% of the time on 2 cpu rhel4. Hacking stress.Mixsuch
> that it only runs the "spawn" method seems to do it. This hack always
> fails on 2 cpu rhel4 and never fails on 1 cpu winxp. It would be
> interesting to try on 1 cpu rhel4 and 2 cpu winxp. If anyone has this
> combination, please try it. This would tell us if the bug is sensitive
to
> OS.
>
> When I run the below patch on RI, it completes successfully every time.
> Curiously it looks like the RI kills the "occupy" thread. It prints on
> the
> console output, "occupy terminated by java.lang.OutOfMemoryError..
.". But
> I
> don't see occupy terminate when running drlvm. I will run more
> tests. This
> may actually be compounding the problems we are seeing.
>
> Naveen, Rana,
> Can you try the below patch on your hardware to see if you can reproduce
> what I describe above? Does the output look the same as Harmony-2803?
>
>
> Below is an svn diff that makes the hard failure happen on 2 cpu rhel4:
>
> Index: Mix.java
> ===================================================================
> --- Mix.java (revision 491852)
> +++ Mix.java (working copy)
> @@ -93,6 +93,8 @@
>
> static Random random = new Random(0);
> static String selectThreadType(int i) {
> + return "spawn";
> + /*
> switch (i % 9) {
> case 0: return "uncontended";
> case 1: return "contended";
> @@ -105,6 +107,7 @@
> case 8: return "exceptions";
> }
> return "nothing";
> + */
> }
>
> static int thread_number = 60;
>
>
>
> On 1/4/07, Naveen Neelakantam <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Jan 4, 2007, at 4:28 PM, Weldon Washburn wrote:
> >
> > > I see it hang consistently when running automated mode (build
> > > test). I have
> > > seen it hang once when running manually from a linux terminal
> > > window. It
> > > actually printed out "PASSED" then hung. This leads me to suspect
> > > there
> > > might be problems with how System.out.flush() is working when there
> > > are
> > > multiple threads running on SMP. Are you running on an SMP box?
> > > Can you
> > > give me the exact command line you are using? I would like to try
> > > it on my
> > > box.
> >
> > Ok, cool. I was seeing the exact same behavior (i.e. the test prints
> > PASSED and then hangs). So it sounds like you are on the right
> > track, to me anyway.
> >
> > But to answer your questions: I am running RHEL4 update 4 on a core2
> > duo. The command line I am using is "java -cp . stress.Mix" (with my
> > path and JAVA_HOME set appropriately).
> >
> > Naveen
> >
>
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
