Uploaded image for project: 'JikesRVM'
  1. JikesRVM
  2. RVM-625

FullAdaptiveImmix and FullAdaptiveStickyImmix broken on ppc32-linux

    Details

      Description

      All tests for these two configurations fail with the appended stack trace.

      See http://jikesrvm.anu.edu.au/cattrack/results/piano.watson.ibm.com/sanity-ppc32/4688/regression_report

      vm internal error at:

      – Stack –
      at Lorg/jikesrvm/VM; _assertionFailure(Ljava/lang/String;Ljava/lang/String;)V at line 627
      at Lorg/jikesrvm/VM; _assert(ZLjava/lang/String;Ljava/lang/String;)V at line 610
      at Lorg/jikesrvm/VM; _assert(Z)V at line 588
      at Lorg/jikesrvm/runtime/Memory; zeroPages(Lorg/vmmagic/unboxed/Address;I)V at line 428
      at Lorg/jikesrvm/mm/mmtk/Memory; zeroPages(Lorg/vmmagic/unboxed/Address;I)V at line 163
      at Lorg/mmtk/policy/immix/Chunk; clearMetaData(Lorg/vmmagic/unboxed/Address;)V at line 84
      at Lorg/mmtk/policy/immix/ImmixSpace; growSpace(Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Extent;Z)V at line 253
      at Lorg/mmtk/utility/heap/FreeListPageResource; allocPages(I)Lorg/vmmagic/unboxed/Address; at line 171
      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 404
      at Lorg/mmtk/policy/immix/ImmixSpace; getSpace(ZZI)Lorg/vmmagic/unboxed/Address; at line 224
      at Lorg/mmtk/utility/alloc/ImmixAllocator; allocSlowOnce(III)Lorg/vmmagic/unboxed/Address; at line 173
      at Lorg/mmtk/utility/alloc/Allocator; allocSlowInline(III)Lorg/vmmagic/unboxed/Address; at line 229
      at Lorg/mmtk/utility/alloc/ImmixAllocator; allocSlowHot(III)Lorg/vmmagic/unboxed/Address; at line 218
      at Lorg/mmtk/utility/alloc/ImmixAllocator; alloc(III)Lorg/vmmagic/unboxed/Address; at line 112
      at Lorg/mmtk/plan/immix/ImmixMutator; alloc(IIIII)Lorg/vmmagic/unboxed/Address; at line 77
      at Lorg/jikesrvm/mm/mminterface/MemoryManager; allocateSpace(Lorg/jikesrvm/mm/mminterface/Selected$Mutator;IIIII)Lorg/vmmagic/unboxed/Address; at line 742
      at Lorg/jikesrvm/mm/mminterface/MemoryManager; allocateScalar(ILorg/jikesrvm/objectmodel/TIB;IIII)Ljava/lang/Object; at line 651
      at Lorg/jikesrvm/runtime/RuntimeEntrypoints; resolvedNewScalar(ILorg/jikesrvm/objectmodel/TIB;ZIIII)Ljava/lang/Object; at line 296
      at Lorg/jikesrvm/Callbacks; addExitMonitor(Lorg/jikesrvm/Callbacks$ExitMonitor;)V at line 773
      at Lorg/jikesrvm/mm/mminterface/Monitor; boot()V at line 27
      at Lorg/jikesrvm/mm/mminterface/MemoryManager; boot(Lorg/jikesrvm/runtime/BootRecord;)V at line 130
      at Lorg/jikesrvm/VM; finishBooting()V at line 187
      at Lorg/jikesrvm/VM; boot()V at line 158

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              steveblackburn Steve Blackburn added a comment -

              This is apparently AIX-specific (can't reproduce on PPC-32 linux). I suspect it is a page size issue. There was an implicit assumption that Immix's block size (64KB) was greater than or equal to page size.

              In r15520 I've cleaned the code up a little, improved the assertions and made block size be max(default, pagesize).

              Show
              steveblackburn Steve Blackburn added a comment - This is apparently AIX-specific (can't reproduce on PPC-32 linux). I suspect it is a page size issue. There was an implicit assumption that Immix's block size (64KB) was greater than or equal to page size. In r15520 I've cleaned the code up a little, improved the assertions and made block size be max(default, pagesize).
              Hide
              dgrove David Grove added a comment -

              piano is a ppc linux machine.

              Perhaps 15520 cleaned it up, but it was still broken on ppc32-linux as of r15503.

              http://jikesrvm.anu.edu.au/cattrack/results/piano.watson.ibm.com/sanity-ppc32/7969

              Show
              dgrove David Grove added a comment - piano is a ppc linux machine. Perhaps 15520 cleaned it up, but it was still broken on ppc32-linux as of r15503. http://jikesrvm.anu.edu.au/cattrack/results/piano.watson.ibm.com/sanity-ppc32/7969
              Hide
              steveblackburn Steve Blackburn added a comment -

              OK. Thanks Dave, I missed that. I could not reproduce on our test machine (porcupine, which is a peer to serrano, Power5). Possibly piano is using superpages? Anyway, r15520 both attempts to deal with that possibility and adds better sanity checking, so hopefully the next PPC run will either run clean or give a more helpful diagnosis.

              Show
              steveblackburn Steve Blackburn added a comment - OK. Thanks Dave, I missed that. I could not reproduce on our test machine (porcupine, which is a peer to serrano, Power5). Possibly piano is using superpages? Anyway, r15520 both attempts to deal with that possibility and adds better sanity checking, so hopefully the next PPC run will either run clean or give a more helpful diagnosis.
              Hide
              dgrove David Grove added a comment -

              r15520 just missed the start of sanity on piano, so I ran FullAdaptiveImmix manually against r15521.

              Both ppc32-linux and ppc64-linux fail all tests with with stackdumps like the one appended below during memory manager booting.

              Time to turn on more debugging are try something else?

              [dgrove@linchen basic]$ more TestFinally.default.txt
              Thread 1: VM.sysFail(): We're in a (likely) recursive call to VM.sysFail(), 2 deep
              sysFail was called with the message: vm internal error at:
              JikesRVM: internal error: recursive use of hardware exception registers in thread 0x32bcf404 (exiting)
              – Stack –
              at [0x32c1f9b4, 0x35d28a78] Lorg/jikesrvm/VM; sysFail(Ljava/lang/String;)V at line 2234
              at [0x32c1f9c4, 0x35471bbc] Lorg/jikesrvm/VM; _assertionFailure(Ljava/lang/String;Ljava/lang/String;)V at line 614
              at [0x32c1f9f4, 0x35470b9c] Lorg/jikesrvm/VM; _assert(ZLjava/lang/String;Ljava/lang/String;)V at line 597
              at [0x32c1f9f4, 0x35470b9c] Lorg/jikesrvm/VM; _assert(Z)V at line 575
              at [0x32c1f9f4, 0x35470b9c] Lorg/jikesrvm/scheduler/RVMThread; monitorForSlot(I)Lorg/jikesrvm/scheduler/NoYieldpointsCondLock; a
              t line 1084
              at [0x32c1f9f4, 0x35470b9c] Lorg/jikesrvm/scheduler/RVMThread; monitor()Lorg/jikesrvm/scheduler/NoYieldpointsCondLock; at line 1
              092
              at [0x32c1f9f4, 0x35470b9c] Lorg/jikesrvm/mm/mmtk/Lock; acquire()V at line 122
              at [0x32c1fa14, 0x3547f1dc] Lorg/mmtk/utility/heap/PageResource; lock()V at line 307
              at [0x32c1fa14, 0x3547f1dc] Lorg/mmtk/utility/heap/PageResource; reservePages(I)Z at line 149
              at [0x32c1fa14, 0x3547f1dc] Lorg/mmtk/policy/Space; acquire(I)Lorg/vmmagic/unboxed/Address; at line 386
              at [0x32c1fa34, 0x35497e9c] Lorg/mmtk/policy/immix/ImmixSpace; getSpace(ZZI)Lorg/vmmagic/unboxed/Address; at line 224
              at [0x32c1fa4c, 0x3549647c] Lorg/mmtk/utility/alloc/ImmixAllocator; allocSlowOnce(III)Lorg/vmmagic/unboxed/Address; at line 173
              at [0x32c1fa7c, 0x35d0f948] Lorg/mmtk/utility/alloc/Allocator; allocSlowInline(III)Lorg/vmmagic/unboxed/Address; at line 237
              at [0x32c1fa7c, 0x35d0f948] Lorg/mmtk/utility/alloc/ImmixAllocator; allocSlowHot(III)Lorg/vmmagic/unboxed/Address; at line 218
              at [0x32c1faac, 0x35cf5d58] Lorg/mmtk/utility/alloc/ImmixAllocator; alloc(III)Lorg/vmmagic/unboxed/Address; at line 112
              at [0x32c1faac, 0x35cf5d58] Lorg/mmtk/plan/immix/ImmixMutator; alloc(IIIII)Lorg/vmmagic/unboxed/Address; at line 77
              at [0x32c1faac, 0x35cf5d58] Lorg/jikesrvm/mm/mminterface/MemoryManager; allocateSpace(Lorg/jikesrvm/mm/mminterface/Selected$Muta
              tor;IIIII)Lorg/vmmagic/unboxed/Address; at line 761
              at [0x32c1faac, 0x35cf5d58] Lorg/jikesrvm/mm/mminterface/MemoryManager; allocateScalar(ILorg/jikesrvm/objectmodel/TIB;IIII)Ljava
              /lang/Object; at line 670
              at [0x32c1faac, 0x35cf5d58] Lorg/jikesrvm/runtime/RuntimeEntrypoints; resolvedNewScalar(ILorg/jikesrvm/objectmodel/TIB;ZIIII)Lja
              va/lang/Object; at line 325
              at [0x32c1faac, 0x35cf5d58] Lorg/jikesrvm/runtime/RuntimeEntrypoints; deliverHardwareException(II)V at line 730
              at [0x32c1fadc, 0x35cf5d58] <hardware trap>
              at [0x32c1fae8, 0x35d21010] Lorg/jikesrvm/scheduler/RVMThread; traceback(Ljava/lang/String;)V at line 4352
              at [0x32c1faf8, 0x35d28a78] Lorg/jikesrvm/VM; sysFail(Ljava/lang/String;)V at line 2234
              at [0x32c1fb08, 0x35bff318] Lorg/jikesrvm/VM; _assertionFailure(Ljava/lang/String;Ljava/lang/String;)V at line 614
              at [0x32c1fb38, 0x35bec868] Lorg/jikesrvm/VM; _assert(ZLjava/lang/String;Ljava/lang/String;)V at line 597
              at [0x32c1fb38, 0x35bec868] Lorg/jikesrvm/VM; _assert(Z)V at line 575
              at [0x32c1fb38, 0x35bec868] Lorg/jikesrvm/runtime/Memory; zeroPages(Lorg/vmmagic/unboxed/Address;I)V at line 428
              at [0x32c1fb60, 0x3547fd88] Lorg/jikesrvm/mm/mmtk/Memory; zeroPages(Lorg/vmmagic/unboxed/Address;I)V at line 163
              at [0x32c1fb60, 0x3547fd88] Lorg/mmtk/policy/immix/Chunk; clearMetaData(Lorg/vmmagic/unboxed/Address;)V at line 88
              at [0x32c1fb70, 0x3547479c] Lorg/mmtk/policy/immix/ImmixSpace; growSpace(Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Exten
              t;Z)V at line 253
              at [0x32c1fb88, 0x35470c20] Lorg/mmtk/utility/heap/FreeListPageResource; allocPages(I)Lorg/vmmagic/unboxed/Address; at line 174
              at [0x32c1fbc8, 0x3547f1dc] Lorg/mmtk/utility/heap/PageResource; getNewPages(I)Lorg/vmmagic/unboxed/Address; at line 234
              at [0x32c1fbc8, 0x3547f1dc] Lorg/mmtk/policy/Space; acquire(I)Lorg/vmmagic/unboxed/Address; at line 395
              at [0x32c1fbe8, 0x35497e9c] Lorg/mmtk/policy/immix/ImmixSpace; getSpace(ZZI)Lorg/vmmagic/unboxed/Address; at line 224
              at [0x32c1fc00, 0x3549647c] Lorg/mmtk/utility/alloc/ImmixAllocator; allocSlowOnce(III)Lorg/vmmagic/unboxed/Address; at line 173
              at [0x32c1fc30, 0x35704fac] Lorg/mmtk/utility/alloc/Allocator; allocSlowInline(III)Lorg/vmmagic/unboxed/Address; at line 237
              at [0x32c1fc30, 0x35704fac] Lorg/mmtk/utility/alloc/ImmixAllocator; allocSlowHot(III)Lorg/vmmagic/unboxed/Address; at line 218
              at [0x32c1fc60, 0x35cee5d0] Lorg/mmtk/utility/alloc/ImmixAllocator; alloc(III)Lorg/vmmagic/unboxed/Address; at line 112
              at [0x32c1fc60, 0x35cee5d0] Lorg/mmtk/plan/immix/ImmixMutator; alloc(IIIII)Lorg/vmmagic/unboxed/Address; at line 77
              at [0x32c1fc60, 0x35cee5d0] Lorg/jikesrvm/mm/mminterface/MemoryManager; allocateSpace(Lorg/jikesrvm/mm/mminterface/Selected$Mutator;IIIII)Lorg/vmmagic/unboxed/Address; at line
              761
              at [0x32c1fc60, 0x35cee5d0] Lorg/jikesrvm/mm/mminterface/MemoryManager; allocateScalar(ILorg/jikesrvm/objectmodel/TIB;IIII)Ljava/lang/Object; at line 670
              at [0x32c1fc60, 0x35cee5d0] Lorg/jikesrvm/runtime/RuntimeEntrypoints; resolvedNewScalar(ILorg/jikesrvm/objectmodel/TIB;ZIIII)Ljava/lang/Object; at line 325
              at [0x32c1fc60, 0x35cee5d0] Lorg/jikesrvm/Callbacks; addExitMonitor(Lorg/jikesrvm/Callbacks$ExitMonitor;)V at line 773
              at [0x32c1fc80, 0x35d29b64] Lorg/jikesrvm/mm/mminterface/Monitor; boot()V at line 27
              at [0x32c1fc80, 0x35d29b64] Lorg/jikesrvm/mm/mminterface/MemoryManager; boot(Lorg/jikesrvm/runtime/BootRecord;)V at line 129
              at [0x32c1fc90, 0x35d2ab6c] Lorg/jikesrvm/VM; finishBooting()V at line 174
              at [0x32c1fcb8, 0x35d2aae0] Lorg/jikesrvm/VM; boot()V at line 145

              Show
              dgrove David Grove added a comment - r15520 just missed the start of sanity on piano, so I ran FullAdaptiveImmix manually against r15521. Both ppc32-linux and ppc64-linux fail all tests with with stackdumps like the one appended below during memory manager booting. Time to turn on more debugging are try something else? [dgrove@linchen basic] $ more TestFinally.default.txt Thread 1: VM.sysFail(): We're in a (likely) recursive call to VM.sysFail(), 2 deep sysFail was called with the message: vm internal error at: JikesRVM: internal error: recursive use of hardware exception registers in thread 0x32bcf404 (exiting) – Stack – at [0x32c1f9b4, 0x35d28a78] Lorg/jikesrvm/VM; sysFail(Ljava/lang/String;)V at line 2234 at [0x32c1f9c4, 0x35471bbc] Lorg/jikesrvm/VM; _assertionFailure(Ljava/lang/String;Ljava/lang/String;)V at line 614 at [0x32c1f9f4, 0x35470b9c] Lorg/jikesrvm/VM; _assert(ZLjava/lang/String;Ljava/lang/String;)V at line 597 at [0x32c1f9f4, 0x35470b9c] Lorg/jikesrvm/VM; _assert(Z)V at line 575 at [0x32c1f9f4, 0x35470b9c] Lorg/jikesrvm/scheduler/RVMThread; monitorForSlot(I)Lorg/jikesrvm/scheduler/NoYieldpointsCondLock; a t line 1084 at [0x32c1f9f4, 0x35470b9c] Lorg/jikesrvm/scheduler/RVMThread; monitor()Lorg/jikesrvm/scheduler/NoYieldpointsCondLock; at line 1 092 at [0x32c1f9f4, 0x35470b9c] Lorg/jikesrvm/mm/mmtk/Lock; acquire()V at line 122 at [0x32c1fa14, 0x3547f1dc] Lorg/mmtk/utility/heap/PageResource; lock()V at line 307 at [0x32c1fa14, 0x3547f1dc] Lorg/mmtk/utility/heap/PageResource; reservePages(I)Z at line 149 at [0x32c1fa14, 0x3547f1dc] Lorg/mmtk/policy/Space; acquire(I)Lorg/vmmagic/unboxed/Address; at line 386 at [0x32c1fa34, 0x35497e9c] Lorg/mmtk/policy/immix/ImmixSpace; getSpace(ZZI)Lorg/vmmagic/unboxed/Address; at line 224 at [0x32c1fa4c, 0x3549647c] Lorg/mmtk/utility/alloc/ImmixAllocator; allocSlowOnce(III)Lorg/vmmagic/unboxed/Address; at line 173 at [0x32c1fa7c, 0x35d0f948] Lorg/mmtk/utility/alloc/Allocator; allocSlowInline(III)Lorg/vmmagic/unboxed/Address; at line 237 at [0x32c1fa7c, 0x35d0f948] Lorg/mmtk/utility/alloc/ImmixAllocator; allocSlowHot(III)Lorg/vmmagic/unboxed/Address; at line 218 at [0x32c1faac, 0x35cf5d58] Lorg/mmtk/utility/alloc/ImmixAllocator; alloc(III)Lorg/vmmagic/unboxed/Address; at line 112 at [0x32c1faac, 0x35cf5d58] Lorg/mmtk/plan/immix/ImmixMutator; alloc(IIIII)Lorg/vmmagic/unboxed/Address; at line 77 at [0x32c1faac, 0x35cf5d58] Lorg/jikesrvm/mm/mminterface/MemoryManager; allocateSpace(Lorg/jikesrvm/mm/mminterface/Selected$Muta tor;IIIII)Lorg/vmmagic/unboxed/Address; at line 761 at [0x32c1faac, 0x35cf5d58] Lorg/jikesrvm/mm/mminterface/MemoryManager; allocateScalar(ILorg/jikesrvm/objectmodel/TIB;IIII)Ljava /lang/Object; at line 670 at [0x32c1faac, 0x35cf5d58] Lorg/jikesrvm/runtime/RuntimeEntrypoints; resolvedNewScalar(ILorg/jikesrvm/objectmodel/TIB;ZIIII)Lja va/lang/Object; at line 325 at [0x32c1faac, 0x35cf5d58] Lorg/jikesrvm/runtime/RuntimeEntrypoints; deliverHardwareException(II)V at line 730 at [0x32c1fadc, 0x35cf5d58] <hardware trap> at [0x32c1fae8, 0x35d21010] Lorg/jikesrvm/scheduler/RVMThread; traceback(Ljava/lang/String;)V at line 4352 at [0x32c1faf8, 0x35d28a78] Lorg/jikesrvm/VM; sysFail(Ljava/lang/String;)V at line 2234 at [0x32c1fb08, 0x35bff318] Lorg/jikesrvm/VM; _assertionFailure(Ljava/lang/String;Ljava/lang/String;)V at line 614 at [0x32c1fb38, 0x35bec868] Lorg/jikesrvm/VM; _assert(ZLjava/lang/String;Ljava/lang/String;)V at line 597 at [0x32c1fb38, 0x35bec868] Lorg/jikesrvm/VM; _assert(Z)V at line 575 at [0x32c1fb38, 0x35bec868] Lorg/jikesrvm/runtime/Memory; zeroPages(Lorg/vmmagic/unboxed/Address;I)V at line 428 at [0x32c1fb60, 0x3547fd88] Lorg/jikesrvm/mm/mmtk/Memory; zeroPages(Lorg/vmmagic/unboxed/Address;I)V at line 163 at [0x32c1fb60, 0x3547fd88] Lorg/mmtk/policy/immix/Chunk; clearMetaData(Lorg/vmmagic/unboxed/Address;)V at line 88 at [0x32c1fb70, 0x3547479c] Lorg/mmtk/policy/immix/ImmixSpace; growSpace(Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Exten t;Z)V at line 253 at [0x32c1fb88, 0x35470c20] Lorg/mmtk/utility/heap/FreeListPageResource; allocPages(I)Lorg/vmmagic/unboxed/Address; at line 174 at [0x32c1fbc8, 0x3547f1dc] Lorg/mmtk/utility/heap/PageResource; getNewPages(I)Lorg/vmmagic/unboxed/Address; at line 234 at [0x32c1fbc8, 0x3547f1dc] Lorg/mmtk/policy/Space; acquire(I)Lorg/vmmagic/unboxed/Address; at line 395 at [0x32c1fbe8, 0x35497e9c] Lorg/mmtk/policy/immix/ImmixSpace; getSpace(ZZI)Lorg/vmmagic/unboxed/Address; at line 224 at [0x32c1fc00, 0x3549647c] Lorg/mmtk/utility/alloc/ImmixAllocator; allocSlowOnce(III)Lorg/vmmagic/unboxed/Address; at line 173 at [0x32c1fc30, 0x35704fac] Lorg/mmtk/utility/alloc/Allocator; allocSlowInline(III)Lorg/vmmagic/unboxed/Address; at line 237 at [0x32c1fc30, 0x35704fac] Lorg/mmtk/utility/alloc/ImmixAllocator; allocSlowHot(III)Lorg/vmmagic/unboxed/Address; at line 218 at [0x32c1fc60, 0x35cee5d0] Lorg/mmtk/utility/alloc/ImmixAllocator; alloc(III)Lorg/vmmagic/unboxed/Address; at line 112 at [0x32c1fc60, 0x35cee5d0] Lorg/mmtk/plan/immix/ImmixMutator; alloc(IIIII)Lorg/vmmagic/unboxed/Address; at line 77 at [0x32c1fc60, 0x35cee5d0] Lorg/jikesrvm/mm/mminterface/MemoryManager; allocateSpace(Lorg/jikesrvm/mm/mminterface/Selected$Mutator;IIIII)Lorg/vmmagic/unboxed/Address; at line 761 at [0x32c1fc60, 0x35cee5d0] Lorg/jikesrvm/mm/mminterface/MemoryManager; allocateScalar(ILorg/jikesrvm/objectmodel/TIB;IIII)Ljava/lang/Object; at line 670 at [0x32c1fc60, 0x35cee5d0] Lorg/jikesrvm/runtime/RuntimeEntrypoints; resolvedNewScalar(ILorg/jikesrvm/objectmodel/TIB;ZIIII)Ljava/lang/Object; at line 325 at [0x32c1fc60, 0x35cee5d0] Lorg/jikesrvm/Callbacks; addExitMonitor(Lorg/jikesrvm/Callbacks$ExitMonitor;)V at line 773 at [0x32c1fc80, 0x35d29b64] Lorg/jikesrvm/mm/mminterface/Monitor; boot()V at line 27 at [0x32c1fc80, 0x35d29b64] Lorg/jikesrvm/mm/mminterface/MemoryManager; boot(Lorg/jikesrvm/runtime/BootRecord;)V at line 129 at [0x32c1fc90, 0x35d2ab6c] Lorg/jikesrvm/VM; finishBooting()V at line 174 at [0x32c1fcb8, 0x35d2aae0] Lorg/jikesrvm/VM; boot()V at line 145
              Hide
              steveblackburn Steve Blackburn added a comment -

              I'll need to do another sanity check. However it looks like the assertion that is failing here (Lorg/jikesrvm/runtime/Memory; zeroPages(Lorg/vmmagic/unboxed/Address;I)V at line 428) is one for which I explicitly added a check upstream in Lorg/mmtk/policy/immix/Chunk; clearMetaData in r15520, and which is apparently not failing. Strange. Will look into it.

              Show
              steveblackburn Steve Blackburn added a comment - I'll need to do another sanity check. However it looks like the assertion that is failing here (Lorg/jikesrvm/runtime/Memory; zeroPages(Lorg/vmmagic/unboxed/Address;I)V at line 428) is one for which I explicitly added a check upstream in Lorg/mmtk/policy/immix/Chunk; clearMetaData in r15520, and which is apparently not failing. Strange. Will look into it.
              Hide
              zyridium Daniel Frampton added a comment -

              So, JIRA lost my longer, clearer comment so I will just summarize

              1) PPC64/RHEL has a 2^16 page size. Our PPC machines here use 4k pages.

              2) SizeConstants has 2^12 hard coded as page size, which is just going to be wrong... But it might not matter so long as we know that our page size can be a bit of a lie. Evidently most of the system already knows this as other collectors seem to work (maybe we can even transparently use superpages for some things in our current setup).

              3) Immix is the only user of zeroPages. It should probably use zero, which does the 'right' thing under any situation.... We should change this independent of what we decide for this issue. I have made this trivial change to Immix, and we can think about removing zeroPages later if it makes sense.

              I have made the change for Immix to use zero in 15532, but leaving this issue open to deal with the page size issue more completely.

              Show
              zyridium Daniel Frampton added a comment - So, JIRA lost my longer, clearer comment so I will just summarize 1) PPC64/RHEL has a 2^16 page size. Our PPC machines here use 4k pages. 2) SizeConstants has 2^12 hard coded as page size, which is just going to be wrong... But it might not matter so long as we know that our page size can be a bit of a lie. Evidently most of the system already knows this as other collectors seem to work (maybe we can even transparently use superpages for some things in our current setup). 3) Immix is the only user of zeroPages. It should probably use zero, which does the 'right' thing under any situation.... We should change this independent of what we decide for this issue. I have made this trivial change to Immix, and we can think about removing zeroPages later if it makes sense. I have made the change for Immix to use zero in 15532, but leaving this issue open to deal with the page size issue more completely.
              Hide
              steveblackburn Steve Blackburn added a comment -

              I'm afraid I did not get any time to look at this today, but Daniel is right. The MMTk assertions were using LOG_BYTES_IN_PAGE, while the rvm one called a sysCall to figure out the real value.

              Two comments:

              1) supposedly zeroPages is the right thing to use if you're zeroing pages (which is why Immix used it . Presumably the underlying system could use mmap /dev/zero or whatever. So in theory at least, there is a reason for having zero pages.

              2) it is insane to have two inconsistent ways of determining page size (one of which is plain wrong). That's the real bug and we need to fix it. Although the other collectors "work" despite this brokenness, it is entirely reasonable to make optimizations and design decisions on the basis of page size (as Immix explicitly does in its effort to reduce TLB traffic via appropriate block sizing).

              So while r15532 should get immix working again on PPC, it is not a fix since it simply side-steps the real problem.

              Show
              steveblackburn Steve Blackburn added a comment - I'm afraid I did not get any time to look at this today, but Daniel is right. The MMTk assertions were using LOG_BYTES_IN_PAGE, while the rvm one called a sysCall to figure out the real value. Two comments: 1) supposedly zeroPages is the right thing to use if you're zeroing pages (which is why Immix used it . Presumably the underlying system could use mmap /dev/zero or whatever. So in theory at least, there is a reason for having zero pages. 2) it is insane to have two inconsistent ways of determining page size (one of which is plain wrong). That's the real bug and we need to fix it. Although the other collectors "work" despite this brokenness, it is entirely reasonable to make optimizations and design decisions on the basis of page size (as Immix explicitly does in its effort to reduce TLB traffic via appropriate block sizing). So while r15532 should get immix working again on PPC, it is not a fix since it simply side-steps the real problem.
              Hide
              dgrove David Grove added a comment -

              Tested 15532 on piano and can confirm that it sidesteps the problem.

              So, that removes the blocker to switching to GenImmix as the default collector if we're ready to think about doing that.

              Show
              dgrove David Grove added a comment - Tested 15532 on piano and can confirm that it sidesteps the problem. So, that removes the blocker to switching to GenImmix as the default collector if we're ready to think about doing that.

                People

                • Assignee:
                  steveblackburn Steve Blackburn
                  Reporter:
                  dgrove David Grove
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: