This patch adds the following three metrics for the --trace_gc_nvp option.
nodes_died_in_new_space_; // Number of died nodes in the new space.
nodes_copied_in_new_space_; // Number of copied nodes to the new space.
nodes_promoted; // Number of promoted nodes to the old space.
BUG=
TEST=Manually confirmed that the "--trace_gc --trace_gc_nvp" option prints the metrics
Review URL: https://codereview.chromium.org/11365146
Patch from Kentaro Hara <haraken@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13159 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Making the code size predictable is hard, and to make things even more
complicated, the start of a function can contain various stuff like calls to a
profiling hook, receiver adjustment or dynamic frame alignment. Instead of
tackling all these problems separately, we now simply record the offset where
patching should happen later in the Code object itself.
Review URL: https://codereview.chromium.org/11316218
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13081 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Modules now have their own local scope, represented by their own context.
Module instance objects have an accessor for every export that forwards
access to the respective slot from the module's context. (Exports that are
modules themselves, however, are simple data properties.)
All modules have a _hosting_ scope/context, which (currently) is the
(innermost) enclosing global scope. To deal with recursion, nested modules
are hosted by the same scope as global ones.
For every (global or nested) module literal, the hosting context has an
internal slot that points directly to the respective module context. This
enables quick access to (statically resolved) module members by 2-dimensional
access through the hosting context. For example,
module A {
let x;
module B { let y; }
}
module C { let z; }
allocates contexts as follows:
[header| .A | .B | .C | A | C ] (global)
| | |
| | +-- [header| z ] (module)
| |
| +------- [header| y ] (module)
|
+------------ [header| x | B ] (module)
Here, .A, .B, .C are the internal slots pointing to the hosted module
contexts, whereas A, B, C hold the actual instance objects (note that every
module context also points to the respective instance object through its
extension slot in the header).
To deal with arbitrary recursion and aliases between modules,
they are created and initialized in several stages. Each stage applies to
all modules in the hosting global scope, including nested ones.
1. Allocate: for each module _literal_, allocate the module contexts and
respective instance object and wire them up. This happens in the
PushModuleContext runtime function, as generated by AllocateModules
(invoked by VisitDeclarations in the hosting scope).
2. Bind: for each module _declaration_ (i.e. literals as well as aliases),
assign the respective instance object to respective local variables. This
happens in VisitModuleDeclaration, and uses the instance objects created
in the previous stage.
For each module _literal_, this phase also constructs a module descriptor
for the next stage. This happens in VisitModuleLiteral.
3. Populate: invoke the DeclareModules runtime function to populate each
_instance_ object with accessors for it exports. This is generated by
DeclareModules (invoked by VisitDeclarations in the hosting scope again),
and uses the descriptors generated in the previous stage.
4. Initialize: execute the module bodies (and other code) in sequence. This
happens by the separate statements generated for module bodies. To reenter
the module scopes properly, the parser inserted ModuleStatements.
R=mstarzinger@chromium.org,svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/11093074
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13033 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This requires adding a new JSObject to the strong root list and populating it from
object-observe.js. The main other change is that we now directly use ObjectHashTable
from JS rather than using WeakMap, since using the latter would end up leaking whichever
Context initialized that observation state.
Added a test via the API showing that different contexts all end up working on the same state.
Review URL: https://codereview.chromium.org/11274014
Patch from Adam Klein <adamk@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12873 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added highly efficient Object::SetAlignedPointerInInternalField and
Object::GetAlignedPointerFromInternalField functions for 2-byte-aligned
pointers. Their non-aligned counterparts Object::GetPointerFromInternalField and
Object::SetPointerInInternalField are now deprecated utility functions.
External is now a true Value again, with New/Value/Cast using a JSObject with an
internal field containing a Foreign. External::Wrap, and External::Unwrap are now
deprecated utility functions.
Added Context::GetEmbedderData and Context::SetEmbedderData. Deprecated
Context::GetData and Context::SetData, these are now only wrappers to access
internal field 0.
Added highly efficient Context::SetAlignedPointerInEmbedderData and
Context::GetAlignedPointerFromEmbedderData functions for 2-byte-aligned
pointers.
Review URL: https://codereview.chromium.org/11190050
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12849 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This enables code flushing even with incremental marking enabled and
fully shares the function link field in JSFunctions between candidates
for code flushing and the optimized functions list. If a candidate for
code flushing gets optimized, it will be evicted from the candidates
list.
R=ulan@chromium.org
BUG=v8:1609
Review URL: https://codereview.chromium.org/11140025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12796 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The patch introduces CommittedPhysicalMemory function to
the Heap class that reports committed *physical* memory acquired
for the heap from the OS.
It is important because some OSes may defer actual committment on e.g.
first access to the region.
So reporting just plain committed size led to various weird artifacts
like showing V8 allocated memory higher than the whole process
private size.
BUG=v8:2191
Review URL: https://codereview.chromium.org/11066118
Patch from Alexei Filippov <alph@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12793 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The patch introduces CommittedPhysicalMemory function to the Heap class
that reports committed *physical* memory acquired from the OS.
It is important because some OSes may postpone actual commitment on e.g.
first access to the previously committed region.
So reporting just plain committed size led to various weird artifacts
like DevTools showing V8 allocated memory higher than the whole process
private size.
BUG=v8:2191
Review URL: https://codereview.chromium.org/10961042
Patch from Alexei Filippov <alph@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
the speed of deserializing code. The current startup
time improvement for V8 is around 6%, but code deserialization
is speeded up disproportionately, and we will soon have more
code in the snapshot.
* Removed support for deserializing into large object space.
The regular pages are 1Mbyte now and that is plenty. This
is a big simplification.
* Instead of reserving space for the snapshot we actually
allocate it now. This removes some special casing from
the memory management and simplifies deserialization since
we are just bumping a pointer rather than calling the
normal allocation routines during deserialization.
* Record in the snapshot how much we need to boot up and
allocate it instead of just assuming that allocations in
a new VM will always be linear.
* In the snapshot we always address an object as a negative
offset from the current allocation point. We used to
sometimes address from the start of the deserialized data,
but this is less useful now that we have good support for
roots and repetitions in the deserialization data.
* Code objects were previously deserialized (like other
objects) by alternating raw data (deserialized with memcpy)
and pointers (to external references, other objects, etc.).
Now we deserialize code objects with a single memcpy,
followed by a series of skips and pointers that partially
overwrite the code we memcopied out of the snapshot.
The skips are sometimes merged into the following
instruction in the deserialization data to reduce dispatch
time.
* Integers in the snapshot were stored in a variable length
format that gives a compact representation for small positive
integers. This is still the case, but the new encoding can
be decoded without branches or conditional instructions,
which is faster on a modern CPU.
Review URL: https://chromiumcodereview.appspot.com/10918067
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12505 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL adds multiple things:
Transition arrays do not directly point at their descriptor array anymore, but rather do so via an indirect pointer (a JSGlobalPropertyCell).
An ownership bit is added to maps indicating whether it owns its own descriptor array or not.
Maps owning a descriptor array can pass on ownership if a transition from that map is generated; but only if the descriptor array stays exactly the same; or if a descriptor is added.
Maps that don't have ownership get ownership back if their direct child to which ownership was passed is cleared in ClearNonLiveTransitions.
To detect which descriptors in an array are valid, each map knows its own NumberOfOwnDescriptors. Since the descriptors are sorted in order of addition, if we search and find a descriptor with index bigger than this number, it is not valid for the given map.
We currently still build up an enumeration cache (although this may disappear). The enumeration cache is always built for the entire descriptor array, even if not all descriptors are owned by the map. Once a descriptor array has an enumeration cache for a given map; this invariant will always be true, even if the descriptor array was extended. The extended array will inherit the enumeration cache from the smaller descriptor array. If a map with more descriptors needs an enumeration cache, it's EnumLength will still be set to invalid, so it will have to recompute the enumeration cache. This new cache will also be valid for smaller maps since they have their own enumlength; and use this to loop over the cache. If the EnumLength is still invalid, but there is already a cache present that is big enough; we just initialize the EnumLength field for the map.
When we apply ClearNonLiveTransitions and descriptor ownership is passed back to a parent map, the descriptor array is trimmed in-place and resorted. At the same time, the enumeration cache is trimmed in-place.
Only transition arrays contain descriptor arrays. If we transition to a map and pass ownership of the descriptor array along, the child map will not store the descriptor array it owns. Rather its parent will keep the pointer. So for every leaf-map, we find the descriptor array by following the back pointer, reading out the transition array, and fetching the descriptor array from the JSGlobalPropertyCell. If a map has a transition array, we fetch it from there. If a map has undefined as its back-pointer and has no transition array; it is considered to have an empty descriptor array.
When we modify properties, we cannot share the descriptor array. To accommodate this, the child map will get its own transition array; even if there are not necessarily any transitions leaving from the child map. This is necessary since it's the only way to store its own descriptor array.
Review URL: https://chromiumcodereview.appspot.com/10909007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12492 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- The global object has a reference to the current global scope chain.
Running a script adds to the chain if it contains global lexical declarations.
- Scripts are executed relative to a global, not a native context.
- Harmony let and const bindings are allocated to the innermost global context;
var and function still live on the global object.
(Lexical bindings are not reflected on the global object at all,
but that will probably change later using accessors, as for modules.)
- Compilation of scripts now needs a (global) context (previously only eval did).
- The global scope chain represents one logical scope, so collision tests take
the chain into account.
R=svenpanne@chromium.org
BUG=
Review URL: https://chromiumcodereview.appspot.com/10872084
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12398 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The order by name is maintained as secondary order by using unused bits in the property details.
This is preliminary work towards sharing descriptors arrays.
The change allows us
- to get rid of the LastAdded bits in the map, binding it to the number of valid descriptors for the given map
- to avoid resorting by enumeration index to create the cache
- (maybe in the future, depending on performance) to get rid of the enumeration cache altogether.
Although generally the number_of_descriptors equals the NumberOfOwnDescriptors in the current version, this is preliminary work towards sharing descriptors, where maps may have more descriptors than are valid for the map.
Review URL: https://chromiumcodereview.appspot.com/10879013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12385 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
Now a map points to a transition array which contains the descriptor array. The descriptor array is now immutable. The next step is to share the descriptor array with all back-pointed maps as long as there is a single line of extension. Maps that require a descriptor array but don't need transitions will still need a pseudo-empty transition array to contain the descriptor array.
Review URL: https://chromiumcodereview.appspot.com/10816005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12298 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The deoptimizer generates full-code-generator code and relies on it having
the same layout as last time. This means that the code the full code
generator makes for the snapshot should be the same as the code it makes
later. This change makes the full code generator create more consistent
code between mksnapshot time and run time.
This is a bug fix and a step towards making the snapshot code more robust.
Review URL: https://chromiumcodereview.appspot.com/10824084
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12233 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Using insertion-sort won't have too much of an overhead for the short arrays for bootstrapping (which are probably snapshot anyway).
CopyAppendCallbackDescriptors was extending and sorting the array in a loop. By using an append that inserts at the right position we do not need to resort in each iteration.
Additionally remove Sort and rename SortUnchecked to Sort. The IsSortedNoDuplicates check is moved into InitializeDescriptor.
Review URL: https://chromiumcodereview.appspot.com/10808011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12136 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
AccessorPair related transitions are now also stored as single map links, simplifying the code that handles transitions. AccessorPairs can now be shared between descriptor arrays, since they can only be mutated after another transition anyway; during which the pair is copied before writing.
Review URL: https://chromiumcodereview.appspot.com/10784014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12097 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The LastAdded points to the descriptor that was last added to the array. From the descriptor we can deduce the NextEnumerationIndex. This allows us to quickly find the property that we are transitioning to, which is necessary for transition-intensive code, eg JSON parsing.
Review URL: https://chromiumcodereview.appspot.com/10695120
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12042 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Specifically:
- In parser, check that all exports are defined.
- Move JSModule allocation from parser to scope resolution.
- Move JSModule linking from full codegen to scope resolution.
- Implement module accessors for exported value members.
- Allocate module contexts statically along with JSModules
(to allow static linking), but chain them when module literal is evaluated.
- Make module contexts' extension slot refer to resp. JSModule
(makes modules' ScopeInfo accessible from context).
- Some other tweaks to context handling in general.
- Make any code containing module literals (and thus embedding
static references to JSModules) non-cacheable.
This enables accessing module instance objects as expected.
Import declarations are a separate feature and do not work yet.
R=mstarzinger@chromium.org
BUG=v8:1569
TEST=
Review URL: https://chromiumcodereview.appspot.com/10690043
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
with more JS code that is loaded into the VM before writing the snapshot. Get
rid of the hard coded limit on the partial snapshot cache size. This change
disables most of the serializer tests for the snapshot build of the VM: It's
getting too complicated to support both booting from a snapshot and then
creating a new snapshot from the same VM or loading more code with another
snapshot in the same VM.
Review URL: http://codereview.chromium.org/10574013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11871 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This makes back pointers in the map transition tree explicit by having
accurate back pointers throughout the lifetime of maps instead of
establishing and destroying back pointers before and after each marking
phase. This is a prerequisite for being able to clear map transitions
during incremental marking.
R=vegorov@chromium.org
BUG=v8:1465
Review URL: https://chromiumcodereview.appspot.com/10381053
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11528 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Constructs the (generally cyclic) graph of module instance objects
and populates their exports. Any exports other than nested modules
are currently set to 'undefined' (but already present as properties).
Details:
- Added new type JSModule for instance objects: a JSObject carrying a context.
- Statically allocate instance objects for all module literals (in parser 8-}).
- Extend interfaces to record and unify concrete instance objects,
and to support iteration over members.
- Introduce new runtime function for pushing module contexts.
- Generate code for allocating, initializing, and setting module contexts,
and for populating instance objects from module literals.
Currently, all non-module exports are still initialized with 'undefined'.
- Module aliases are resolved statically, so no special code is required.
- Make sure that code containing module constructs is never optimized
(macrofy AST node construction flag setting while we're at it).
- Add test case checking linkage.
Baseline: http://codereview.chromium.org/9722043/R=svenpanne@chromium.org,mstarzinger@chromium.org
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9844002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11336 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Marking aligned frames with a marker can produce false positives since
an optimized frame spill slot may be mistakenly seen as a marker value.
It also breaks the debugger reproducably: Tested when enabling alignment
for all functions and running the debugger unit tests.
BUG=v8:2009
TEST=no crashes in EarleyBoyer
Review URL: https://chromiumcodereview.appspot.com/9703110
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11075 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change includes two CLs by pliard@chromium.org:
1. http://codereview.chromium.org/9447052/ (Add CallOnce() and simple LazyInstance implementation):
Note that this implementation of LazyInstance does not handle global destructors (i.e. the lazy instances are never deleted).
This CL was initially reviewed on codereview.appspot.com:
http://codereview.appspot.com/5687064/
2. http://codereview.chromium.org/9455088/ (Remove static initializers in v8):
This CL depends on CL 9447052 (adding CallOnce and LazyInstance).
It is based on a patch sent by Digit.
With this patch applied, we have only one static initializer left (in atomicops_internals_x86_gcc.cc). This static initializer populates a structure used by x86 atomic operations. It seems that we can hardly remove it. If possible, it will be removed in a next CL.
This CL also modifies the presubmit script to check the number of static initializers.
BUG=v8:1859
Review URL: https://chromiumcodereview.appspot.com/9666052
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is essential for the upcoming map sharing with accessors, and we aleady
have enough machinery to handle the holes now. Furthermore, use "To" template in
2 nearby functions, and made naming a bit more consistent.
In a nutshell: This CL should have no visible effect at all at the moment.
Famous last words...
Review URL: https://chromiumcodereview.appspot.com/9594013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10919 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This allows elements of the non-strict arguments object to be redefined
with custom attributes and still maintain an alias into the context.
Such a slow alias is maintained by placing a special marker into the
dictionary backing store of the arguments object.
R=rossberg@chromium.org
BUG=v8:1772
TEST=test262,mjsunit/object-define-property
Review URL: https://chromiumcodereview.appspot.com/9460004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10827 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL is an intermediate step only, in the end we need to have a single
DefineOrRedefineAccessorProperty call for a single Object.defineProperty
call. Currently we can end up making two such calls, making the necessary access
checks extremely ugly and hard (impossible?) to get right for complete spec
conformance.
The bulk of the change is quite mechanical:
* Prepare an AccessorPair *before* we add it to our data structures,
eliminating the previous voodoo-like threading of a placeholder.
* The previous item makes it possible to activate our check that we do not
share AccessorPairs by accident.
* Split a monster method into 2 quite unrelated methods.
* Use templated To method in a few places.
Review URL: https://chromiumcodereview.appspot.com/9428026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10788 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To test the upcoming changes for map sharing in the presence of accessors, it is
essential that we keep a few global invariants: The map tree should always stay
a tree and AccessorPairs should not be shared between different DescriptorArrays
and/or StringDictionaries. This CL adds a test method for the latter invariant
and makes some changes to the bootstrapping process to avoid such sharing.
Note that we can't enable the new test method permanently yet, because we
currently go back and forth between fast mode and slow mode when adding an
accessor and break this invariant temporarily. This will be handled in a
separate CL.
Review URL: https://chromiumcodereview.appspot.com/9417043
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10744 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
