The preprocessor defines ENABLE_LOGGING_AND_PROFILING and ENABLE_VMSTATE_TRACKING has been removed as these where required to be turned on for Crankshaft to work. To re-enable reducing the binary size by leaving out heap and CPU profiler a new set of defines needs to be created.
R=ager@chromium.org
BUG=v8:1271
TEST=all
Review URL: http://codereview.chromium.org//7350014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8622 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
We now only recognize "native function" when it occurs in extension scripts
(parsing with a non-NULL extension), and only if there is no line-terminator
between "native" and "function" (so that it would otherwise be a Syntax Error).
Preparsing never recognizes native functions, which is acceptable since we
never preparse extension scripts (because we don't allow lazy functions
anyway).
BUG=v8:1097
Review URL: http://codereview.chromium.org/7206020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8326 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Before, they had no extra slots and an extension object with one named
property. Now, they use the extension slot for the property name and have
an extra slot for the thrown object. This increases the size of the context
itself, but removes overall allocation and eliminates a level of indirection.
R=ager@chromium.org
Review URL: http://codereview.chromium.org/7152002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8277 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
Mainly, there were errors concerning blank lines before and after class access
control sections [whitespace/blank_line].
BEFORE an access control section (e.g. public:, private:) there should be a
blank line (except for the section right after the class declaration).
AFTER an access control section there should be no blank line.
TBR=ager@chromium.org
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8193 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We used to have a linked list of nodes that were internally
block-allocated.
I kept the node blocks and put them on two lists: 1) the list of all
allocated blocks, 2) the list of blocks with used nodes. (1) is used
to reclaim blocks and (2) is used for traversal during GC. To make
traversal on scavenges faster the nodes holding new space objects are
grouped in an auxiliary array.
This changes the minimal memory usage from 5 words per global handle
to 4. Additional word is used for new space handles.
Review URL: http://codereview.chromium.org/7054072
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8186 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The current json parser and scanner inherits fromt he normal scanners and parsers,
which are more complicated than we need for parsing json.
The supplied scanner works directly on the string supplied and has a
fast case mode for scanning only ascii characters (it will simply
create a substring or a symbol directly from the existing string). To
allow for creating symbols from a substring I have added a
SubStringAsciiSymbolKey that creates the hash based from our string
without extracting the sub-string. In case we need to add the symbol
it simply creates the symbol directly from the characters inside the
given string.
Review URL: http://codereview.chromium.org/7039037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8029 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
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
Non-moveable code-stube are allocated in large object space. They are only required on ARM where the different C-entry stubs are required to never move.
This gets rid of pre-computing these stubs and hope that they never move. Also for crankshaft the C-entry stub which saved doubles is not generated in the snapshot so it ends up being generated at runtime and potentially move.
Review URL: http://codereview.chromium.org/6626072
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7097 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
- var eval | arguments
- catch (eval | arguments)
- 'with' is disabled
- function can't be named eval or arguments
Add FLAG_strict_mode
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6422 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- var eval | arguments
- catch (eval | arguments)
- 'with' is disabled
- function can't be named eval or arguments
- function parameter name cannot be eval or arguments
- no duplicate parameter names allowed
Add FLAG_strict_mode
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6369 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently weak handles retain an object for another GC round (oftem times,
major GC round.) Instrumenting Chromium shows that navigation leaves
many global objects which are only collected in next go. Let's
attempt to collect more garbage when approacing OOM condition.
This is a better version of rolled out r5455: now it's correctly
rebuilds object groups between additional GCs.
Review URL: http://codereview.chromium.org/4295004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5761 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently weak handles retain an object for another GC round (oftem times,
major GC round.) Instrumenting Chromium shows that navigation leaves
many global objects which are only collected in next go. Let's
attempt to collect more garbage when approacing OOM condition.
Review URL: http://codereview.chromium.org/3327021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5455 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
the code object's instructions.
This allows us to find a code object using just the pc. This approach
uses a cache (PcToCodeCache) to make sure we don't continuously have
to iterate heap pages.
This change eliminates the need for cooking and uncooking of stack frames.
Review URL: http://codereview.chromium.org/3226014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5369 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
Object model changes
----------------------------------------
New fixed_cow_array_map is used for the elements array of a JSObject
to mark it as COW. The JSObject's map and other fields are not
affected. The JSObject's map still has the "fast elements" bit set. It
means we can do only the receiver map check in keyed loads and the
receiver and the elements map checks in keyed stores. So introducing
COW arrays doesn't hurt performance of these operations. But note that
the elements map check is necessary in all mutating operations because
the "has fast elements" bit now means "has fast elements for reading".
EnsureWritableFastElements can be used in runtime functions to perform
the necessary lazy copying.
Generated code changes
----------------------------------------
Generic keyed load is updated to only do the receiver map check (this
could have been done earlier). FastCloneShallowArrayStub now has two
modes: clone elements and use COW elements. AssertFastElements macro
is added to check the elements when necessary. The custom call IC
generators for Array.prototype.{push,pop} are updated to avoid going
to the slow case (and patching the IC) when calling the builtin should
work.
COW enablement
----------------------------------------
Currently we only put shallow and simple literal arrays in the COW
mode. This is done by the parser.
Review URL: http://codereview.chromium.org/3144002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5275 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
That could allow us to understand why commit of from space sometimes fails.
Another option would be start a separate structure with OS-related info, but
as it's a single field, let's put it into HeapStats, at least for now.
Review URL: http://codereview.chromium.org/3118013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5261 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Use virtually dispatched specialized scavengers instead of single generic ScavengeObjectSlow implementation.
Rollback of r5041 with assertion checking callback alignment removed. Map space is iterated in a special fashion during scavenges so special callback alignment is not required.
Review URL: http://codereview.chromium.org/2950003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5047 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Stable high survival rates of young objects both during partial and
full collection indicate that mutator is either building or modifying
a structure with a long lifetime.
In this case we aggressively raise old generation memory limits to
postpone subsequent mark-sweep collection and trade memory space
for the mutation speed.
Review URL: http://codereview.chromium.org/2809032
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4938 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If a two-byte string only contains ascii characters, then we can save
memory when flattening a cons string containing it. Similarly we can
use this in Array.prototype.join implementation. To track this a new
bit is added to instance type. This bit is used as a hint in generated
code and in runtime functions.
To enable testing a new V8 extension is added controlled by
--expose-externalize-string flag.
Review URL: http://codereview.chromium.org/2762008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4894 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Changed the disposal of external string resources to call a virtual Dispose method on the resource. The default inplementation of Dispose deletes the object and will capture the delete operator matching the new operator used to allocate the object.
Review URL: http://codereview.chromium.org/2658008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4816 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This adds an additional step to full gc, removing code from functions
that are no longer in the compilation cache. The code is replaced with
a lazy compile version enabling us to recompile the function in case
we do actually need it again.
Review URL: http://codereview.chromium.org/2632003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4814 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- New сardmarking write barrier handles large objects and normal objects in a similar fashion (no more additional space for pointer tracking is required, no conditional branches in WB code).
- Changes to enable oldspaces iteration without maps decoding:
-- layout change for FixedArrays: length is stored as a smis (initial patch by
Kevin Millikin)
-- layout change for SharedFunctionInfo: integer fields are stored as smi on
arm, ia32 and rearranged on x64.
-- layout change for String: meaning of LSB bit is fliped (1 now means hash not
computed); on x64 padding is added.
-- layout of maps is _not_ changed. Map space is currently iterated in a special
way.
Review URL: http://codereview.chromium.org/2144006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4715 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-- layout change for FixedArrays: length is stored as a smis (initial patch by Kevin Millikin)
-- layout change for SharedFunctionInfo: integer fields are stored as smi on arm, ia32 and rearranged on x64.
-- layout change for String: meaning of LSB bit is fliped (1 now means hash not computed); on x64 padding is added.
-- layout of maps is _not_ changed. Map space is currently iterated in a special way.
- Cardmarking write barrier. New barrier handles large objects and normal objects in a similar fashion (no more additional space for pointer tracking is required, no conditional branches in WB code).
Review URL: http://codereview.chromium.org/2101002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4685 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
registration of external references in Proxy objects).
I moved the declaration of the two functions to stub-cache.h
because with all the types they use it's hard to declare them
anywhere else. But the actual definition is still in runtime.cc
near to the place where they are used.
Review URL: http://codereview.chromium.org/1079012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4231 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
Remove messages.h from v8.h and include it explicitly in only the few places
it is needed. Many files relied on getting handles-inl.h implicitly from
messages.h through v8.h, so include handles-inl.h explicitly in v8.h
instead.
Remove zone-inl.h from header files where it is not needed, can be replaced
by a forward declaration, or can be replaced by zone.h (specifically,
factory.h and heap.h). Include zone.h or zone-inl.h in header files where
it was implicitly included via heap.h or factory.h. Prefer zone.h over
zone-inl.h in header files where possible by including zone-inl.h in .cc
files.
Review URL: http://codereview.chromium.org/668248
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4058 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Thus, now there is a "generic" SplayTree and its Zone-bound
specialization ZoneSplayTree.
This is needed for my reimplementation of profiler tree generation in
C++. As generation is performed in a separate thread, Zone can't be
used, because it intentionally not thread-safe.
Review URL: http://codereview.chromium.org/660280
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3990 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
