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 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
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
Replaced FIRST_PHANTOM_PROPERTY_TYPE by a predicate. Removed the (hopefully)
last default cases for switches on PropertyType. Benchmarks show that both
changes are performace-neutral.
Now every value of PropertyType should either be handled by an explicit case in
a switch or by an equality operator. Therefore, the C++ compiler should finally
be able to tell us which places to touch when changing PropertyType.
Review URL: http://codereview.chromium.org/8506004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9930 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 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
If a GC happened during initialization (when allocating the elements array)
of the non_strict_arguments_boilerplate, heap verification would fail with the following assert:
ASSERT_EQ((map()->has_fast_elements() || map()->has_fast_smi_only_elements()),
(elements()->map() == GetHeap()->fixed_array_map() ||
elements()->map() == GetHeap()->fixed_cow_array_map()));
This was not harmful since the boilerplate was setup
correctly immediatly afterwards.
Simplified the setup code by removing a call to GetElementsTransitionMap. It always return the same map as
the input object in this case and is therefore unnecessary.
Added more assertions to verify well-formed non-strict
arguments backing store.
BUG=v8:1520
TEST=no more flaky tests with failing this assert.
Review URL: http://codereview.chromium.org/8336021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9678 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
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
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
Introduce separate maps for function and with contexts. Use the function
context map for testing whether a context is a function context (global
contexts are no longer function contexts).
Split the paths for allocating with and catch contexts.
Rename some functions. Generally refactor code to make it simpler.
R=ager@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/7003058
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8231 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
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
1) Add new type JSProxy for representing proxy objects.
Currently devoid of functionality, i.e., all properties are undefined.
2) Some rudimentary global $Proxy functions to create proxies.
Next step: Hook up getProperty and getOwnProperty handlers. Will probably
require introducing a new LookupResult type, which is a mixture of
INTERCEPTOR (handles any property) and CALLBACK (calls back to JS).
Can we unify this somehow?
TODO: Should probably rename existing Proxy type to something like
"Foreign", to avoid confusion.
Review URL: http://codereview.chromium.org/6932068
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7887 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Crankshaft is now the default on all platforms. This is the first
patch on the way to removing the classic code generator from the
system.
This time with no removal of the crankshaft flag. --nocrankshaft is
not at all the same as --always-full-compiler which I had used instead
for testing. That was what caused timeouts on the buildbots because of
repeated attempts to optimize hot functions. It makes sense to keep
the crankshaft flag in case you want to run only with the full
compiler and with no adaptive compilation.
R=vitalyr@chromium.org
Review URL: http://codereview.chromium.org/6759070
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7486 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This commit adds current working versions of assembler, macro-assembler,
disassembler, and simulator.
All other mips arch files are replaced with stubbed-out versions that
will build.
Arch independent files are updated as needed to support building and
running mips.
The only test is cctest/test-assembler-mips, and this passes on the
simulator and on mips hardware.
TEST=none
BUG=none
Patch by Paul Lind from MIPS.
Review URL: http://codereview.chromium.org/6730029/
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7388 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
