Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.0, 3.0.1
-
Fix Version/s: 3.1.0
-
Component/s: Instruction Architecture: PowerPC, Operating System: Linux
-
Labels:None
-
Number of attachments :
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
Issue Links
Activity
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.
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.
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).