RVM
  1. RVM
  2. RVM-808

OutOfMemoryError when allocating a 200 MB tab

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.1
    • Fix Version/s: 3.1.0
    • Component/s: MMTk: GenMS
    • Labels:
      None
    • Environment:
      Linux IA32 in host and target with production config (GenMS GC). The machine is a bi xeon with 2GB of RAM with a 32 bit Debian GNU/Linux
    • Number of attachments :
      0

      Description

      When allocating a 200 MB tab, a OOM is thrown. Here is a code which lead to a OOM :

      package lip6.jikesrvm.bench;

      public class Test
      {
      public static final int NB_ELEM = 200 * 1024 * 1024 / 4;
      private static int[] tab;

      public static void main(String args[])

      { tab = new int[NB_ELEM]; }

      };

      The program is run with rvm -cp barrier/bin -Xms1G -Xmx1.5G -X:processors=all lip6.jikesrvm.bench.Test

      This perfectly run with sun JVM or with NB_ELEM set at 20 * 1024 * 1024

        Issue Links

          Activity

          Hide
          David Grove added a comment -

          My guess would be that this indicates that MMTk has broken up the virtual address space such that it is unable to find 200Mb of free contiguous space to satisfy the request.

          Show
          David Grove added a comment - My guess would be that this indicates that MMTk has broken up the virtual address space such that it is unable to find 200Mb of free contiguous space to satisfy the request.
          Hide
          Thomas Preud'homme added a comment -

          I did a few test and it seems that the bug appears at 200MB of memory ask precisely. There is no problem with a 199 MB tab allocation. It sounds like a hard coded limit in Jikes for me, but maybe it is just a coincidence.

          Show
          Thomas Preud'homme added a comment - I did a few test and it seems that the bug appears at 200MB of memory ask precisely. There is no problem with a 199 MB tab allocation. It sounds like a hard coded limit in Jikes for me, but maybe it is just a coincidence.
          Hide
          Steve Blackburn added a comment -

          I have found that it works fine if you use a full heap collector (Immix or MarkSweep) and explicitly set the minimum heap size. Seems that there is at least one bug in the heap growth manager and its reporting of current heap size.

          Show
          Steve Blackburn added a comment - I have found that it works fine if you use a full heap collector (Immix or MarkSweep) and explicitly set the minimum heap size. Seems that there is at least one bug in the heap growth manager and its reporting of current heap size.
          Hide
          Steve Blackburn added a comment -

          OK, so there's also some kind of a bug in the discontiguous space allocation. For some reason it is failing to find large chunks of discontiguous space which are in fact available. Not a problem for full heap GC, which is interesting. Investigating further.

          Show
          Steve Blackburn added a comment - OK, so there's also some kind of a bug in the discontiguous space allocation. For some reason it is failing to find large chunks of discontiguous space which are in fact available. Not a problem for full heap GC, which is interesting. Investigating further.
          Hide
          Steve Blackburn added a comment -

          Thomas,

          Your immediate problem should have been fixed by r15632. Please follow up if there is still a problem.

          The problem was that in the generational collector, the nursery is by default limited to a fixed amount of virtual memory. If an object does not fit in this space, allocation fails with an out of memory error. I have fixed things now so that any such allocation will go to the large object space.

          I'm not closing this yet, because I still have a handful of followups:

          1. The heapgrowth manager needs to be fixed, as per my previous note.

          2. We probably should re-explore discontiguous nurseries (it is all there, just a matter of flipping a boolean)

          3. We need to update the MMTk tutorial now

          4. We should probably change the failure mode for out-of-address-space failures

          Show
          Steve Blackburn added a comment - Thomas, Your immediate problem should have been fixed by r15632. Please follow up if there is still a problem. The problem was that in the generational collector, the nursery is by default limited to a fixed amount of virtual memory. If an object does not fit in this space, allocation fails with an out of memory error. I have fixed things now so that any such allocation will go to the large object space. I'm not closing this yet, because I still have a handful of followups: 1. The heapgrowth manager needs to be fixed, as per my previous note. 2. We probably should re-explore discontiguous nurseries (it is all there, just a matter of flipping a boolean) 3. We need to update the MMTk tutorial now 4. We should probably change the failure mode for out-of-address-space failures
          Hide
          Thomas Preud'homme added a comment -

          I've just tested r15632 and it works indeed perfectly well.

          Thanks for the fix, it was very quick.

          Show
          Thomas Preud'homme added a comment - I've just tested r15632 and it works indeed perfectly well. Thanks for the fix, it was very quick.
          Hide
          Steve Blackburn added a comment -

          I just updated the tutorial and Daniel has a bunch of refactoring in-flight which among other things changes the handling of OOMs.

          Show
          Steve Blackburn added a comment - I just updated the tutorial and Daniel has a bunch of refactoring in-flight which among other things changes the handling of OOMs.
          Hide
          David Grove added a comment -

          Moving all unscheduled issues to 3.1. Please close or retarget to a different fix target as appropriate.

          Show
          David Grove added a comment - Moving all unscheduled issues to 3.1. Please close or retarget to a different fix target as appropriate.
          Hide
          Steve Blackburn added a comment -

          Each of the three residual issues arising from this entry are subsumed by other issues. The specific problem that lead to this JIRA was fixed, as noted above.

          Show
          Steve Blackburn added a comment - Each of the three residual issues arising from this entry are subsumed by other issues. The specific problem that lead to this JIRA was fixed, as noted above.

            People

            • Assignee:
              Steve Blackburn
              Reporter:
              Thomas Preud'homme
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: