Name: elR10090 Date: 07/18/2000



J2SDK 1.3.0-b22 (Sparc) Server HS fails to properly schedule threads;
so that the test jck12a004 hangs while trying to display the test
execution status.

I started jck12a004 as:
    java -server -Xcomp -showversion jck12a004 -stress:timer=2m -stress:priority=min

Here:
-stress:timer=2m Brings the StressTest wrapper to display the test execution
                      status every 2 minutes.
-stress:priority=min Says StressTest wrapper to assign Thread.MIN_PRIORITY to
                      the threads executing the involved JCK tests.

Please note, that the thread printing the execution status is assigned to
the Thread.MAX_PRIORITY -- just in order that the status could be displayed
while the involved JCK tests keep running.

However, the test hung while trying to display its execution status:
    >>>> time java -server -Xcomp -showversion jck12a004 -stress:timer=2m -stress:priority=min ;
echo $status
    java version "1.3.0"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-b22)
    Java HotSpot(TM) Server VM (build 1.3.0-b22, compiled mode)
    ---
    --- Hmm! Its time for the draft report #1
[ The test hung, and I've pressed CTRL-C here: ]
    ^C335.0u 10.0s 6:20 90% 0+0k 0+0io 0pf+0w

It is interesting to note, that the test could print a couple of lines more
when I slightly modified the StressTest wrapper (StressTest.java, line 1044).
Namely, I have commented-away the floating-point operation of division by
60000.0 intended to rescale the elapsedTime to minutes, not milliseconds.
        . . .
        System.err.println("--- The time passed till the tests have started: "
            + elapsedTime + " milliseconds") ; // XXX: /60000.0 + " minutes");
        . . .
This resulted in few more lines printed in my next execution:
    >>>> time java -server -Xcomp -showversion jck12a004 -stress:timer=2m -stress:priority=min ;
echo $status
    java version "1.3.0"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-b22)
    Java HotSpot(TM) Server VM (build 1.3.0-b22, compiled mode)
    ---
    --- Hmm! Its time for the draft report #1
    --- The time passed till the tests have started: 120315 milliseconds
    --- The following JCK tests still havn't finish:
    ^C714.0u 16.0s 12:33 96% 0+0k 0+0io 0pf+0w

Please note, that the test jck12a004 involves just floating-point tests
from JCK 1.2a; and many of those JCK tests consume CPU time intensively.
(I mean, that many of those tests do not try to print something, and do
not yield to other threads by some other way.)

My guess is that HS 1.3 (sparc) should schedule threads finer, when
there are threads consuming CPU time intensively. (See the bug 4342899.)

To reproduce the hangup, please see the directory:
    /net/sqesvr/vsn/GammaBase/Bugs/<this_bug_id>

======================================================================
jon.masamitsu@Eng 2000-08-07

The compiler thread seems to be in an infinite loop somewhere in this
call chain.

current thread: t@11
  [1] IndexSet::insert(this = 0xff97a0, element = 0x79dU), line 269 in "indexSet.hpp"
  [2] PhaseConservativeCoalesce::update_ifg(this = 0xf3f80b30, lr1 = 0x79dU, lr2 = 0x16eaU, n_lr1 = 0xe37f18, n_lr2 = 0xe8fec4), line 661 in "coalesce.cpp"
  [3] PhaseConservativeCoalesce::copy_copy(this = 0xf3f80b30, dst_copy = 0xc43d2c, src_copy = 0xc43d2c, b = 0xb79068, bindex = 0x3U), line 770 in "coalesce.cpp"
  [4] PhaseConservativeCoalesce::coalesce(this = 0xf3f80b30, b = 0xb79068), line 831 in "coalesce.cpp"
=>[5] PhaseCoalesce::coalesce_driver(this = 0xf3f80b30), line 245 in "coalesce.cpp"
  [6] PhaseChaitin::Register_Allocate(this = 0xf3f80db8), line 346 in "chaitin.cpp"
  [7] Compile::Code_Gen(this = 0xf3f81608, save_argument_registers = 0), line 980 in "compile.cpp"
  [8] Compile::Compile(this = 0xf3f81608, ci_env = 0xf3f819dc, ci_scope = 0x221f38, target = 0x221e44, osr_bci = 0xffffffff, subsume_loads = 0x1, subsume_long_adds = 0x1, reuse_env = 0), line 381 in "compile.cpp"
  [9] C2Compiler::compile_method(this = 0x128910, env = 0xf3f819dc, scope = 0x221f38, target = 0x221e44, entry_bci = 0xffffffff, reuse_env = 0), line 38 in "c2compiler.cpp"
  [10] CompileBroker::invoke_compiler_on_method(task = 0x13a790), line 1139 in "compileBroker.cpp"
  [11] CompileBroker::compiler_thread_loop(), line 1047 in "compileBroker.cpp"
  [12] compiler_thread_entry(thread = 0x12e468, __the_thread__ = 0x12e468), line 1687 in "thread.cpp"
  [13] JavaThread::thread_main_inner(this = 0x12e468), line 794 in "thread.cpp"
  [14] JavaThread::run(this = 0x12e468), line 778 in "thread.cpp"
  [15] _start(data = 0x12e468), line 489 in "os_solaris.cpp"

I set a breakpoint at the return for frame 5 and did not reach it after
> 3 minutes. I set a trace on the entry to IndexSet::insert(unsigned)
and got repeated message like


IndexSet::insert(this = 0xff03ec, element = 0xdfaU) called from function update_ifg
IndexSet::insert returns 0
IndexSet::insert(this = 0xff0448, element = 0xdfaU) called from function update_ifg
IndexSet::insert returns 0
IndexSet::insert(this = 0xff04a4, element = 0xdfaU) called from function update_ifg
IndexSet::insert returns 0
IndexSet::insert(this = 0xff055c, element = 0xdfaU) called from function update_ifg
IndexSet::insert returns 0
IndexSet::insert(this = 0xff05b8, element = 0xdfaU) called from function update_ifg
IndexSet::insert returns 0
IndexSet::insert(this = 0xff0614, element = 0xdfaU) called from function update_ifg
IndexSet::insert returns 0
IndexSet::insert(this = 0xff0670, element = 0xdfaU) called from function update_ifg
IndexSet::insert returns 0

This problem occurred with the RC1 build in debug mode.