Reviewers: Mads Ager, Kevin Millikin, Description: Extend the maximum size map space
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 Please review this at http://codereview.chromium.org/504026 SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/ Affected files: M src/globals.h M src/heap-inl.h M src/heap.h M src/heap.cc M src/objects-inl.h M src/objects.h M src/serialize.cc M src/spaces.h M src/spaces.cc A test/mjsunit/regress/regress-524.js -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
