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

possible problem with a missing safe-point in pow's while loop

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P2
    • Resolution: Won't Fix
    • Affects Version/s: 1.4.2_12
    • Fix Version/s: 1.4-pool
    • Component/s: hotspot
    • Labels:
      None
    • Subcomponent:
    • CPU:
      sparc
    • OS:
      solaris_8

      Description

      bash-2.05$ head -615 pstack.1 | tail -4
      ----------------- lwp# 62 / thread# 62 --------------------
       008af0d8 ???????? (1084e, ffffffff, 6a4d2, 7f2c0fb0, 7d6741b4, 7f46a300)
       f9c79414 ???????? (839a20d0, b7, 78142388, 78142388, 8, 0)
       f9c05850 ???????? (652fbb40, b6, 0, f9c16230, 18, 652fba40)
      bash-2.05$ head -615 pstack.2 | tail -4
      ----------------- lwp# 62 / thread# 62 --------------------
       008af0d4 ???????? (105fc, ffffffff, 6a4d2, 7f2c0fb0, 7d7b21d4, 7f46a300)
       f9c79414 ???????? (839a20d0, b7, 78142388, 78142388, 8, 0)
       f9c05850 ???????? (652fbb40, b6, 0, f9c16230, 18, 652fba40)
      bash-2.05$ head -615 pstack.3 | tail -4
      ----------------- lwp# 62 / thread# 62 --------------------
       008af0a4 ???????? (103ac, ffffffff, 6a4d2, 7f2c0fb0, 7d7788bc, 7f46a300)
       f9c79414 ???????? (839a20d0, b7, 78142388, 78142388, 8, 0)
       f9c05850 ???????? (652fbb40, b6, 0, f9c16230, 18, 652fba40)

      Diffs between pstacks show that the Thread t@62 is moving very slowly.

      If this hasnt changed, thread 62 has been running for a long while.
      bash-2.05$ grep 12157 prstat.out | grep 62
       12157 wmadmin1 2425M 2391M cpu30 0 10 1:51:47 0.0% java/62


      hsdb> where t@62

      Java Stack Trace for HTTP Handler 171.177.166.223
      Thread state = IN_JAVA
       - public java.math.BigInteger pow(int) @0xf09f07e0 @bci = 88, pc = 0xf9c05858 (Interpreted)
       - private static java.math.BigInteger timesTenToThe(java.math.BigInteger, int) @0xf11974f0 @bci = 8, pc = 0xf9c05858 (Interpreted)
       - public void <init>(java.lang.String) @0xf1196568 @bci = 448, pc = 0xfa48e228 (Compiled)
       - private java.math.BigDecimal getBigDecimal(java.lang.Object) @0xf1bb67f0 @bci = 26, line = 404, pc = 0xfa501aa4 (Compiled)
       - protected void evalSymComparator(com.wm.lang.flow.ExpressionEvaluator$Token) @0xf1bb8928 @bci = 2, line = 1199, pc = 0xfa43a150 (Compiled)
      ...

      We are again in BigInteger.pow(int) ...

      (dbx) print __1cUSafepointSynchronizeG_state_
      __1cUSafepointSynchronizeG_state_ = 1
      036 _synchronizing = 1, // Synchronizing in progress

      (dbx) print __1cUSafepointSynchronizeR_waiting_to_block_
      __1cUSafepointSynchronizeR_waiting_to_block_ = 1

      (dbx) print __1cUSafepointSynchronizeU_safepointing_thread_
      __1cUSafepointSynchronizeU_safepointing_thread_ = 1
      042 _vm_thread = 1,

      (dbx) print -fu __1cUSafepointSynchronizeP_last_safepoint_
      __1cUSafepointSynchronizeP_last_safepoint_ = 3409970318

      In the past, we wonder if a slow java.math.BigInteger pow can cause the JVM to be very slow coming to a safepoint. There was a bug 4646474 on slow algorithm of BigInteger.pow.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              minqi Yumin Qi
              Reporter:
              msusko Mark Susko (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: