RVM
  1. RVM
  2. RVM-953

Immix fails with unclear error message in builds without assertions when hardcoded thread limit is exceeded

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.1.2, hg tip
    • Fix Version/s: 3.1.4
    • Component/s: MMTk
    • Labels:
      None
    • Environment:
      x86_64;production configuration;ubuntu 3.0.0-15-server-offcore; Intel(R) Xeon(R) CPU E7- 4830 @ 2.13GHz
    • Testcase included:
      yes
    • Number of attachments :
      3

      Description

      The attached test case is executed with the following parameters:

      -Xms1000m -Xmx2000m -X:gc:verbose=2

      The same test works fine with Jikes 32-bit

      [Full heap][GC 1 Start 582.88 ms 774056KB
      Fatal error: ArrayIndexOutOfBoundsException within uninterruptible region (index was 27).

      Fatal error: ArrayIndexOutOfBoundsException within uninterruptible region (index was 26).
      Exception in GC thread

      Fatal error: ArrayIndexOutOfBoundsException within uninterruptible region (index was 21).
      Thread 30: VM.sysFail(): We're in a (likely) recursive call to VM.sysFail(), 2 deep
      sysFail was called with the message: Exiting virtual machine due to uninterruptibility violation.
      Exception in GC thread

      Fatal error: ArrayIndexOutOfBoundsException within uninterruptible region (index was 18).
      Exception in GC thread
      Died in GC:
      Exception in GC thread
      Thread 25: VM.sysFail(): We're in a (likely) recursive call to VM.sysFail(), 3 deep
      sysFail was called with the message: Exiting virtual machine due to uninterruptibility violation.
      Exception in GC thread
      Died in GC:
      Thread 22: VM.sysFail(): We're in a (likely) recursive call to VM.sysFail(), 4 deep
      sysFail was called with the message: Exiting virtual machine due to uninterruptibility violation.
      Exception in GC thread

      Fatal error: ArrayIndexOutOfBoundsException within uninterruptible region (index was 28).
      Exception in GC thread
      Exception in GC thread
      Thread 32: VM.sysFail(): We're in a (likely) recursive call to VM.sysFail(), 5 deep
      sysFail was called with the message: Exiting virtual machine due to uninterruptibility violation.
      Exiting virtual machine due to uninterruptibility violattion.

      1. rvm953.diff
        5 kB
        Jeremy Singer
      2. rvm-953-sketch-for-immix-fix.diff
        8 kB
        Erik Brangs
      3. Test.java
        0.2 kB
        Albert Noll

        Activity

        Hide
        David Grove added a comment -

        Discussion on researchers list (https://sourceforge.net/mailarchive/forum.php?thread_name=CAAqwin7ohB_oZ1yGw%3Dfj8ER1i0Zhg1to%2BqqpwjcBtJD%2BtW02rA%40mail.gmail.com&forum_name=jikesrvm-researchers) suggests that this may be due to hard-coded limit in Immix on # of GC threads being exceeded (and not caught because production disables assertions).

        Show
        David Grove added a comment - Discussion on researchers list ( https://sourceforge.net/mailarchive/forum.php?thread_name=CAAqwin7ohB_oZ1yGw%3Dfj8ER1i0Zhg1to%2BqqpwjcBtJD%2BtW02rA%40mail.gmail.com&forum_name=jikesrvm-researchers ) suggests that this may be due to hard-coded limit in Immix on # of GC threads being exceeded (and not caught because production disables assertions).
        Hide
        Jeremy Singer added a comment -

        Attached patch rvm953.diff
        checks for a hard-coded limit
        on num GC threads, and reports a
        warning to user if limit is
        exceeded.

        Not sure how elegant this solution
        is? Thoughts?

        Show
        Jeremy Singer added a comment - Attached patch rvm953.diff checks for a hard-coded limit on num GC threads, and reports a warning to user if limit is exceeded. Not sure how elegant this solution is? Thoughts?
        Hide
        David Grove added a comment -

        bulk defer to 3.1.4

        Show
        David Grove added a comment - bulk defer to 3.1.4
        Hide
        Erik Brangs added a comment -

        I ran into this problem on a POWER7 machine (which appears to the OS as having 64 cores).

        As somebody not familiar with garbage collection, I'd expect the garbage collector to scale gracefully to a higher number of cores (or at least not fail if more cores are available than expected). If that's not possible, I'd suggest that we do something similar to Jeremy Singer's patch. However, I'd prefer it if the code failed fast and hard (e.g. using Assert.fail(..)).

        Show
        Erik Brangs added a comment - I ran into this problem on a POWER7 machine (which appears to the OS as having 64 cores). As somebody not familiar with garbage collection, I'd expect the garbage collector to scale gracefully to a higher number of cores (or at least not fail if more cores are available than expected). If that's not possible, I'd suggest that we do something similar to Jeremy Singer's patch. However, I'd prefer it if the code failed fast and hard (e.g. using Assert.fail(..) ).
        Hide
        Erik Brangs added a comment -

        In light of the renewed discussion of this issue on the mailing lists, I'm attaching a new patch (based on Jeremy Singer's patch) that sketches a fix for the thread limit in Immix collectors. I'm not sure if it's the right approach but it seemed to work during my (very limited) testing.

        Show
        Erik Brangs added a comment - In light of the renewed discussion of this issue on the mailing lists , I'm attaching a new patch (based on Jeremy Singer's patch) that sketches a fix for the thread limit in Immix collectors. I'm not sure if it's the right approach but it seemed to work during my (very limited) testing.
        Hide
        Erik Brangs added a comment -

        I want to have this issue fixed for 3.1.4. If nobody else wants to work on it, I'll commit a fix (probably next weekend).

        Show
        Erik Brangs added a comment - I want to have this issue fixed for 3.1.4. If nobody else wants to work on it, I'll commit a fix (probably next weekend).
        Hide
        Erik Brangs added a comment -

        Fixes in 98a92919ec5ae39c8b4299a9fa017ab2a7fa123e (10758) and 3bcaa000db6c0f279f7d69c9d53376d67f923cfa (10759).

        Show
        Erik Brangs added a comment - Fixes in 98a92919ec5ae39c8b4299a9fa017ab2a7fa123e (10758) and 3bcaa000db6c0f279f7d69c9d53376d67f923cfa (10759).

          People

          • Assignee:
            Erik Brangs
            Reporter:
            Albert Noll
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: