This introduces an additional check into the StoreIC_ArrayLength builtin
checking that the array still has fast properties. Redifinitions of the
length property that would cause it's type or attributes to change, will
switch to slow properties, thereby invalidating said optimization.
R=svenpanne@chromium.org
BUG=v8:1756
TEST=test262
Review URL: http://codereview.chromium.org/8895025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10254 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Now with arm and x64 support. Additionally, added default unreachable case to switch statement in CompareIC::TargetState to make win and mac compilers happy.
Reviewer guide:
This is an exact copy of 10216 except:
src/arm/*
src/x64/*
src/ic.cc (added default case to swith in CompareIC::TargetState)
Review URL: http://codereview.chromium.org/8872060
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10219 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This includes specialcasing the generation when we know that the maps
of the two objects are the same. In addition, a new specialized
compare ic known objects cache is created.
The reason for the cache is that we need to have access to the stub
code from the roots; if we do not, the GC will collect the stub. In
this specialized case we use the map pointer as key in the cache, and
we always do a lookup before generating code. Actually hitting
something in the cache will happen very rarely, but we could
potentially overwrite an existing stub, which again will lead to the
GC collecting this old stub (even if it is referenced from other code
objects)
Review URL: http://codereview.chromium.org/8520006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10216 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL introduces a third mode next to the non-strict
(henceforth called 'classic mode') and 'strict mode'
which is called 'extended mode' as in the current
ES.next specification drafts. The extended mode is based on
the 'strict mode' and adds new functionality to it. This
means that most of the semantics of these two modes
coincide.
The 'extended mode' is entered instead of the 'strict mode'
during parsing when using the 'strict mode' directive
"use strict" and when the the harmony-scoping flag is
active. This should be changed once it is fully specified how the 'extended mode' is entered.
This change introduces a new 3 valued enum LanguageMode
(see globals.h) corresponding to the modes which is mostly
used by the frontend code. This includes the following
components:
* (Pre)Parser
* Compiler
* SharedFunctionInfo, Scope and ScopeInfo
* runtime functions: StoreContextSlot,
ResolvePossiblyDirectEval, InitializeVarGlobal,
DeclareGlobals
The old enum StrictModeFlag is still used in the backend
when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes:
* SetProperty runtime function, Delete builtin
* StoreIC and KeyedStoreIC
* StubCache
Review URL: http://codereview.chromium.org/8417035
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Do not rely on 'default' clauses or 'if's when analysing a PropertyType, because
this makes it hard to find the relevant places when a new type is added. Note
that the detection of "phantom property types" is left untouched, because this
might have a performance impact, especially for the GC (to be investigated).
This is a preliminary step for introducing a new kind of map transition.
Review URL: http://codereview.chromium.org/8491016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9900 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The IC records the set of types it has seen, e.g. {String} or {Boolean,
Undefined}, etc. Note that in theory this could lead to a large number of
different ToBoolean ICs (512, to be exact, because we distinguish 9 types),
but in practice only a small handful of them are actually generated.
Currently the type recording part is only implemented on ia32, other platforms
continue to work like they did before, though.
Removed some dead code on the way.
Review URL: http://codereview.chromium.org/7473028
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8716 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Introduce a class JSReceiver, that is a common superclass of JSObject and
JSProxy. Use JSReceiver where appropriate (probably lots of places that we
still have to migrate, but we will find those later with proxy test suite).
- Move appropriate methods to JSReceiver class (SetProperty,
GetPropertyAttribute, Get/SetPrototype, Lookup, and so on).
- Introduce new JSFunctionProxy subclass of JSProxy. Currently only a stub.
- Overhaul enum InstanceType:
* Introduce FIRST/LAST_SPEC_OBJECT_TYPE that ranges over all types that
represent JS objects, and use that consistently to check language types.
* Rename FIRST/LAST_JS_OBJECT_TYPE and FIRST/LAST_FUNCTION_CLASS_TYPE
to FIRST/LAST_[NON]CALLABLE_SPEC_OBJECT_TYPE for clarity.
* Eliminate the overlap over JS_REGEXP_TYPE.
* Also replace FIRST_JS_OBJECT with FIRST_JS_RECEIVER, but only use it where
we exclusively talk about the internal representation type.
* Insert JS_PROXY and JS_FUNCTION_PROXY in the appropriate places.
- Fix all checks concerning classification, especially for functions, to
use the CALLABLE_SPEC_OBJECT range (that includes funciton proxies).
- Handle proxies in SetProperty (that was the easiest part :) ).
- A few simple test cases.
R=kmillikin@chromium.org
Review URL: http://codereview.chromium.org/6992072
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8126 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Only IA32 version for now. I'll start porting.
Strict mode functions are to get 'undefined' as the receiver when
called with an implicit receiver. Modes are bad! It forces us to have
checks on all function calls.
This change attempts to limit the cost by passing information about
whether or not a call is with an implicit or explicit receiver in ecx
as part of the calling convention. The cost is setting ecx on all
calls and checking ecx on entry to strict mode functions.
Implicit/explicit receiver state has to be maintained by ICs. Various
stubs have to not clobber ecx or save and restore it.
CallFunction stub needs to check if the receiver is implicit when it
doesn't know from the context.
Review URL: http://codereview.chromium.org/7039036
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8040 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When the stub return a heap number we do a state transition to
a version HEAP_NUMBER that can handle -0.
There is room for further improvement in the typefeedback for the
case of -0. This change however does not address this and only fixes
the acute issue.
Review URL: http://codereview.chromium.org/7037025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7944 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Better support for 'polymorphic' JS and external arrays
Allow keyed store/load stubs to switch between external array and fast JS arrays without forcing a state transition to the generic stub.
There CL consists of two pieces of functionality. First, code stubs for fast element arrays don't immediately transition to the MEGAMORPHIC state when there's a map mismatch. Second, two ICs are cached per map for fast elements, the MONOMORPHIC version, and a new MEGAMORPHIC version that handles two or more different maps and dispatches to shared stubs to perform the array operation.
Review URL: http://codereview.chromium.org/7036016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7935 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Allow keyed store/load stubs to switch between external array and fast JS arrays without forcing a state transition to the generic stub.
There CL consists of two pieces of functionality. First, code stubs for fast element arrays don't immediately transition to the MEGAMORPHIC state when there's a map mismatch. Second, two ICs are cached per map for fast elements, the MONOMORPHIC version, and a new MEGAMORPHIC version that handles two or more different maps. Currently, the only array types supported by the MEGAMORPHIC stub are fast elements for objects and JSArrays.
BUG=
TEST=
Review URL: http://codereview.chromium.org/6894003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7917 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Worth mentioning:
- Specialized versions of pixel array and store/loads inside the generic stubs have been removed, since to have parity for all external arrays, 8 different versions would have to be inlined/checked.
- There's a new constant in v8.h for external arrays with pixel array elements.
Review URL: http://codereview.chromium.org/6546036
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7106 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Strict mode assignment to undefined reference.
Simple assignments (x = <value>) use CODE_TARGET_CONTEXT.
StoreIC stores its own strictness in extra_ic_state.
The strcitness is propagated as further ic stubs are generated.
Details:
* ReferenceError on assignment to non-resolvable reference in strict mode.
* Fix es5conform test expectation file.
* Add es5conform test suite into .gitignore.
* Fix Xcode project.
* Change implemented in virtual frame code generator, as well as full-codegen
for all architectures.
* Fix debugger test.
* Fix comment for CODE_TARGET_CONTEXT
* Implement remaining StoreIC stubs to be strict mode aware.
* Trace extra_ic_state() for ic code stubs.
Code Review URL: http://codereview.chromium.org/6474026/
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6760 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Strict mode assignment to undefined reference.
Simple assignments (x = <value>) use CODE_TARGET_CONTEXT.
StoreIC stores its own strictness in extra_ic_state.
The strcitness is propagated as further ic stubs are generated.
Details:
* ReferenceError on assignment to non-resolvable reference in strict mode.
* Fix es5conform test expectation file.
* Add es5conform test suite into .gitignore.
* Fix Xcode project.
* Change implemented in virtual frame code generator, as well as full-codegen
for all architectures.
* Fix debugger test.
* Fix comment for CODE_TARGET_CONTEXT
* Implement remaining StoreIC stubs to be strict mode aware.
* Trace extra_ic_state() for ic code stubs.
Code Review URL: http://codereview.chromium.org/6474026/
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6756 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To avoid deopts a few extra changes were needed:
o Enable megamorphic state for special property loads on
primitives. We used to flip between monomorphic stubs.
o Extract pure string (no string wrapper support) version of the
string length stub.
Review URL: http://codereview.chromium.org/6334015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6472 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implements the type recording binary operation stub for ARM. This first iteration only supports ADD. Handling of 32-bit integers is currently not implemented but just transitions. The generic case for now delegates to the generic binary operation stub.
Review URL: http://codereview.chromium.org/6342019
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6471 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
conversions for external array types, which implement the Typed Array
spec. (Revision of http://codereview.chromium.org/6315004 .)
Prefer SSE2 code path on x86 processors. Non-SSE2 processors now make
a slow runtime call for float-to-int conversions. Use SSE3 for 32-bit
signed and unsigned int array types where possible.
The movement of code from ic-arm.cc to stub-cache-arm.cc caused the
VFP3 code path to be tested for the first time. Fixed bugs in the
register usage and in the constant value stored into integer arrays
for NaN and +/-Infinity.
Added new truncation test to test-api.cc. Storage of NaN and +/-Inf
was already covered. Ran unit tests on x86, x64 and ARM simulator.
Tested ia32 and x64 code in Chromium on Mac and Linux respectively
with Typed Array unit tests and WebGL content.
BUG=http://code.google.com/p/chromium/issues/detail?id=50972
TEST=test-api/ExternalArrays
Review URL: http://codereview.chromium.org/6303012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6431 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Extra IC state is only two bits and only supported for call IC-s for
now. To change its extra state an IC stub jumps to a new miss stub
that goes to runtime as usual but then instead of going megamorphic
generates a monomorphic stub with the updated state.
Review URL: http://codereview.chromium.org/6344005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6370 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is an improved version of my earlier change r5970. It avoids degrading the
non-optimized code.
Initially we emit a conditional branch that is either always- or never-taken
after a smi-check (depending on whether we test for smi for for non-smi)
Since test-eax always sets the carry-flag to 0 we use jump-if-carry and
jump-if-not-carry.
The first invocation of the stub patches a jc with a jz and
jnc with a jnz-instruction so that the code looks exactly as it was
without patching. The only difference is the test- or nop-instruction
after the IC-call.
Review URL: http://codereview.chromium.org/5763004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6030 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the case of inlined smi code in non-optimzied code we could not
distinguish between the smi-only case and the case that the operation was
never executed.
With this change the first execution of a binary operation always jumps
to the stub which in turn patches the smi-check into the correct
conditional branch, so that we benefit from inlined smi code after the
first invocation.
A nop instruction after the call to the BinaryOpIC indicates that no
smi code was inlined. A "test eax" instruction says that there was smi
code inlined and encodes the delta to the patch site and the condition
code of the branch at the patch site to restore the original jump.
Review URL: http://codereview.chromium.org/5714001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5970 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Contextual load requires only a map check followed by a cell hole
check so we can generate pretty compact code for that. The fact that
we have inlined code is marked by mov ecx, offset instruction after
the IC call. Inlining is only enabled inside loops and in non-builtin
functions.
The generated code size increase is about 3%. This descreased the
pc-to-code cache hit rate in some of the benchmarks that trigger
GC. To compensate we now have 4 times as much entries in the cache.
Review URL: http://codereview.chromium.org/3402014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5497 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
r5147 wrongly assumed that a code cache for a slow case map is always empty.
This patch solves this: whenever we attempt to add a stub to a map's code cache
we check that this map is cached. If it is we give the object its own copy
of the map and only then modify the map.
Review URL: http://codereview.chromium.org/3134027
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5342 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
to the runtime will both patch in the more specialized binary op
stub and calculate the answer. This eliminates the need to call
both the rest of the binary op and the patching runtime call. The
runtime routines are altered to be more agressive in returning
Smis so we don't get spurious heap numbers as inputs to binary ops
while we are patching the binary op ICs.
Review URL: http://codereview.chromium.org/2843049
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5026 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The IC stub is completely generic, so there will only be one such stub
in the system.
Added a new overloaded version of the macro assembler RecordWrite
method for cases where we have the address we store to computed up
front.
Review URL: http://codereview.chromium.org/2804029
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4991 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
A potential issue with this change is creating lots of maps when
objects flip between fast/slow elements modes. We could add special
transitions to avoid this. Yet testing this on our benchmarks, gmail,
and wave seems to indicate that this is not a real problem.
Review URL: http://codereview.chromium.org/2870018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4941 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We need to be careful to check global property cells for the property
encountered during lookup. Therefore, the ICs have to be specific to
the name of the property if global objects are involved. In
principle, this means that we could get a large number of monomorphic
ICs for the same map if there is a global object in the prototype
chain. However, since this is only done for normal load ICs and not
for keyed load ICs I do not expect this to be a problem. I will
experiment with it once this goes in.
BUG=675
Review URL: http://codereview.chromium.org/1559033
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4426 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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.
This is a remake of r3952 (http://codereview.chromium.org/652119) which have the additional ability to look for the index of code stubs for access to the global object.
BUG=http://code.google.com/p/v8/issues/detail?id=613
Review URL: http://codereview.chromium.org/717001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4066 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Replaced IsValid by IsPropertyOrTransition and used IsProperty in most
of the places where IsValid was used before. Most of the time when
inspecting a lookup result we really want to know if there is a real
property present. Only for stores are we interested in transitions.
BUG=http://crbug.com/20104
TEST=cctest/test-api/NamedInterceptorMapTransitionRead
Review URL: http://codereview.chromium.org/647015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3901 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When a function is called with a value type as the receiver this is now boxed as an object.
This is a low-impact solution where the receiver is only boxed when required. For IC calls to the V8 builtins values are not boxed and as most of the functions on String.prototype, Number.prototype and Boolean.prototype are sitting there most IC calls on values will not need any boxing of the receiver.
For calls which are not IC calls but calls through the CallFunctionStub a flag is used to determine whether the receiver might be a value and only when that is the case will the receiver be boxed.
No changtes to Function.call and Function.apply - they already boxed values. According to the ES5 spec the receiver should not be boxed for these functions, but current browsers have not adopted that change yet.
BUG=223
TEST=test/mjsunit/value-wrapper.js
TEST=test/mjsunit/regress/regress-crbug-3184.js
Review URL: http://codereview.chromium.org/542087
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3617 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Instead of going through a runtime function for keyed loads
on strings we invoke a separate specialized stub that
assumes string as receiver type and the key to be a number.
The stub calls a JS builtin function to return the corresponding one-character string.
Review URL: http://codereview.chromium.org/521041
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3556 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
