Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4354056

J2SDK 1.3.0-b26 (Sparc) Server: compiler thread looping against "jck12a004"

    Details

    • Subcomponent:
    • CPU:
      sparc
    • OS:
      solaris_7

      Description



      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                rasbold Chuck Rasbold
                Reporter:
                latkinsunw Latkin Latkin (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: