• sgjesse@chromium.org's avatar
    Extend the maximum size map space · 44b7c59e
    sgjesse@chromium.org authored
    On 32-bit the maps are now aligned on a 32-byte boundary in order to encode more maps during compacting GC. The actual size of a map on 32-bit is 28 bytes making this change waste 4 bytes per map.
    
    On 64-bit the encoding for compacting GC is now using more than 32-bits and the maps here are still pointer size aligned. The actual size of a map on 64-bit is 48 bytes and this change does not intruduce any waste.
    
    My choice of 16 bits for kMapPageIndexBits for 64-bit should give the same maximum number of pages (8K) for map space. As maps on 64-bit are larger than on 32-bit the total number of maps on 64-bit will be smaller than on 32-bit. We could consider raising this to 17 or 18.
    
    I moved the kPageSizeBits to globals.h as the calculation of the encoding really depended on this.
    
    There are still an #ifdef/#endif in objects.h and this constant could be moved to globaks.h as well, but I kept it together with the related constants.
    
    All the tests run in debug mode with additional options --gc-global --always-compact as well (except for a few tests on which also fails before this change when run with --gc-global --always-compact).
    
    BUG=http://code.google.com/p/v8/issues/detail?id=524
    BUG=http://crbug.com/29428
    TEST=test/mjsunit/regress/regress-524.js
    
    Review URL: http://codereview.chromium.org/504026
    
    git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3481 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
    44b7c59e
Name
Last commit
Last update
benchmarks Loading commit data...
include Loading commit data...
samples Loading commit data...
src Loading commit data...
test Loading commit data...
tools Loading commit data...
.gitignore Loading commit data...
AUTHORS Loading commit data...
ChangeLog Loading commit data...
LICENSE Loading commit data...
SConstruct Loading commit data...