RVM
  1. RVM
  2. RVM-662

Error growing discontiguous space

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.0.1
    • Fix Version/s: 3.1.0
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      The following error may relate to recent moves to make everything discontiguous. It may be a new bug, but more likely, it is just that the recent changes exposed an underlying bug. I hope to attack this in the next few days. If not we should be able to easily back out the changes which I suspect were the culprits.

      Conflicting virtual address request for space "los" at 0xa3800000
      Key: (I)mmortal (N)onmoving (D)iscontiguous (E)xtent (F)raction
      HEAP_START 0x57000000
      AVAILABLE_START 0x5c800000
      boot IN 0x57000000->0x66ffffff E 0x10000000
      immortal IND [0x67000000->0x673fffff]
      meta ND [0x87c00000->0x87ffffff]
      los ND [0xa3400000->0xa37fffff, 0xa3000000->0xa33fffff, 0xa2c00000->0xa2ffffff, 0xa2800000->0xa2bfffff, 0xa2400000->0xa27fffff, 0xa2000000->0xa23fffff, 0xa1c00000->0xa1ffffff, 0xa1800000->0xa1bfffff, 0xa1400000->0xa17fffff, 0xa1000000->0xa13fffff, 0xa0c00000->0xa0ffffff, 0xa0800000->0xa0bfffff, 0xa0400000->0xa07fffff, 0xa0000000->0xa03fffff, 0x9fc00000->0x9fffffff, 0x9f800000->0x9fbfffff, 0x9f400000->0x9f7fffff, 0x9f000000->0x9f3fffff, 0x9ec00000->0x9effffff, 0x9e800000->0x9ebfffff, 0x9e400000->0x9e7fffff, 0x9e000000->0x9e3fffff, 0x9dc00000->0x9dffffff, 0x9d800000->0x9dbfffff, 0x9d400000->0x9d7fffff, 0x9d000000->0x9d3fffff, 0x9cc00000->0x9cffffff, 0x9c800000->0x9cbfffff, 0x9c400000->0x9c7fffff, 0x9c000000->0x9c3fffff, 0x9bc00000->0x9bffffff, 0x9b800000->0x9bbfffff, 0x9b400000->0x9b7fffff, 0x9b000000->0x9b3fffff, 0x83800000->0x83bfffff, 0x83400000->0x183fffff]
      sanity ND []
      non-moving ND [0x68000000->0x683fffff]
      sm-code ND [0x71c00000->0x71ffffff, 0x67800000->0x67bfffff]
      lg-code ND [0x67c00000->0x67ffffff]
      nursery 0xa3800000->0xafffffff F 0.15
      ms ND [0x8cc00000->0x8cffffff, 0x8c400000->0x8c7fffff, 0x8c000000->0x8c3fffff, 0x8b800000->0x8bbfffff, 0x8b400000->0x8b7fffff, 0x8b000000->0x8b3fffff, 0x87800000->0x87bfffff, 0x86400000->0x867fffff, 0x85c00000->0x85ffffff, 0x7ac00000->0x7affffff, 0x80800000->0x80bfffff, 0x7f800000->0x7fbfffff, 0x7f400000->0x7f7fffff, 0x7f000000->0x7f3fffff, 0x7ec00000->0x7effffff, 0x7e800000->0x7ebfffff, 0x7e400000->0x7e7fffff, 0x7e000000->0x7e3fffff, 0x7dc00000->0x7dffffff, 0x7d800000->0x7dbfffff, 0x7d400000->0x7d7fffff, 0x7d000000->0x7d3fffff, 0x7cc00000->0x7cffffff, 0x7c400000->0x7c7fffff, 0x7c000000->0x7c3fffff, 0x7bc00000->0x7bffffff, 0x7b800000->0x7bbfffff, 0x7b400000->0x7b7fffff, 0x7a000000->0x7a3fffff, 0x78800000->0x78bfffff, 0x77400000->0x777fffff, 0x76000000->0x763fffff, 0x75400000->0x757fffff, 0x74c00000->0x74ffffff, 0x74400000->0x747fffff, 0x74000000->0x743fffff, 0x73800000->0x73bfffff, 0x73400000->0x737fffff, 0x72400000->0x727fffff, 0x72000000->0x723fffff, 0x71400000->0x717fffff, 0x70800000->0x70bfffff, 0x6fc00000->0x6fffffff, 0x6f000000->0x6f3fffff, 0x6e400000->0x6e7fffff, 0x6dc00000->0x6dffffff, 0x6d800000->0x6dbfffff, 0x6d400000->0x6d7fffff, 0x6c400000->0x6c7fffff, 0x6bc00000->0x6bffffff, 0x6b400000->0x6b7fffff, 0x6a400000->0x6a7fffff, 0x69c00000->0x69ffffff, 0x69800000->0x69bfffff, 0x69000000->0x693fffff, 0x68c00000->0x68ffffff, 0x68800000->0x68bfffff]
      AVAILABLE_END 0xb0000000
      HEAP_END 0xb0000000
      Died in GC:
      exiting

      – Stack –
      at Lorg/jikesrvm/mm/mmtk/Assert; fail(Ljava/lang/String;)V at line 45
      at Lorg/mmtk/utility/heap/Map; insert(Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Extent;ILorg/mmtk/policy/Space;)V at line 97
      at Lorg/mmtk/utility/heap/Map; allocateContiguousChunks(ILorg/mmtk/policy/Space;ILorg/vmmagic/unboxed/Address;)Lorg/vmmagic/unboxed/Address; at line 128
      at Lorg/mmtk/policy/Space; growDiscontiguousSpace(I)Lorg/vmmagic/unboxed/Address; at line 419
      at Lorg/mmtk/utility/heap/FreeListPageResource; allocateContiguousChunks(I)I at line 262
      at Lorg/mmtk/utility/heap/FreeListPageResource; allocPages(I)Lorg/vmmagic/unboxed/Address; at line 150
      at Lorg/mmtk/utility/heap/PageResource; getNewPages(I)Lorg/vmmagic/unboxed/Address; at line 234
      at Lorg/mmtk/policy/Space; acquire(I)Lorg/vmmagic/unboxed/Address; at line 391
      at Lorg/mmtk/utility/alloc/LargeObjectAllocator; allocSlowOnce(III)Lorg/vmmagic/unboxed/Address; at line 91
      at Lorg/mmtk/utility/alloc/Allocator; allocSlowInline(III)Lorg/vmmagic/unboxed/Address; at line 229
      at Lorg/mmtk/utility/alloc/Allocator; allocSlow(III)Lorg/vmmagic/unboxed/Address; at line 209
      at Lorg/mmtk/utility/alloc/LargeObjectAllocator; alloc(III)Lorg/vmmagic/unboxed/Address; at line 72
      at Lorg/mmtk/plan/generational/marksweep/GenMSCollector; allocCopy(Lorg/vmmagic/unboxed/ObjectReference;IIII)Lorg/vmmagic/unboxed/Address; at line 91
      at Lorg/jikesrvm/mm/mminterface/MemoryManager; allocateSpace(Lorg/jikesrvm/mm/mminterface/Selected$Collector;IIIILorg/vmmagic/unboxed/ObjectReference;)Lorg/vmmagic/unboxed/Address; at line 772
      at Lorg/jikesrvm/mm/mmtk/ObjectModel; copyArray(Lorg/vmmagic/unboxed/ObjectReference;Lorg/jikesrvm/objectmodel/TIB;Lorg/jikesrvm/classloader/RVMArray;I)Lorg/vmmagic/unboxed/ObjectReference; at line 81
      at Lorg/jikesrvm/mm/mmtk/ObjectModel; copy(Lorg/vmmagic/unboxed/ObjectReference;I)Lorg/vmmagic/unboxed/ObjectReference; at line 55
      at Lorg/mmtk/policy/CopySpace; traceObject(Lorg/mmtk/plan/TransitiveClosure;Lorg/vmmagic/unboxed/ObjectReference;I)Lorg/vmmagic/unboxed/ObjectReference; at line 187
      at Lorg/mmtk/plan/generational/GenNurseryTraceLocal; traceObject(Lorg/vmmagic/unboxed/ObjectReference;)Lorg/vmmagic/unboxed/ObjectReference; at line 84
      at Lorg/mmtk/plan/TraceLocal; traceObject(Lorg/vmmagic/unboxed/ObjectReference;Z)Lorg/vmmagic/unboxed/ObjectReference; at line 299
      at Lorg/mmtk/plan/TraceLocal; processEdge(Lorg/vmmagic/unboxed/ObjectReference;Lorg/vmmagic/unboxed/Address;)V at line 89
      at Lorg/jikesrvm/mm/mminterface/SpecializedScanMethod; pattern(ILjava/lang/Object;Lorg/mmtk/plan/TransitiveClosure;)V at line 237
      at Lorg/jikesrvm/mm/mminterface/SpecializedScanMethod; scalarRNNNNN(Ljava/lang/Object;Lorg/mmtk/plan/TransitiveClosure;)V at line 410
      at Lorg/jikesrvm/mm/mmtk/Scanning; specializedScanObject(ILorg/mmtk/plan/TransitiveClosure;Lorg/vmmagic/unboxed/ObjectReference;)V at line 89
      at Lorg/mmtk/plan/TraceLocal; scanObject(Lorg/vmmagic/unboxed/ObjectReference;)V at line 167
      at Lorg/mmtk/plan/TraceLocal; completeTrace()V at line 483
      at Lorg/mmtk/plan/generational/GenCollector; collectionPhase(SZ)V at line 109
      at Lorg/mmtk/plan/generational/marksweep/GenMSCollector; collectionPhase(SZ)V at line 156
      at Lorg/mmtk/plan/Phase; processPhaseStack(Z)Z at line 477
      at Lorg/mmtk/plan/Phase; beginNewPhaseStack(I)Z at line 390
      at Lorg/mmtk/plan/StopTheWorldCollector; collect()V at line 39
      at Lorg/jikesrvm/mm/mminterface/CollectorThread; run()V at line 383
      at Lorg/jikesrvm/scheduler/RVMThread; startoff()V at line 632
      Virtual machine state:

        Issue Links

          Activity

          Hide
          David Grove added a comment -

          Is this a release blocking issue, is it out of date, or are there changes we need to back out?

          Show
          David Grove added a comment - Is this a release blocking issue, is it out of date, or are there changes we need to back out?
          Hide
          David Grove added a comment -

          Noticed and example of this in last night's performance run on SPE#Cjbb2000.
          http://jikesrvm.anu.edu.au/cattrack/results/habanero.anu.edu.au/perf/5799/production/default/perf-jbb2005/jbb2005

          Show
          David Grove added a comment - Noticed and example of this in last night's performance run on SPE#Cjbb2000. http://jikesrvm.anu.edu.au/cattrack/results/habanero.anu.edu.au/perf/5799/production/default/perf-jbb2005/jbb2005
          Show
          David Grove added a comment - Happened again: http://jikesrvm.anu.edu.au/cattrack/results/habanero.anu.edu.au/perf/5915/production/default/perf-jbb2005/jbb2005/1/Output.txt
          Hide
          Steve Blackburn added a comment -

          I have narrowed things down and made an initial fix.

          There was a bug in the initialization of the chunk free list, which meant it was possible to get double-allocations (as seen in above stack traces). I have fixed that bug in r15132.

          However, that bug only showed up in a setting where virtual memory was exhausted. Now when virtual memory is exhausted, the VM dies with an out-of-virtual-memory error.

          Unfortunately, we are not handling virtual memory exhaustion properly. This is basically a design issue which I'm now looking at. The problem is that in a generational collector, if the heap is large enough, no mature space collections will be performed, so the mature space will just grow and grow. If the heap is big enough, it will grow to the point where the mature space has exhausted all available virtual memory. This should trigger a full heap collection, but since it occurs in the middle of a GC, it cannot. We need to pre-emptively trigger the full heap GC when we're running low on virtual memory....

          Show
          Steve Blackburn added a comment - I have narrowed things down and made an initial fix. There was a bug in the initialization of the chunk free list, which meant it was possible to get double-allocations (as seen in above stack traces). I have fixed that bug in r15132. However, that bug only showed up in a setting where virtual memory was exhausted. Now when virtual memory is exhausted, the VM dies with an out-of-virtual-memory error. Unfortunately, we are not handling virtual memory exhaustion properly. This is basically a design issue which I'm now looking at. The problem is that in a generational collector, if the heap is large enough, no mature space collections will be performed, so the mature space will just grow and grow. If the heap is big enough, it will grow to the point where the mature space has exhausted all available virtual memory. This should trigger a full heap collection, but since it occurs in the middle of a GC, it cannot. We need to pre-emptively trigger the full heap GC when we're running low on virtual memory....
          Hide
          Steve Blackburn added a comment -

          Looking into things more carefully, it seems that aside from the bug fixed in r15132, we had the mechanisms in place to handle things reasonably. However, the test case really pushes the system up against the wall, where it dies.

          I have just gone through and made our heuristics more conservative, accounting for fragmentation etc, when estimating available space.

          Now the test case associated with RVM-694 will correctly trigger a full heap collection. However, this is to no avail since this does not create much space, so soon we're back up against the wall. I think the fundamental problem is that in that case we're using an unreasonably large heap (larger than the available virtual memory and the efficiency of the free list can accommodate).

          As a side-note, the test runs fun under GenImmix, presumably because it has better fragmentation characteristics (it shares GC triggering mechanisms with production & prototype, which (mostly) live in the superclass, Gen).

          Show
          Steve Blackburn added a comment - Looking into things more carefully, it seems that aside from the bug fixed in r15132, we had the mechanisms in place to handle things reasonably. However, the test case really pushes the system up against the wall, where it dies. I have just gone through and made our heuristics more conservative, accounting for fragmentation etc, when estimating available space. Now the test case associated with RVM-694 will correctly trigger a full heap collection. However, this is to no avail since this does not create much space, so soon we're back up against the wall. I think the fundamental problem is that in that case we're using an unreasonably large heap (larger than the available virtual memory and the efficiency of the free list can accommodate). As a side-note, the test runs fun under GenImmix, presumably because it has better fragmentation characteristics (it shares GC triggering mechanisms with production & prototype, which (mostly) live in the superclass, Gen).
          Hide
          Steve Blackburn added a comment -

          The immediate problems have been fixed, but RVM-695 documents an overriding issue that remains unaddressed.

          Show
          Steve Blackburn added a comment - The immediate problems have been fixed, but RVM-695 documents an overriding issue that remains unaddressed.

            People

            • Assignee:
              Steve Blackburn
              Reporter:
              Steve Blackburn
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: