* src/contexts.h:
* src/bootstrapper.cc (InitializeExperimentalGlobal): Make generator
meta-objects, and store maps for constructing generator functions
and their prototypes.
* src/factory.h:
* src/factory.cc (MapForNewFunction): New helper.
(NewFunctionFromSharedFunctionInfo): Use the new helper.
* src/heap.cc (AllocateFunctionPrototype, AllocateInitialMap): For
generators, allocate appropriate prototypes and maps.
* src/code-stubs.h:
* src/arm/code-stubs-arm.h:
* src/arm/full-codegen-arm.h:
* src/ia32/code-stubs-ia32.h:
* src/ia32/full-codegen-ia32.h:
* src/x64/code-stubs-x64.h:
* src/x64/full-codegen-x64.h: Allow fast closure creation for generators,
using the appropriate map.
* test/mjsunit/harmony/builtins.js: Add a special case for
GeneratorFunctionPrototype.prototype.__proto__.
BUG=
TEST=mjsunit/harmony/generators-runtime
Review URL: https://codereview.chromium.org/13192004
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14236 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Since symbols and strings share a common representation, most of this change is about consistently replacing 'String' with 'Name' in all places where property names are expected. In particular, no new logic at all is necessary for maps, property dictionaries, or transitions. :) The only places where an actual case distinction is needed have to do with generated type checks, and with conversions of names to strings (especially in logger and profiler).
Left in some TODOs wrt to the API: interceptors and native getters don't accept symbols as property names yet, because that would require extending the external v8.h.
(Baseline CL: https://codereview.chromium.org/12296026/)
R=verwaest@chromium.org,mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12330012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13811 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The new instance type 'Symbol' represents ES6 symbols (a.k.a. private/unique names). Currently, symbols are simple data objects that only carry a hash code, random-generated upon allocation.
The new type 'Name' now serves as the common super class for strings and symbols, and is supposed to represent property names. We will eventually migrate APIs from String to Name for the standard key type.
Strings and symbols share the same hash field representation, via the Name class. This way, we should be able to use the same code paths for symbols and internalized strings in most cases. Also, Symbol's instance type code is allocated adjacent to internalized string codes in the enum, allowing a simple range check for the common case.
Baseline CL: https://codereview.chromium.org/12210083/R=mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/12223071
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13783 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in preparation of the introduction of ES6 'symbols' (aka private/unique names).
The SymbolTable became the StringTable. I also made sure to adapt all comments. The only remaining use of the term "symbol" (other than unrelated uses in the parser and such) is now 'NewSymbol' in the API and the 'V8.KeyedLoadGenericSymbol' counter, changing which might break embedders.
The one functional change in this CL is that I removed the former 'empty_string' constant, since it is redundant given the 'empty_symbol' constant that we also had (and both were used inconsistently).
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/12210083
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13781 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Unified parameter order of CreateHandle with the rest of v8 on the way. A few
Isolate::Current()s had to be introduced, which is not nice, and not every place
will win a beauty contest, but we can clean this up later easily in smaller steps.
Review URL: https://codereview.chromium.org/12300018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13717 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The basic idea is to tag OOM-Failure objects with an ID indicating where they were created. This requires changes to equality comparisons.
Note to MIPS folks: I'm planning to revert this CL in a couple of days, so feel free to skip porting the platform-specific changes.
BUG=chromium:156010
Review URL: https://codereview.chromium.org/11818023
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13341 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
