A separate object type for the code cache have been added. This object has two different code caches. The first one (default_cache) is a fixed array organized in the same way as the as the code cache was before. The second cache (global_access_cache) is for code stubs to access the global object. This cache is organized as a hash table taking the property name and code flags as the key.
The reason for separating the global access stubs into a hash table representation is that the number of these is not bounded in the same was as the other types.
BUG=613
Review URL: http://codereview.chromium.org/652119
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3952 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Moved all the logic to a function on SharedFunctionInfo (including the flag check) to make things more readable.
Changed the check for setter to do a lookup for a named setter for each of the properties assigned in the constructor.
Added tests using accessors and interseptors set through the API.
Added fast case objects to the mjsunit test.
TEST=test/mjsunit/setter-on-constructor-prototype.js
TEST=test/cctest/test-api/SetterOnConstructorPrototype
TEST=test/cctest/test-api/InterceptorOnConstructorPrototype
Review URL: http://codereview.chromium.org/619006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3893 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Simple objects which are constructed without calling the actual constructor function did not take setters defined on prototype chain of the new object into account.
Constructing objects this way is now not done if there are setters involved on the prototype chain of the new object.
This only fixes the case where the setter is found when the first object from a constructor is created. If the prototype chain is changed new objects will on take any change to setters into account.
TEST=test/mjsunit/setter-on-constructor-prototype.js
Review URL: http://codereview.chromium.org/606062
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3879 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
NumberToString in runtime JavaScript is inlined through a call to a stub. Currently the stub only checks the number string cache and only if the number is a smi. Code is shared with the inlining of number string cache lookup when adding a smi to a string.
Review URL: http://codereview.chromium.org/604062
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3865 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When functions only have simple assignments of the form this.x = ... the object is created in generated code without actually calling the constructor. In this case the initial map for the function already contains the properties assigned in the constructor. The field descriptors in this initial map now has an enumeration index assigned to make property enumeration order the insertion order. The insertion order here is the order of the this.x assignments in the code.
BUG=http://crbug.com/3867
TEST=test/mjsunit/regress/regress-crbug-3867.js
Review URL: http://codereview.chromium.org/566016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3768 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
1. Avoid using SKIP_WRITE_BARRIER when we don't have to (smis).
2. Check and document the remaining uses of SKIP_WRITE_BARRIER.
3. Only allow GetWriteBarrierMode when in an AssertNoAllocation scope.
The only functional change should be in DeepCopyBoilerplate where we
no longer use the write barrier mode (because of allocations). I'm
running benchmarks to see if this has a measurable impact on performance.
Review URL: http://codereview.chromium.org/558041
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3743 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
objects in the startup heap from a partial snapshot. This happens
through the partial snapshot cache. A startup snapshot and a
partial snapshot are created together so that the startup snapshot
contains the partial snapshot cache entries needed.
Review URL: http://codereview.chromium.org/548149
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3713 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
that attempt to run with a small heap. Additionally, it can
potentially keep a lot of string data alive and it is never flushed.
Can we make it grow dynamically if used so that we can still start the
VM with a small heap size?
Review URL: http://codereview.chromium.org/503081
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3517 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
