- 14 Sep, 2012 18 commits
-
-
danno@chromium.org authored
In WebKit, we would like to store a void* to a data structure that contains lots of exciting per-context data. The current API restricts us to storing only Strings, which is less useful. I've also cleaned up the implementation of GetData to be less convoluted. Review URL: https://codereview.chromium.org/10907189 Patch from Adam Barth <abarth@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12520 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
TransitionArrays never allocate while being created. Review URL: https://chromiumcodereview.appspot.com/10908237 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12519 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=verwaest@chromium.org BUG=v8:2318 Review URL: https://chromiumcodereview.appspot.com/10914290 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12518 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
Review URL: https://chromiumcodereview.appspot.com/10918245 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12517 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
BUG=v8:2297 Review URL: https://chromiumcodereview.appspot.com/10914262 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12515 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
erik.corry@gmail.com authored
Review URL: https://chromiumcodereview.appspot.com/10915277 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12513 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
Review URL: https://chromiumcodereview.appspot.com/10928204 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12512 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
erik.corry@gmail.com authored
Review URL: https://chromiumcodereview.appspot.com/10917260 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12511 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
svenpanne@chromium.org authored
With this CL we clearly distinguish two different views on Lithium instructions: For register allocation, the actual instruction/operand is irrelevant, so it has only an iterator/indexed view on the instruction operands. All other places, most importantly code generation, use named getters for the operands now, making it easy to see where each one is used. Review URL: https://codereview.chromium.org/10919261 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12510 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
erik.corry@gmail.com authored
Review URL: https://chromiumcodereview.appspot.com/10913273 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12509 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
svenpanne@chromium.org authored
Review URL: https://codereview.chromium.org/10933087 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12508 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=jkummerow@chromium.org BUG=v8:2317 Review URL: https://chromiumcodereview.appspot.com/10911305 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12507 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
erik.corry@gmail.com authored
Review URL: https://chromiumcodereview.appspot.com/10928203 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12506 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
erik.corry@gmail.com authored
the speed of deserializing code. The current startup time improvement for V8 is around 6%, but code deserialization is speeded up disproportionately, and we will soon have more code in the snapshot. * Removed support for deserializing into large object space. The regular pages are 1Mbyte now and that is plenty. This is a big simplification. * Instead of reserving space for the snapshot we actually allocate it now. This removes some special casing from the memory management and simplifies deserialization since we are just bumping a pointer rather than calling the normal allocation routines during deserialization. * Record in the snapshot how much we need to boot up and allocate it instead of just assuming that allocations in a new VM will always be linear. * In the snapshot we always address an object as a negative offset from the current allocation point. We used to sometimes address from the start of the deserialized data, but this is less useful now that we have good support for roots and repetitions in the deserialization data. * Code objects were previously deserialized (like other objects) by alternating raw data (deserialized with memcpy) and pointers (to external references, other objects, etc.). Now we deserialize code objects with a single memcpy, followed by a series of skips and pointers that partially overwrite the code we memcopied out of the snapshot. The skips are sometimes merged into the following instruction in the deserialization data to reduce dispatch time. * Integers in the snapshot were stored in a variable length format that gives a compact representation for small positive integers. This is still the case, but the new encoding can be decoded without branches or conditional instructions, which is faster on a modern CPU. Review URL: https://chromiumcodereview.appspot.com/10918067 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12505 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mstarzinger@chromium.org authored
This makes sure we do not share optimized code across closures that were optimized using OSR (for a particular OSR entry AST id) even if caching of optimized code kicks in. R=danno@chromium.org BUG=v8:2326 TEST=mjsunit/regress/regress-2326 Review URL: https://codereview.chromium.org/10933088 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12504 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=jkummerow@chromium.org BUG=v8:2317 Review URL: https://chromiumcodereview.appspot.com/10917236 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12503 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
danno@chromium.org authored
R=yangguo@chromium.org Review URL: https://codereview.chromium.org/10907230 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12502 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
This fixes an omission in cl 10818026. Patch by Nathan Rajlich. Review URL: https://chromiumcodereview.appspot.com/10913256 Patch from Bert Belder <bertbelder@gmail.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12501 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 13 Sep, 2012 5 commits
-
-
verwaest@chromium.org authored
This is the only place from where we are allowed to modify the value of the descriptors pointer. Review URL: https://chromiumcodereview.appspot.com/10905266 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12500 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=jkummerow@chromium.org BUG=v8:2319 Review URL: https://chromiumcodereview.appspot.com/10928182 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12499 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
Review URL: https://chromiumcodereview.appspot.com/10905262 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12498 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mstarzinger@chromium.org authored
R=jkummerow@chromium.org BUG=chromium:148896 TEST=cctest/test-api/ExternalArrayLimits Review URL: https://codereview.chromium.org/10914257 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12495 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
BUG=chromium:148376 Review URL: https://chromiumcodereview.appspot.com/10908216 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12494 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Sep, 2012 8 commits
-
-
mmassi@chromium.org authored
Fixed bounds check removal by restricting it to int32 indexes (and reenabled both ABCR and index dehoisting). BUG= TEST= Review URL: https://chromiumcodereview.appspot.com/10905232 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12493 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
This CL adds multiple things: Transition arrays do not directly point at their descriptor array anymore, but rather do so via an indirect pointer (a JSGlobalPropertyCell). An ownership bit is added to maps indicating whether it owns its own descriptor array or not. Maps owning a descriptor array can pass on ownership if a transition from that map is generated; but only if the descriptor array stays exactly the same; or if a descriptor is added. Maps that don't have ownership get ownership back if their direct child to which ownership was passed is cleared in ClearNonLiveTransitions. To detect which descriptors in an array are valid, each map knows its own NumberOfOwnDescriptors. Since the descriptors are sorted in order of addition, if we search and find a descriptor with index bigger than this number, it is not valid for the given map. We currently still build up an enumeration cache (although this may disappear). The enumeration cache is always built for the entire descriptor array, even if not all descriptors are owned by the map. Once a descriptor array has an enumeration cache for a given map; this invariant will always be true, even if the descriptor array was extended. The extended array will inherit the enumeration cache from the smaller descriptor array. If a map with more descriptors needs an enumeration cache, it's EnumLength will still be set to invalid, so it will have to recompute the enumeration cache. This new cache will also be valid for smaller maps since they have their own enumlength; and use this to loop over the cache. If the EnumLength is still invalid, but there is already a cache present that is big enough; we just initialize the EnumLength field for the map. When we apply ClearNonLiveTransitions and descriptor ownership is passed back to a parent map, the descriptor array is trimmed in-place and resorted. At the same time, the enumeration cache is trimmed in-place. Only transition arrays contain descriptor arrays. If we transition to a map and pass ownership of the descriptor array along, the child map will not store the descriptor array it owns. Rather its parent will keep the pointer. So for every leaf-map, we find the descriptor array by following the back pointer, reading out the transition array, and fetching the descriptor array from the JSGlobalPropertyCell. If a map has a transition array, we fetch it from there. If a map has undefined as its back-pointer and has no transition array; it is considered to have an empty descriptor array. When we modify properties, we cannot share the descriptor array. To accommodate this, the child map will get its own transition array; even if there are not necessarily any transitions leaving from the child map. This is necessary since it's the only way to store its own descriptor array. Review URL: https://chromiumcodereview.appspot.com/10909007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12492 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=ulan@chromium.org BUG=148378 Review URL: https://chromiumcodereview.appspot.com/10905239 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12491 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mstarzinger@chromium.org authored
R=svenpanne@chromium.org Review URL: https://chromiumcodereview.appspot.com/10909190 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12490 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mstarzinger@chromium.org authored
This fixes materialization of arguments objects for strict mode functions during deoptimization. We materialize arguments from the stack area where optimized code pushes the arguments when entering the inlined environment. For adapted invocations we use the arguments adaptor frame for materialization. R=svenpanne@chromium.org BUG=v8:2261 TEST=mjsunit/regress/regress-2261,mjsunit/compiler/inline-arguments Review URL: https://chromiumcodereview.appspot.com/10908194 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12489 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
BUG= Review URL: https://chromiumcodereview.appspot.com/10917211 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12488 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
This was part of r12430 (http://codereview.chromium.org/10857030/) which has been reverted. R=ulan@chromium.org BUG= Review URL: https://chromiumcodereview.appspot.com/10913220 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12487 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
jkummerow@chromium.org authored
BUG=148389 Review URL: https://chromiumcodereview.appspot.com/10914222 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12486 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Sep, 2012 6 commits
-
-
yangguo@chromium.org authored
BUG=144649 Review URL: https://chromiumcodereview.appspot.com/10914201 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12485 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mmassi@chromium.org authored
BUG=141395 TEST= Review URL: https://chromiumcodereview.appspot.com/10919214 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12484 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
erik.corry@gmail.com authored
white objects when compacting. Add flag for incremental code compaction. Review URL: https://chromiumcodereview.appspot.com/10907174 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12483 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mstarzinger@chromium.org authored
R=jkummerow@chromium.org Review URL: https://chromiumcodereview.appspot.com/10911208 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12480 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
BUG= Review URL: https://chromiumcodereview.appspot.com/10928108 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12479 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
ulan@chromium.org authored
BUG=v8:2314 R=yangguo@chromium.org Review URL: https://chromiumcodereview.appspot.com/10908195 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12478 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 Sep, 2012 3 commits
-
-
peter.rybin@gmail.com authored
Committed: https://code.google.com/p/v8/source/detail?r=12346 Review URL: https://chromiumcodereview.appspot.com/10834376 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12477 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=svenpanne@chromium.org BUG= Review URL: https://chromiumcodereview.appspot.com/10928083 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12474 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mstarzinger@chromium.org authored
The deoptimizer searched the stack for activations of the same function to determine whether to trigger lazy deopting. Since we share optimized code we actually need to search for activations of the same code (but potentially different functions). R=jkummerow@chromium.org BUG=chromium:147475 TEST=mjsunit/regress/regress-crbug-147475 Review URL: https://chromiumcodereview.appspot.com/10917162 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12473 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-