Hi all,<br><br>This is Hal Mo<<a href="mailto:kungu.mjh@taobao.com">kungu.mjh@taobao.com</a>> from Alibaba Group(with OCA).<br><br>Our hadoop namenode crashed, when we set the heap size to 135G using CMS GC.<br>Attached please find the crash log(hs_err_pid.log).<br>
<br>I can steadily reproduce the crash on a test machine with 190G physical memory, by a simple command:<br>$ java -Xmx135g -XX:+UseConcMarkSweepGC<br><br>Then I build a debug jvm and use gdb to debug the problem.<br><br>
call stack<br><br>C  [libc.so.6+0x7a9b0]  memset+0x40<br>V  [libjvm.so+0x2b6c42]  BlockOffsetArray::set_remainder_to_point_to_start_incl(unsigned long, unsigned long, bool)+0xce<br>V  [libjvm.so+0x2b7043]  BlockOffsetArray::set_remainder_to_point_to_start(HeapWord*, HeapWord*, bool)+0x71<br>
V  [libjvm.so+0x2b728d]  BlockOffsetArray::BlockOffsetArray(BlockOffsetSharedArray*, MemRegion, bool)+0x9f<br>V  [libjvm.so+0x3c089f]  BlockOffsetArrayNonContigSpace::BlockOffsetArrayNonContigSpace(BlockOffsetSharedArray*, MemRegion)+0x37<br>
V  [libjvm.so+0x3be56f]  CompactibleFreeListSpace::CompactibleFreeListSpace(BlockOffsetSharedArray*, MemRegion, bool, FreeBlockDictionary::DictionaryChoice)+0x9b<br>V  [libjvm.so+0x3fd2e1]  ConcurrentMarkSweepGeneration::ConcurrentMarkSweepGeneration(ReservedSpace, unsigned long, int, CardTableRS*, bool, FreeBlockDictionary::DictionaryChoice)+0x1df<br>
V  [libjvm.so+0x4dc03e]  GenerationSpec::init(ReservedSpace, int, GenRemSet*)+0x37c<br>V  [libjvm.so+0x4ced40]  GenCollectedHeap::initialize()+0x510<br>V  [libjvm.so+0x7c23c3]  Universe::initialize_heap()+0x31d<br>V  [libjvm.so+0x7c27ec]  universe_init()+0xa6<br>
V  [libjvm.so+0x5056e2]  init_globals()+0x34<br>V  [libjvm.so+0x7ac926]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x23a<br>V  [libjvm.so+0x53f3d4]  JNI_CreateJavaVM+0x7a<br><br>in function BlockOffsetArray::set_remainder_to_point_to_start_inc, inside the for loop:<br>
    size_t reach = start_card - 1 + (power_to_cards_back(i+1) - 1);<br>when i = 7, the value of reach was 0. then the loop could not break, and <br>    _array->set_offset_array(start_card_for_region, reach, offset, reducing);<br>
accessed the wrong address, and crashed.<br><br>the root cause was <br>static size_t power_to_cards_back(uint i) {<br>    return (size_t)(1 << (LogBase * i));<br>}<br>the literal 1 is a 32bit int, and 1<<32 overflow. <br>
<br><br>Here was my fix(has been tested), also found in attached file cms_large_heap_crash.patch<br><br>+++ b/src/share/vm/memory/blockOffsetTable.hpp<br>@@ -289,7 +289,7 @@<br>};<br><br>static size_t power_to_cards_back(uint i) {<br>
- return (size_t)(1 << (LogBase * i));<br>+ return (size_t)1 << (LogBase * i);<br>}<br>static size_t power_to_words_back(uint i) {<br>return power_to_cards_back(i) * N_words;<br><br>Contributed-by: Hal Mo <<a href="mailto:kungu.mjh@taobao.com">kungu.mjh@taobao.com</a>> <br>
<br>Similar situation also found in G1, but the size is mega(2^20) based. 2^(32+20) is too large to overflow.<br><br>Krystal remind me, this changeset cover the same code, <a href="http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c3a720eefe82">http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c3a720eefe82</a>  .<br>
I do not  build it on visual studio, someone please help to review the compatibility with VS.<br><br>Regards,<br><br>Hal<br>