This fixes a corner case when the instance prototype of a function is
changed while inobject slack tracking is still in progress. This caused
the intial map to be unrelated for functions with the same shared info
and hence the shared construct stub is no longer generic enough to work
for all those functions.
R=danno@chromium.org
BUG=chromium:157019
TEST=mjsunit/regress/regress-crbug-157019
Review URL: https://codereview.chromium.org/11293059
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12896 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Highlights of this CL:
* Introduced a new opcode in the deoptimizer for a setter stub frame.
* Added a global setter stub for returning after deoptimizing a setter.
* We do not need special deopt support for getters, although the getter stub creates an internal frame. The normal machinery works just right for this case, although we generate a stack that can never occur during normal fullcode execution. If this hurts us one day, we can parameterize and reuse the setter deopt machinery.
Review URL: https://chromiumcodereview.appspot.com/10855098
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12328 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in anticipation of the upcoming lexical global scope.
Mostly automatised as:
for FILE in `egrep -ril "global[ _]?context" src test/cctest`
do
echo $FILE
sed "s/Global context/Native context/g" <$FILE >$FILE.0
sed "s/global context/native context/g" <$FILE.0 >$FILE.1
sed "s/global_context/native_context/g" <$FILE.1 >$FILE.2
sed "s/GLOBAL_CONTEXT/NATIVE_CONTEXT/g" <$FILE.2 >$FILE.3
sed "s/GlobalContext/NativeContext/g" <$FILE.3 >$FILE
rm $FILE.[0-9]
done
R=mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10832342
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12325 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This fixes the positive lookup performed by these LoadICs, to use the
holder instead of the receiver to perfrom the lookup on. It also extends
this improvement to KeyedLoadICs. And it fixes a bug introduced for the
JavaScript getter case of a LoadIC.
R=erik.corry@gmail.com
BUG=chromium:142088
TEST=cctest/test-api/Regress142088,cctest/test-api/Regress137002b
Review URL: https://chromiumcodereview.appspot.com/10828303
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12311 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Ensure that IsFound() is only used when not in combination with other
checks. To do so, the default type is NONEXISTENT rather than NORMAL;
and NotFound() also resets the type to NONEXISTENT.
- Use test methods rather than .type() == A_PROPERTY_TYPE.
Review URL: https://chromiumcodereview.appspot.com/10626004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11899 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Removes 6 out of 8 of our remaining unintentional failures on test262.
Also fixes treatment of inherited setters added after the fact.
Specifically:
- In the runtime, when looking for setter callbacks in the prototype chain,
also look for read-only properties. If one is found, reject (exception in
strict mode). If a proxy is found, invoke proper trap.
Note: this folds in the CanPut function from the spec and avoids an extra
lookup over the prototype chain.
- In generated code for stores, insert a test for the maps from the prototype
chain, but only up to the object where the property already exists (which
may be the object itself).
In Hydrogen, if the found property is read-only or not cacheable (e.g. a
proxy), bail out; in a stub, generate an unconditional miss (to get an
exception in strict mode).
- Add test cases and adapt existing test expectations.
R=mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10388047
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11694 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Some GWT compiled code results in array access that has a heap number (e.g. -0)
as an index. Until now this would result in a generic IC.
For example:
a[-0] === a[0] or
a[0.25 * 4] === a[1]
This change detects heap numbers that are representable as a smi
and converts them. As a result we can still use the fast keyed monomorphic
ICs. Optimized code already handles keyed access with a double-key efficiently.
As a result the frame rate on the reported benchmark improves by roughly 2x.
BUG=v8:1388,v8:1295
Review URL: https://chromiumcodereview.appspot.com/9837109
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11282 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Yak shaving for map sharing with accessor properties contd.: When CALLBACKS can
have map transitions, simply looking at the property type is not sufficient
anymore to decide if a property is there or not. One has to look at the actual
contents of the descriptor entry then, but this breaks down sometimes when the
lookup is being done with a NULL holder. Luckily enough, we can oftren replace
IsProperty by the simpler IsFound, because we inspect the type immediately
afterwards, anyway.
Review URL: https://chromiumcodereview.appspot.com/9280007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10474 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Loosen the requirement for Map equivalency on several map checks, including checks up the prototype chain, that are not sensitive to ElementsKinds. These selected map checks should also match against FAST_DOUBLE_ELEMENT and FAST_ELEMENT transitions of the original map. This specifically helps all variants of transitioned JSArrays to still efficiently call builtins like push, pop and sort.
BUG=none
TEST=none
Committed: http://code.google.com/p/v8/source/detail?r=10331
Review URL: http://codereview.chromium.org/9015020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10356 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Loosen the requirement for Map equivalency on several map checks, including checks up the prototype chain, that are not sensitive to ElementsKinds. These selected map checks should also match against FAST_DOUBLE_ELEMENT and FAST_ELEMENT transitions of the original map. This specifically helps all variants of transitioned JSArrays to still efficiently call builtins like push, pop and sort.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/9015020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10331 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
This function relies on a number of helpers for checking prototypes and
probing dictionaries. It is not possible to wrap these helpers to retry
after allocation failure in a safe way---the assembler has no way to undo
what it has already assembled.
These functions have all been duplicated with handle and raw versions. The
raw versions will eventually be removed completely.
R=ulan@chromium.org,vegorov@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8332003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9769 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
1) Don't make a call to C without having a valid frame on the stack.
2) Don't generate a call to a stub while generating a stub, unless we can be
sure that the stub we are calling has already been generated (the stub
generation code is not reentrant wrt. GC).
Review URL: http://codereview.chromium.org/7891042
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9297 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
KeyedLoadStubCompiler::GenerateLoadExternalArray is tail-calling a stub, which it is not allowed to, because its major key is higher than InstanceOf. Instead of changing the major key I decided to provide an inline implementation.
TEST=test-api/ExternalArrays with --noenable-vfp3
R=danno@chromium.org
Review URL: http://codereview.chromium.org/7060007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8002 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