true. The rules are:
1. Heap::AllocateRaw can normally handle allocation requests in new
space even when always_allocate() is true. It properly retries
failed allocation in the second 'retry' space.
2. Heap::Allocate can normally handle allocation requests in new
space.
3. We only need to check always_allocate() when explicitly requesting
allocation in new space via Heap::new_space().AllocateRaw().
4. The exception to these rules is fixed arrays with size such that
MaxObjectSizeInPagedSpace < size <= MaxObjectSizeInNewSpace (ie,
those that will be allocated in new space and promoted to large
object space). They cannot be allocated in new space via
Heap::Allocate or Heap::AllocateRaw, because the retry logic does
not know to allocate extra remembered set bits when retrying in
large object space.
Review URL: http://codereview.chromium.org/518007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3535 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
Instead of weak handles external strings use a separate table. This
table uses 5 times less memory than weak handles. Moreover, since we
don't have to follow the weak handle callback protocol we can collect
the strings faster and even on scavenge collections.
Review URL: http://codereview.chromium.org/467037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3439 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The different length string types was used to encode the string length and the hash in one field. This is now split into two fields one for length and one for hash. The hash field still encodes the array index of the string if it has one. If an array index is encoded in the hash field the string length is added to the top bits of the hash field to avoid a hash value of zero.
On 32-bit this causes an additional 4 bytes to be used for all string objects. On 64-bit this will be half on average dur to pointer alignment.
Review URL: http://codereview.chromium.org/436001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3350 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If V8 is holding on to a lot of external memory, we attempt to clean
it up even if we do not get an allocation failure. Since tiny V8
objects can hold on to a lot of external memory, we might run out of
external memory while waiting for a normal allocation failure.
Review URL: http://codereview.chromium.org/155916
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2519 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
space is similar to map space in that it has fixed-size objects. A
common superclass for a space with fixed size objects is used for the
map space and cell space.
Allocate all cells in cell space. Handle it during all GCs. Modify
the free-list node representation (so that the size is not at a fixed
offset in all cells) to allow two-pointer free-list nodes. Clean up
some stuff in the MC collector.
Review URL: http://codereview.chromium.org/155211
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2411 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This issue was raised by Brett Wilson while reviewing my changelist for readability. Craig Silverstein (one of C++ SG maintainers) confirmed that we should declare one namespace per line. Our way of namespaces closing seems not violating style guides (there is no clear agreement on it), so I left it intact.
Review URL: http://codereview.chromium.org/115756
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2038 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in the old generation while its remembered set is being swept for
pointers into the young generation. This is done by delaying the
copying of promoted objects from when they are first encountered and
promoted to only when their body is visited.
Review URL: http://codereview.chromium.org/115086
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1971 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
it for scripts too. In the context of Chromium, this should
have a very positive impact on memory consumption for web apps
that run multiple tabs from the same domain with a lot of the
same JavaScript code.
For now, the cache retirement policy is really simple:
Whenever a mark-sweep collection is started we clear the
cache. This guarantees that this change will not have a
huge negative impact on memory consumption, but it may
not be ideal. We should consider a more sophisticated LRU
scheme.
Review URL: http://codereview.chromium.org/1933
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@270 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Make old_data_space non-executable on OSs and hardware that support it.
* Rename old_space to old_pointer_space (can contain pointers, esp. to new space).
* Ensure that individual pages allocated for old_space are only executable when
they are for code objects.
* Ensure Space::Setup can cope with non-aligned memory.
* Make some methods on Spaces virtual. Make a way to iterate over all spaces.
* Replace executability flag with Executability enum in order to make intent at
call site clearer.
* Fix serialization/deserialization to allocate write barrier memory for large
arrays.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@165 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added better test support.
Added load, quit and version functions to the shell sample so it's easier to run benchmarks and tests.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added a few samples and support for building them. The samples include a simple shell that can be used to benchmark and test V8.
Changed V8::GetVersion to return the version as a string.
Added source for lazily loaded scripts to snapshots and made serialization non-destructive.
Improved ARM support by fixing the write barrier code to use aligned loads and stores and by removing premature locals optimization that relied on broken support for callee-saved registers (removed).
Refactored the code for marking live objects during garbage collection and the code for allocating objects in paged spaces. Introduced an abstraction for the map word of a heap-allocated object and changed the memory allocator to allocate executable memory only for spaces that may contain code objects.
Moved StringBuilder to utils.h and ScopedLock to platform.h, where they can be used by debugging and logging modules. Added thread-safe message queues for dealing with debugger events.
Fixed the source code reported by toString for certain builtin empty functions and made sure that the prototype property of a function is enumerable.
Improved performance of converting values to condition flags in generated code.
Merged disassembler-{arch} files.
git-svn-id: http://v8.googlecode.com/svn/trunk@8 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
