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
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
- 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
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
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.
BUG=613
Review URL: http://codereview.chromium.org/652119
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3952 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
For scripts originating from a call to eval the Script object used to hold a reference to the function from where the eval was called together with the code offset within that function of the eval call. This is used by the stack trace and is part of the debugger protocol. In order to avoid storing the function the script, the position within the script and the name of the function calling eval is stored instead. This avoids holding context dependent objects in the script object.
The calculation of the position of the eval in the script holding the eval is now done when the eval script is compiled as it is not possible to postpone this unless a reference is kept to the generated code for the function calling eval.
BUG=http://code.google.com/p/v8/issues/detail?id=528
TEST=cctest/test-api/Regress528
Review URL: http://codereview.chromium.org/450034
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3393 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Storing a JSArray in the Script object could cause an indirect reference from the compilation cache to a global object to be created. Now the line ends are only stored as a FixedArrya and when that is needed in JavaScript a JSArray copy is created. Changed some of the JavaScript code to cache the line ends in a local variable for better performance.
BUG=http://code.google.com/p/v8/issues/detail?id=528
TEST=test/test-api/Bug528
Review URL: http://codereview.chromium.org/434117
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3374 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The different length string types was used to encode the string length and the hash in one field. This is now split into two fields one for length and one for hash. The hash field still encodes the array index of the string if it has one. If an array index is encoded in the hash field the string length is added to the top bits of the hash field to avoid a hash value of zero.
On 32-bit this causes an additional 4 bytes to be used for all string objects. On 64-bit this will be half on average dur to pointer alignment.
Review URL: http://codereview.chromium.org/436001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3350 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
of individual changes:
- Added infrastructure for custom stub caching.
- Push the code object onto the stack in exit calls instead of a
debug/non-debug marker.
- Remove the DEBUG_EXIT frame type.
- Add a new exit stub generator for API getters.
Review URL: http://codereview.chromium.org/330017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3130 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
specification under development. The optimizations are patterned after
those previously done for CanvasPixelArray. This CL adds all of the
necessary framework but continues to use the generic KeyedLoadIC and
KeyedStoreIC code, to create a baseline for benchmarking purposes. The
next CL will add the optimized ICs to ic-ia32.cc and ic-x64.cc.
These new CanvasArray types have different semantics than
CanvasPixelArray; out-of-range values are clamped via C cast
semantics, which is cheaper than the clamping behavior specified by
CanvasPixelArray. Out-of-range indices raise exceptions instead of
being silently ignored.
As part of this work, pulled FloatingPointHelper::AllocateHeapNumber
up to MacroAssembler on ia32 and x64 platforms. Slightly refactored
KeyedLoadIC and KeyedStoreIC. Fixed encoding for fistp_d on x64 and
added a few more instructions that are needed for the new ICs. The
test cases in test-api.cc have been verified by hand to exercise all
of the generated code paths in the forthcoming specialized ICs.
Review URL: http://codereview.chromium.org/293023
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3096 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
"jsregexp.h" and "jump-target.h" required "macro-assembler.h" to
always be included first. Instead the include of "macro-assembler.h"
has moved into those header files.
"dateparser-inl.h" required "dateparser.h" to always be included
first. Instead the include of "dateparser.h" has moved into
"dateparser-inl.h".
Review URL: http://codereview.chromium.org/267117
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3074 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When copying a map always set the descriptor array to describe the pre-allocated properties, even when descriptors are to be dropped.
Added a test which otherwise failed with an assert on ARM in debug mode. The reason for it only surfasing on ARM is that the NewObject runtime function is always used for allocating new JSObjects on ARM.
This change includes a few parts of http://codereview.chromium.org/174392 needed to trigger the error.
Review URL: http://codereview.chromium.org/173469
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2762 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
During parsing functions are analyzed for statements of the form this.x = ...;. These assignments are categorized in two types: simple and non simple. The simple ones are where the right hand side is known to be either a constant or an argument to the function. If a function only contains statements of this type the property names are collected and for the simple assignments the index of the argument or the constant value assigned are stored as well.
When the initial map for a function is created and the function consists of only this type of assignemnts the initial map is created with a descriptor array describing these properties which will be known to always exist in an object created from the function.
The information on this property assignments is not collected during pre-parsing so if compiling using pre-parse data these optimization hints are not available.
Next step will be to use the information collected for the simple assignments to generate constructor code which will create and initialize the object from this information without calling the code for the function.
Review URL: http://codereview.chromium.org/172088
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2710 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The abstractions have led to bugs because it looks like descriptor
streams are GC safe but they are not.
I have moved the descriptor stream helper functions to descriptor
arrays and I find most of the code just as readable now as it was
before.
Review URL: http://codereview.chromium.org/149458
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2428 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
