The object's space in Page starts after Page header and is aligned to kMapAlignment which is 32 bytes on 32-bit and 8 bytes on 64-bit.
In case of 64-bit target, the current page header size is exactly 32 bytes so we get the code magically aligned at 32 bytes but it is better to have a separate CODE_POINTER_ALIGN macro to make sure the object space in Page is aligned properly for both maps and code.
There could be a small waste of bytes sometimes (since both Page header and Code header sizes are aligned separately) but it seems the optimal one would involve cross-dependencies between .h files and not clear if it's worth it.
This is a back-port from Isolates branch.
Review URL: http://codereview.chromium.org/3461021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5526 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Allows the host application to provide a mechanism for notification and custom logging through a callback (set through the API V8::AddMemoryAllocationCallback and removed through V8::RemoveMemoryAllocationCallback), when V8 allocates ro frees memory.
This replaces the current histogram data "V8.ExecutableMemoryMax" by allowing usage data to be logged by the application as required rather than always through V8.
BUG=http://crbug.com/54222
TEST=Set the callback function with the API and cause V8 to allocate memory.
Patch by Paul Mehta <pmehta@chromium.org>
Review URL: http://codereview.chromium.org/3329006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5403 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
That could improve chances for commit success as currently,
if we moved free pages out of order, we cannot shrink spaces.
However, when we experience problems commiting from space back, we should
use most of resources at our disposal.
Also get rid of currently unused parameter to DeallocateFunction.
Review URL: http://codereview.chromium.org/3260001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5372 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
the code object's instructions.
This allows us to find a code object using just the pc. This approach
uses a cache (PcToCodeCache) to make sure we don't continuously have
to iterate heap pages.
This change eliminates the need for cooking and uncooking of stack frames.
Review URL: http://codereview.chromium.org/3226014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5369 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- New сardmarking write barrier handles large objects and normal objects in a similar fashion (no more additional space for pointer tracking is required, no conditional branches in WB code).
- Changes to enable oldspaces iteration without maps decoding:
-- layout change for FixedArrays: length is stored as a smis (initial patch by
Kevin Millikin)
-- layout change for SharedFunctionInfo: integer fields are stored as smi on
arm, ia32 and rearranged on x64.
-- layout change for String: meaning of LSB bit is fliped (1 now means hash not
computed); on x64 padding is added.
-- layout of maps is _not_ changed. Map space is currently iterated in a special
way.
Review URL: http://codereview.chromium.org/2144006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4715 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-- layout change for FixedArrays: length is stored as a smis (initial patch by Kevin Millikin)
-- layout change for SharedFunctionInfo: integer fields are stored as smi on arm, ia32 and rearranged on x64.
-- layout change for String: meaning of LSB bit is fliped (1 now means hash not computed); on x64 padding is added.
-- layout of maps is _not_ changed. Map space is currently iterated in a special way.
- Cardmarking write barrier. New barrier handles large objects and normal objects in a similar fashion (no more additional space for pointer tracking is required, no conditional branches in WB code).
Review URL: http://codereview.chromium.org/2101002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4685 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- RelinkPageListInChunkOrder might relink unused pages into the middle of a sequence of used pages. Filler objects should be placed at the beginning of such unused pages otherwise generic iterators (e.g. HeapObjectIterator) would not handle them correctly.
- ObjectAreaEnd() should not be used as an allocation limit for pages from FixedSpace. Pages in such spaces do not use top page_extra_ bytes of object area.
TBR=ager@chromium.org
Review URL: http://codereview.chromium.org/1700005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4476 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Always invoke HeapObjectIterator::has_next() before invoking HeapObjectIterator::next().
This is necessary as ::has_next() has an important side-effect of going to the next
page when current page is exhausted.
And to find if pointers are encodable use more precise data---top of map space, not a number
of pages, as pages might stay in map space due to chunking.
Review URL: http://codereview.chromium.org/552066
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3672 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
for partial snapshots. After reserving space we can be sure that allocations
will happen linearly (no GCs and no free-list allocation). This change also
contains the start of the partial snapshot support, which, however is not yet
completed or tested.
Review URL: http://codereview.chromium.org/545026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3584 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
Additionally fix NewSpace capacity bug by removing the duplicated
capacity and maximum capacity book keeping. The capacity and maximum
capacity of NewSpace is the capacity and maximum capacity of one of
it's semispaces.
Review URL: http://codereview.chromium.org/174052
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2717 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
