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
CPU-eating DOS attacks against node.js servers. Based on code from
Bert Belder. This version only solves the issue for those that compile
V8 themselves or those that do not use snapshots. A snapshot-based
precompiled V8 will still have predictable string hash codes.
Review URL: http://codereview.chromium.org/9086006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10330 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
This shaves 416+ KB, just under 1% off the size of the debug d8 executable
on Linux (mostly because the CheckHelper functions for assertions were
getting separate copies for each compilation unit). The difference in
release builds is negligible---a size reduction of 0.1%.
Also, change namespace-level 'static const' variables to remove the static
storage class as it's the default.
R=danno@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8680013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10083 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
Changes the way we do lazy deoptimization:
1. For side-effect instructions, we insert the lazy-deopt call at
the following LLazyBailout instruction.
CALL
GAP
LAZY-BAILOUT ==> lazy-deopt-call
2. For other instructions (StackCheck) we insert it right after the
instruction since the deopt targets an earlier deoptimization environment.
STACK-CHECK
GAP ==> lazy-deopt-call
The pc of the lazy-deopt call that will be patched in is recorded in the
deoptimization input data. Each Lithium instruction can have 0..n safepoints.
All safepoints get the deoptimization index of the associated LAZY-BAILOUT
instruction. On lazy deoptimization we use the return-pc to find the safepoint.
The safepoint tells us the deoptimization index, which in turn finds us the
PC where to insert the lazy-deopt-call.
Additional changes:
* RegExpLiteral marked it as having side-effects so that it
gets an explicitlazy-bailout instruction (instead of
treating it specially like stack-checks)
* Enable target recording CallFunctionStub to achieve
more inlining on optimized code.
BUG=v8:1789
TEST=jslint and uglify run without crashing, mjsunit/compiler/regress-lazy-deopt.js
Review URL: http://codereview.chromium.org/8492004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10006 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Original commit message:
Add a level of indirection to exception handler addresses.
To support deoptimization of exception handlers, the handler address in the
stack is converted to a pair of code object and an index into a separate
table of code offsets. The index part is invariant under deoptimization.
The index is packed into the handler state field so that handler size does
not change.
R=vegorov@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8538011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9977 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To support deoptimization of exception handlers, the handler address in the
stack is converted to a pair of code object and an index into a separate
table of code offsets. The index part is invariant under deoptimization.
The index is packed into the handler state field so that handler size does
not change.
R=vegorov@chromium.org,fschneider@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8462010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9975 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This also refactors the way we set the length of an arrays' backing
store to use the new elements accessor interface. The actual fix is in
DictionaryElementsAccessor::SetLengthWithoutNormalize() where we first
search for non-deletable elements according to ES5 section 15.4.5.2
specifications.
Snippet from the specification: Attempting to set the length property of
an Array object to a value that is numerically less than or equal to the
largest numeric property name of an existing array indexed non-deletable
property of the array will result in the length being set to a numeric
value that is one greater than that largest numeric property name.
R=danno@chromium.org
TEST=test262/15.4.4.??-7-b-16
Review URL: http://codereview.chromium.org/8372064
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9911 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
This implementation extends the internal ObjectHashTable to be able to
hold arbitrary objects (e.g. Smis, Strings, ...) as keys by applying
specialized hashing functions to primitive types. Equality of keys is
defined using the internal SameValue function.
R=rossberg@chromium.org
BUG=v8:1622
TEST=mjsunit/harmony/collections
Review URL: http://codereview.chromium.org/8372027
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9777 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
This implements block scoped 'const' declared variables in harmony mode. They
have a temporal dead zone semantics similar to 'let' bindings, i.e. accessing
uninitialized 'const' bindings in throws a ReferenceError.
As for 'let' bindings, the semantics of 'const' bindings in global scope is not
correctly implemented yet. Furthermore assignments to 'const's are silently
ignored. Another CL will introduce treatment of those assignments as early
errors.
Review URL: http://codereview.chromium.org/7992005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9764 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This also includes the two fixes from r9674 and r9675. Here's the diff
to the previous CL.
--- a/src/runtime.cc
+++ b/src/runtime.cc
@@ -11133,17 +11133,26 @@ class ScopeIterator {
context_(Context::cast(frame->context())),
nested_scope_chain_(4) {
+ // Catch the case when the debugger stops in an internal function.
+ Handle<SharedFunctionInfo> shared_info(function_->shared());
+ if (shared_info->script() == isolate->heap()->undefined_value()) {
+ if (shared_info->scope_info()->HasContext()) Next();
+ return;
+ }
+
// Check whether we are in global code or function code. If there is a stack
// slot for .result then this function has been created for evaluating
// global code and it is not a real function.
// Checking for the existence of .result seems fragile, but the scope info
// saved with the code object does not otherwise have that information.
- int index = function_->shared()->scope_info()->
+ int index = shared_info->scope_info()->
StackSlotIndex(isolate_->heap()->result_symbol());
// Reparse the code and analyze the scopes.
ZoneScope zone_scope(isolate, DELETE_ON_EXIT);
- Handle<SharedFunctionInfo> shared_info(function_->shared());
Handle<Script> script(Script::cast(shared_info->script()));
Scope* scope;
if (index >= 0) {
Review URL: http://codereview.chromium.org/8344046
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9734 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is reapplying r9501 with this single change which seemed to be causing most (all) of the failures for r9501.
--- a/src/debug.cc
+++ b/src/debug.cc
@@ -2230,6 +2230,7 @@ Debugger::Debugger(Isolate* isolate)
compiling_natives_(false),
is_loading_debugger_(false),
never_unload_debugger_(false),
+ force_debugger_active_(true),
message_handler_(NULL),
debugger_unload_pending_(false),
host_dispatch_handler_(NULL),
R=kmillikin@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org//8337009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9684 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This refactoring (almost) gets rid of the requirement to get the target
object address for an object pointer embedded in code objects. This is
not possible on MIPS as pointers are encoded using two instructions. All
usages of RelocInfo::target_object_address() are (almost) obsoleted by
this change. The serializer still uses it, so MIPS will not yet work
with snapshots turned on.
R=danno@chromium.org,vegorov@chromium.org
Review URL: http://codereview.chromium.org/8245007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9597 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This eliminates compile-errors when assigning Handle<SerializedScopeInfo> to
Handle<Object> in a place where the declaration was not available because
variables.h was not included.
As a result I had to also move the enum Variable::Mode to v8globals.h and
rename it to VariableMode.
Review URL: http://codereview.chromium.org/8221004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9575 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previously, the logic using the hidden properties backing object was
spread accross use sites. Now it's all contained in JSObject, with
only simple accessors available.
Also change the backing object to be a StringDictionary rather than a JSObject.
There's still room for improvement by making a hash-table that don't
store property details as well.
Review URL: http://codereview.chromium.org/8050013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9510 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
While traversing the transition tree we build a work-list using the map
field of maps. Setting those map values with a write barrier causes
black-to-gray changes on maps which are currently not recognized as
such, hence their computed size might be off.
R=vegorov@chromium.org
BUG=v8:1672
TEST=cctest/test-decls/Present
Review URL: http://codereview.chromium.org/8082023
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9498 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change will ensure that full code with debug break slots is compiled and activated for all functions which already have activation frames.
This additional handling is only for functions which have activations on the stack, and that activation is of the full code compiled without debug break slots. In that case the full code is recompiled with debug break slots. It is ensured that the full code is compiled generating the exact same instructions - except for the additional debug break slots - as before. The return address on the stack is then patched to continue execution in the new code.
Also fixed SortedListBSearch to actually use the passed comparision function.
R=svenpanne@chromium.org, kmillikin@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org//8050010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9489 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Extract the part of SetPropertyForResult that searches the prototype chain
for accessor setters into a separate function SetPropertyInPrototypes.
Call this function in SetPropertyPostInterceptor.
This should fix both optimized and unoptimized cases because
the cache stub for storing with interceptor calls the runtime system.
BUG=v8:1636
TEST=cctest/test-api.cc/EmptyInterceptorDoesNotShadowAccessors
Review URL: http://codereview.chromium.org/7991007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9431 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This prevents potential misuse of SeqString::kHeaderSize as in the
case of live byte counting in incremental marking stub. All stubs
picked up the undefined size constant SeqString::kHeaderSize, thus
the computed size of all strings was off by two pointers slots.
R=lrn@chromium.org
BUG=v8:1672
TEST=mjsunit/object-seal.js,...
Review URL: http://codereview.chromium.org/7971009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9349 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change will ensure that all non-optimized code will be compiled
with debug break slots when debugging is initiated. This is handled by
scanning the heap for non-optimized functions without debug break slots and setting their code to be lazy recomplied. When the lazy recompilation happens the code will ge generated with debug break slots (if debugging is still active at that point in time).
R=svenpanne@chromium.org
Currently this is only implemented for functions which do not have activations on the stack.
BUG=
TEST=
Review URL: http://codereview.chromium.org//7839030
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9250 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Use the BitField helper class for the code flags, so that we do not have to
define both a shift and a mask explicitly. This makes changing the flags
layout simpler.
Also, make the 'mask' and 'max' members of BitField into constants, because
they are constant and so that they can be used as constant expressions.
E.g., so they can be used in declaring other const members or in static
asserts.
R=fschneider@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/7787028
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9232 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When recompiling code (e.g., when optimizing) we could incorrectly hoist
some function expressions. This leads to incorrect results or a crash. The
root cause was that functions were not correctly categorized as expression
or declaration at parse time.
This requires some extra hoops to prevent the print name "anonymous" for
functions created by 'new Function' from establishing a binding.
R=vegorov@chromium.org,kasperl@chromium.org
BUG=1583
TEST=regress-1583
Review URL: http://codereview.chromium.org/7572019
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8838 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Advantage is that it's much easier to add new element types (like FAST_SMI_ELEMENTS), and that handling logic for each element kind is (more) consolidated.
Currently, only GetElementsWithReceiver uses the new encapsulation, but the goal is to move much more element functionality into the class incrementally.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/7527001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8810 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
We did not properly combine the property names from the parameter map
and the arguments backing store. They could overwrite each other and
be unsorted.
Also fix an unrelated bug: deleting from a dictionary-mode arguments
backing store could corrupt the parameter map.
R=rossberg@chromium.org
BUG=1531
TEST=mjsunit/regress/regress-1531.js
Review URL: http://codereview.chromium.org/7278033
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8571 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Due to issues relating mostly to chrome extensions we have lately been
running into OOMs that are caused by our executable space running
out. This change introduces flushing of code from regexps if we have
not used the code for 5 mark sweeps.
The approach is different from the normal function code flusing. Here
we make a copy of the code inside the data array, and exchange the
original code with a smi determined by the sweep_generation (a new
heap variable increased everytime we do mark sweep/compact). If we
encounter a smi in EnsureCompiled we simply reinstate the code
object. If, in the marking phase of mark sweep, we find a regexp that
already have a smi in the code field, and this is more than 5
generations old we flush the code from the saved index.
Review URL: http://codereview.chromium.org/7282026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8532 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Lots of web pages have really frequently firing timers that keep the
profiler thread spinning if we require a period of JS inactivity
before suspending the profiler. While it's possible to throttle it by
increasing the sleep delay and adjusting the duration of the required
inactive period, it seemed much simpler to just stop it immediately on
exiting JS.
Stopping the profiler this way effectively turned off two optimization
heuristics: 1) eager optimization (it's reset on waking up the
profiler and now the profiler wakes up much more frequently) and 2)
optimization throttling based on JS to non-JS state ratio (the ratio
is now 100%). I removed these two heuristics and found no performance
regressions so far.
R=ager@chromium.org
BUG=crbug.com/77625
TEST=none
Review URL: http://codereview.chromium.org/7274024
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8472 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
