This CL introduces HPrologue instruction which does the context allocation work and supports deoptimization.
Review URL: https://codereview.chromium.org/1317383002
Cr-Commit-Position: refs/heads/master@{#30496}
This adds a new ToString runtime function and a fast-path ToStringStub
(which is just a simple dispatcher for existing functionality), and also
implements %_ToName using the ToStringStub.
R=mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1319973007
Cr-Commit-Position: refs/heads/master@{#30442}
This adds a %ToName runtime entry that uses the previously introduced
Object::ToName, which is based on the new Object::ToPrimitive method.
Also removes the need to expose ToName in various way via the builtins
and/or context.
Drive-by-fix: Let %HasProperty do the ToName conversion implicitly as
required.
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1319133002
Cr-Commit-Position: refs/heads/master@{#30435}
This is the first step towards a spec compliant ToPrimitive
implementation (and therefore spec compliant ToNumber, ToString,
ToName, and friends). It adds support for the @@toPrimitive
symbol that was introduced with ES2015, and also adds the new
Symbol.prototype[@@toPrimitive] and Date.prototype[@@toPrimitive]
initial properties.
There are now runtime functions for %ToPrimitive, %ToNumber and
%ToString, which do the right thing and should be used as fallbacks
instead of the hairy runtime.js implementations. I will do the
same for the other conversion operations mentioned by the spec in
follow up CLs. Once everything is in place we can look into
optimizing things further, so that we don't always call into the
runtime.
Also fixed Date.prototype.toJSON to be spec compliant.
R=mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4307
LOG=y
Review URL: https://codereview.chromium.org/1306303003
Cr-Commit-Position: refs/heads/master@{#30434}
Adds Uint32x4, Uint16x8, and Uint8x16 types.
Adds all functions in the current spec, except for loads and stores.
LOG=Y
BUG=v8:4124
Review URL: https://codereview.chromium.org/1294513004
Cr-Commit-Position: refs/heads/master@{#30322}
This CL is a nightmare! For the utterly irrelevant edge case of a sloppy function with non-simple parameters and a call to direct eval, like here,
let x = 1;
function f(g = () => x) {
var y
eval("var x = 2")
return g() + x // f() = 3
}
we have to do all of the following, on top of the declaration block ("varblock") contexts we already introduce around the body:
- Introduce the ability for varblock contexts to have both a ScopeInfo and an extension object (e.g., the body varblock in the example will contain both a static var y and a dynamic var x). No other scope needs that. Since there are no context slots left, a special new struct is introduced that pairs up scope info and extension object.
- When declaring lookup slots in the runtime, this new struct is allocated in the case where an extension object has to be added to a block scope (at which point the block's extension slot still contains a plain ScopeInfo).
- While at it, introduce some abstraction to access context extension slots in a more controlled manner, in order to keep special-casing to a minimum.
- Make sure that even empty varblock contexts do not get optimised away when they contain a sloppy eval, so that they can host the potential extension object.
- Extend dynamic search for declaration contexts (used by sloppy direct eval) to recognize varblock contexts.
- In the parser, if a function has a sloppy direct eval, introduce an additional varblock scope around each non-simple (desugared) parameter, as required by the spec to contain possible dynamic var bindings.
- In the pattern rewriter, add the ability to hoist the named variables the pattern declares to an outer scope. That is required because the actual destructuring has to be evaluated inside the protecting varblock scope, but the bindings that the desugaring introduces are in the outer scope.
- ScopeInfos need to save the information whether a block is a varblock, to make sloppy eval calls work correctly that deserialise them as part of the scope chain.
- Add the ability to materialize block scopes with extension objects in the debugger. Likewise, enable setting extension variables in block scopes via the debugger interface.
- While at it, refactor and unify some respective code in the debugger.
Sorry, this CL is large. I could try to split it up, but everything is rather entangled.
@mstarzinger: Please review the changes to contexts.
@yangguo: Please have a look at the debugger stuff.
R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:811,v8:2160
LOG=N
Review URL: https://codereview.chromium.org/1292753007
Cr-Commit-Position: refs/heads/master@{#30295}
We currently have several ways to share symbols that are used in
both native scripts and the runtime. This change unifies this.
We do not use the symbols registry since we don't need the
registry any longer after bootstrapping, but the registry stays
alive afterwards.
R=mlippautz@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1293493004
Cr-Commit-Position: refs/heads/master@{#30280}
Reason for revert:
This performance hack is no longer necessary.
Original issue's description:
> Group lexical context variables for faster look up.
>
> Currently, looking up a lexical context variable requires looking up
> the variable name and then checking its mode. This can be a bottleneck
> in Runtime_DeclareGlobals, even when no lexical context variables are
> declared.
>
> R=rossberg@chromium.org
> BUG=crbug:517778
> LOG=N
>
> Committed: https://crrev.com/a45ed17bb6aca02e940f13bbf456d660cccc86ae
> Cr-Commit-Position: refs/heads/master@{#30075}
TBR=rossberg@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=crbug:517778
Review URL: https://codereview.chromium.org/1290053002
Cr-Commit-Position: refs/heads/master@{#30145}
No need to provide TO_INT32/TO_UINT32 functions for every native
context, as they can be implemented in terms of TO_NUMBER more easily
and efficiently.
Also remove the obsolete TO_BOOLEAN_FUN_INDEX from the native contexts.
Review URL: https://codereview.chromium.org/1275013004
Cr-Commit-Position: refs/heads/master@{#30080}
Currently, looking up a lexical context variable requires looking up
the variable name and then checking its mode. This can be a bottleneck
in Runtime_DeclareGlobals, even when no lexical context variables are
declared.
R=rossberg@chromium.org
BUG=crbug:517778
LOG=N
Review URL: https://codereview.chromium.org/1281883002
Cr-Commit-Position: refs/heads/master@{#30075}
There is only one use case for it: String.prototype.search converts a
string argument into a RegExp. The cache is used to avoid repeating that
conversion. However, this does not make the added complexity worthwhile.
Review URL: https://codereview.chromium.org/1267493006
Cr-Commit-Position: refs/heads/master@{#29985}
This is the initial (big) step towards a more uniform implementation of
the ToObject abstract operation (ES6 7.1.13), where we have a fallback
implementation in JSReceiver::ToObject() and a fast (hydrogen) CodeStub
to deal with the fast case (we should be able to do more cleanup on this
in a followup CL). For natives we expose the abstract operation via a
%_ToObject intrinsic, also exposed via a macro TO_OBJECT, that unifies
the previous confusion with TO_OBJECT_INLINE, ToObject, TO_OBJECT,
$toObject and %$toObject. Now the whole implementation of the abstract
operation is context independent, meaning we don't need any magic in the
builtins object nor the native context.
R=mvstanton@chromium.org,yangguo@chromium.org
Review URL: https://codereview.chromium.org/1266013006
Cr-Commit-Position: refs/heads/master@{#29953}
This CL exposes the constructor function, defines type related
information, and implements value type semantics.
It also refactors test/mjsunit/samevalue.js to test SameValue and SameValueZero.
TEST=test/mjsunit/harmony/simd.js, test/cctest/test-simd.cc
LOG=Y
BUG=v8:4124
Committed: https://crrev.com/e5ed3bee99807c502fa7d7a367ec401e16d3f773
Cr-Commit-Position: refs/heads/master@{#29689}
Review URL: https://codereview.chromium.org/1219943002
Cr-Commit-Position: refs/heads/master@{#29712}
This CL exposes the constructor function, defines type related
information, and implements value type semantics.
It also refactors test/mjsunit/samevalue.js to test SameValue and SameValueZero.
TEST=test/mjsunit/harmony/simd.js, test/cctest/test-simd.cc
LOG=Y
BUG=v8:4124
Review URL: https://codereview.chromium.org/1219943002
Cr-Commit-Position: refs/heads/master@{#29689}
Until now, TF-generated code stubs piggy-backed off of the builtin
context. Since generation of code stubs is lazy, stubs generated at
different times in different native contexts would contain embedded
pointers different builtin contexts, leading to cross-context references
and memory leaks.
After this CL, all TF-generated code stubs are generated inside a
internal thinned-out, native context that lives solely for the
purpose of hosting generated code stubs.
Review URL: https://codereview.chromium.org/1213203007
Cr-Commit-Position: refs/heads/master@{#29593}
Map: get, set, has, delete, clear
Set: add, has, delete, clear
All except clear are implemented as calls into collection.js.
Note that some of these shadow methods of v8::Object. It's unclear
how confusing that's going to be: on the one hand, it seems likely
that most operations you would want to do on a Map or Set are these.
On the other, generic code could get confused if it somehow gets
ahold of a variable that happens to be C++-typed as a v8::Map or v8::Set.
BUG=v8:3340
LOG=y
Review URL: https://codereview.chromium.org/1204623002
Cr-Commit-Position: refs/heads/master@{#29237}
The Map and Set maps get overwritten when collection.js executes, so in
a nosnap build we have to wait until it runs before we grab the maps.
To facilitate that, store the functions in the native context as well.
Review URL: https://codereview.chromium.org/1161363002
Cr-Commit-Position: refs/heads/master@{#28743}
These are similar to the Map/Set constructors when called with an array,
except that they are guaranteed to be side-effect free if called with
a packed array.
This will be useful in implementing structured clone which, as
specified in HTML, speaks in terms of the internal [[MapData]]
and [[SetData]] slots without going through the exposed iteration
ES semantics.
BUG=v8:3340
LOG=y
Review URL: https://codereview.chromium.org/1155893003
Cr-Commit-Position: refs/heads/master@{#28642}
Only supports constructing new objects and returning size.
Followup patch will need to add ability to retrieve and
set contents in order to support structured clone.
Also removes a bunch of outdated "experimental" markers from v8.h.
BUG=v8:3340
LOG=y
Review URL: https://codereview.chromium.org/1157453002
Cr-Commit-Position: refs/heads/master@{#28637}
This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer
under the hood. It can be distinguished from an ArrayBuffer by the newly-added
is_shared() bit.
Currently there is no difference in functionality between a SharedArrayBuffer
and an ArrayBuffer. However, a future CL will add the Atomics API, which is
only available on an SharedArrayBuffer. All non-atomic accesses are identical
to ArrayBuffer accesses.
LOG=N
BUG=
Review URL: https://codereview.chromium.org/1136553006
Cr-Commit-Position: refs/heads/master@{#28594}
Reason for revert:
breaks build
Original issue's description:
> Implement SharedArrayBuffer.
>
> This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.
>
> Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.
>
> BUG=
>
> Committed: https://crrev.com/57170bff7baf341c666252a7f6a49e9c08d51263
> Cr-Commit-Position: refs/heads/master@{#28588}
TBR=jarin@chromium.org,jochen@chromium.org,binji@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1149203003
Cr-Commit-Position: refs/heads/master@{#28589}
This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.
Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.
BUG=
Review URL: https://codereview.chromium.org/1136553006
Cr-Commit-Position: refs/heads/master@{#28588}
Some of the DevTools' clients need to inspect JS objects without enabling debugger. This CL allows to inspect object's internal properties without enabling debugger and instantiating debug context.
Note that now debug context can be created lazily if v8::Debug::GetDebugContext is called when there is no debug listener. This is fragile and has already resulted in some subtle error. I'm going to fix that in a separate CL.
BUG=chromium:481845
LOG=Y
Review URL: https://codereview.chromium.org/1134193002
Cr-Commit-Position: refs/heads/master@{#28371}
Reason for revert:
GC mole issues: https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gcmole/builds/1950/steps/GCMole%20ia32/logs/stdio
Original issue's description:
> Provide accessor for object internal properties that doesn't require debugger to be active
>
> Some of the DevTools' clients need to inspect JS objects without enabling debugger. This CL allows to inspect object's internal properties without enabling debugger and instantiating debug context.
>
> Note that now debug context can be created lazily if v8::Debug::GetDebugContext is called when there is no debug listener. This is fragile and has already resulted in some subtle error. I'm going to fix that in a separate CL.
>
> BUG=chromium:481845
> LOG=Y
>
> Committed: https://crrev.com/bdeb0de88c8cf5f2c78f261b45314138f525110d
> Cr-Commit-Position: refs/heads/master@{#28362}
TBR=pfeldman@chromium.org,kozyatinskiy@chromium.org,yurys@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:481845
Review URL: https://codereview.chromium.org/1133243002
Cr-Commit-Position: refs/heads/master@{#28365}
Some of the DevTools' clients need to inspect JS objects without enabling debugger. This CL allows to inspect object's internal properties without enabling debugger and instantiating debug context.
Note that now debug context can be created lazily if v8::Debug::GetDebugContext is called when there is no debug listener. This is fragile and has already resulted in some subtle error. I'm going to fix that in a separate CL.
BUG=chromium:481845
LOG=Y
Review URL: https://codereview.chromium.org/1126103006
Cr-Commit-Position: refs/heads/master@{#28362}
Exposed to the extras as extrasExports (on the builtins object), on
which they can put things that should be accessible from C++. Exposed
to C++ through the V8 API as v8::Context::GetExtrasExportsObject().
Adding a test (in test-api.cc) required adding a simple extra,
test-extra.js, which we build into the standalone builds.
R=yangguo@chromium.org, jochen@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1128113006
Cr-Commit-Position: refs/heads/master@{#28317}
Just give internal ones an ArrayBuffer with a NULL backing store. This
simplifies the access checks a lot.
BUG=v8:3996
R=hpayer@chromium.org,verwaest@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1109353003
Cr-Commit-Position: refs/heads/master@{#28168}
This enables adding more language modes in the future.
For maximum flexibility, LanguageMode is a bitmask, so we're not restricted to
use a sequence of language modes which are progressively stricter, but we can
express the language mode as combination of features.
For now, LanguageMode can only be "sloppy" or "strict", and there are
STATIC_ASSERTS in places which need to change when more modes are added.
LanguageMode is a bit like the old LanguageMode when "extended" mode was still
around (see https://codereview.chromium.org/8417035 and
https://codereview.chromium.org/181543002 ) except that it's transmitted through
all the layers (there's no StrictModeFlag).
BUG=
Review URL: https://codereview.chromium.org/894683003
Cr-Commit-Position: refs/heads/master@{#26419}
This implements correct semantics for "extensible" top level lexical scope.
The entire lexical scope is represented at runtime by GlobalContextTable, reachable from native context and accumulating global contexts from every script loaded into the context.
When the new script starts executing, it does the following validation:
- checks the GlobalContextTable and global object (non-configurable own) properties against the set of declarations it introduces and reports potential conflicts.
- invalidates the conflicting PropertyCells on global object, so that any code depending on them will miss/deopt causing any contextual lookups to be reexecuted under the new bindings
- adds the lexical bindings it introduces to the GlobalContextTable
Loads and stores for contextual lookups are modified so that they check the GlobalContextTable before looking up properties on global object, thus implementing the shadowing of global object properties by lexical declarations.
R=adamk@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/705663004
Cr-Commit-Position: refs/heads/master@{#25220}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This avoids the appearence of a leak due to storing a JSObject
as the microtask_state in the strong root list, and allows callers
to call Isolate::RunMicrotasks() without having any v8::Context
available (as at least Blink has interest in doing).
The queue is now a strong root, represented as a FixedArray of JSFunctions
(or empty_fixed_array, if it's empty); it doubles in size when it needs to grow.
The number of elements in the queue is stored in Isolate::pending_microtask_count().
LOG=Y
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/290633010
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21356 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implements MapIterator and SetIterator which matches
the same constructs in the ES6 spec. However, these 2
iterators are not exposed to user code yet. They are only
used internally to implement Map.prototype.forEach and
Set.prototype.forEach.
Each iterator has a reference to the OrderedHashTable where
it directly accesses the hash table's entries.
The OrderedHashTable has a reference to the newest iterator
and each iterator has a reference to the next and previous
iterator, effectively creating a double linked list.
When the OrderedHashTable is mutated (or replaced) all the
iterators are updated.
When the iterator iterates passed the end of the data table
it closes itself. Closed iterators no longer have a
reference to the OrderedHashTable and they are removed from
the double linked list. In the case of Map/Set forEach, we
manually call Close on the iterator in case an exception was
thrown so that the iterator never reached the end.
At this point the OrderedHashTable keeps all the non finished
iterators alive but since the only thing we currently expose
is forEach there are no unfinished iterators outside a forEach
call. Once we expose the iterators to user code we will need
to make the references from the OrderedHashTable to the
iterators weak and have some mechanism to close an iterator
when it is garbage collected.
BUG=1793, 2323
LOG=Y
R=adamk@chromium.orgTBR=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/238063009
Patch from Erik Arvidsson <arv@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20857 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implements MapIterator and SetIterator which matches
the same constructs in the ES6 spec. However, these 2
iterators are not exposed to user code yet. They are only
used internally to implement Map.prototype.forEach and
Set.prototype.forEach.
Each iterator has a reference to the OrderedHashTable where
it directly accesses the hash table's entries.
The OrderedHashTable has a reference to the newest iterator
and each iterator has a reference to the next and previous
iterator, effectively creating a double linked list.
When the OrderedHashTable is mutated (or replaced) all the
iterators are updated.
When the iterator iterates passed the end of the data table
it closes itself. Closed iterators no longer have a
reference to the OrderedHashTable and they are removed from
the double linked list. In the case of Map/Set forEach, we
manually call Close on the iterator in case an exception was
thrown so that the iterator never reached the end.
At this point the OrderedHashTable keeps all the non finished
iterators alive but since the only thing we currently expose
is forEach there are no unfinished iterators outside a forEach
call. Once we expose the iterators to user code we will need
to make the references from the OrderedHashTable to the
iterators weak and have some mechanism to close an iterator
when it is garbage collected.
BUG=1793,2323
LOG=Y
TBR=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/240323003
Patch from Erik Arvidsson <arv@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20823 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implements MapIterator and SetIterator which matches
the same constructs in the ES6 spec. However, these 2
iterators are not exposed to user code yet. They are only
used internally to implement Map.prototype.forEach and
Set.prototype.forEach.
Each iterator has a reference to the OrderedHashTable where
it directly accesses the hash table's entries.
The OrderedHashTable has a reference to the newest iterator
and each iterator has a reference to the next and previous
iterator, effectively creating a double linked list.
When the OrderedHashTable is mutated (or replaced) all the
iterators are updated.
When the iterator iterates passed the end of the data table
it closes itself. Closed iterators no longer have a
reference to the OrderedHashTable and they are removed from
the double linked list. In the case of Map/Set forEach, we
manually call Close on the iterator in case an exception was
thrown so that the iterator never reached the end.
At this point the OrderedHashTable keeps all the non finished
iterators alive but since the only thing we currently expose
is forEach there are no unfinished iterators outside a forEach
call. Once we expose the iterators to user code we will need
to make the references from the OrderedHashTable to the
iterators weak and have some mechanism to close an iterator
when it is garbage collected.
BUG=1793,2323
LOG=Y
R=adamk@chromium.org, mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/236143002
Patch from Erik Arvidsson <arv@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20781 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch generalizes Object.observe callbacks and promise resolution into a FIFO queue called a "microtask queue".
It also exposes new V8 API which exposes the microtask queue to the embedder. In particular, it allows the embedder to
-schedule a microtask (EnqueueExternalMicrotask)
-run the microtask queue (RunMicrotasks)
-control whether the microtask queue is run automatically within V8 when the last script exits (SetAutorunMicrotasks).
R=dcarney@chromium.org, rossberg@chromium.org, dcarney, rossberg, svenpanne
BUG=
Review URL: https://codereview.chromium.org/154283002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19344 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Based on prototype at
https://github.com/rossberg-chromium/js-promise
which informed the latest spec draft version at
https://github.com/domenic/promises-unwrapping/blob/master/README.md
Activated by --harmony-promises.
Feature complete with respect to the draft spec, plus the addition of .when and .deferred methods. Final naming and other possible deviations from the current draft will hopefully be resolved soon after the next TC39 meeting.
This CL also generalises the Object.observe delivery loop into a simplistic microtask loop. Currently, all observer events are delivered before invoking any promise handler in a single fixpoint iteration. It's not clear yet what the final semantics is supposed to be (should there be a global event ordering?), but it will probably require a more thorough event loop abstraction inside V8 once we get there.
R=dslomov@chromium.org, yhirano@chromium.org
BUG=
Review URL: https://codereview.chromium.org/64223010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18113 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This removes tons of architecture-specific code and makes it easy to
experiment with other pseudo-RNG algorithms. The crankshafted code is
extremely good, keeping all things unboxed and doing only minimal
checks, so it is basically equivalent to the handwritten code.
When benchmarks are run without parallel recompilation, we get a few
percent regression on SunSpider's string-validate-input and
string-base64, but these benchmarks run so fast that the overall
SunSpider score is hardly affected and within the usual jitter. Note
that these benchmarks actually run even faster when we don't
crankshaft at all on the main thread (the regression is not caused by
bad code, it is caused by Crankshaft needing a few hundred microsecond
for compilation of a trivial function). Luckily, when parallel
recompilation is enabled, i.e. in the browser, we see no regression at
all!
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/68723002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17955 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
ES3 specified that functions created via Function() would have
enumerable prototypes, unlike function literals. For this reason, V8
has always had two prototypes for functions: "function_map" for
literals, and "function_instance_map" for "function instances": those
functions created by Function().
However, since 2009 or so, both maps have been the same! Both have had
writable, non-enumerable prototypes. Moreover, ES5 changed to specify
that function instances would have non-enumerable prototypes.
This patch removes the separate maps for function instances in sloppy
and strict mode.
R=mstarzinger@chromium.org
TEST=mjsunit/function-prototype
BUG=
Review URL: https://codereview.chromium.org/14829005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14619 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* 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
(qua last week's TC39)
Specifically:
- Install Symbol constructor function on the global object.
- Adjust code generation for typeof.
- Remove IsSymbol built-in, IS_SYMBOL macro now defined using typeof.
- Remove hack that allowed symbols as constructor results, and some other special cases.
- Remove symbol_delegate and GetDelegate function.
- Extend ToBoolean stub to handle symbols.
- Extend ToNumber to return NaN on symbols.
- Poison symbol's toString function, and thereby ToString on symbols.
R=mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12957004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14051 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Add --harmony-symbols flag.
- Add Symbol constructor; allow symbols as (unreplaced) return value from constructors.
- Introduce %CreateSymbol and %_IsSymbol natives and respective instructions.
- Extend 'typeof' code generation to handle symbols.
- Extend CompareIC with a UNIQUE_NAMES state that (uniformly) handles internalized strings and symbols.
- Property lookup delegates to SymbolDelegate object for symbols, which only carries the toString method.
- Extend Object.prototype.toString to recognise symbols.
Per the current draft spec, symbols are actually pseudo objects that are frozen with a null prototype and only one property (toString). For simplicity, we do not treat them as proper objects for now, although typeof will return "object". Only property access works as if they were (frozen) objects (via the internal delegate object).
(Baseline CL: https://codereview.chromium.org/12223071/)
R=mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12296026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13786 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 CL has two parts: the first is the logic itself, whereby each observer callback is assigned
a "priority" number the first time it's passed as an observer to Object.observe(), and that
priority is used to determine the order of delivery.
The second part invokes the above logic as part of the API, when the JS stack winds down to
zero.
Added several tests via the API, as the delivery logic isn't testable from a JS test
(it runs after such a test would exit).
Review URL: https://codereview.chromium.org/11266011
Patch from Adam Klein <adamk@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12902 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In more detail:
- Set observation bit for observed objects (and make NormalizedMapCache respect it).
- Mutation of observed objects is always delegated from ICs to runtime.
- Introduce JS runtime function for notifying generated changes.
- Invoke this function in the appropriate places (including some local refactoring).
- Inclusion of oldValue field is not yet implemented, nor element properties.
Also, shortened flag to --harmony-observation.
R=verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/11347037
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12867 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
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
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
I also discovered that our treatment of const declarations is inconsistent
when inside a global eval under 'with' (i.e., when created by
DeclareContextSlots). That is,
var x;
eval("const x = 9")
and
var x;
eval("with({}) const x = 9")
differ (the former assigns 9, the latter throws). This appears to be an
oversight from earlier changes to our const semantics (the latter shouldn't
throw either). Fixing this is a separate issue, though (and one that doesn't
seem quite worthwhile).
R=mstarzinger@chromium.org
BUG=v8:1991,80591
TEST=
Review URL: https://chromiumcodereview.appspot.com/10067010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11333 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
So far free variables references in eval code are not statically
resolved. For example in
function foo() { var x = 1; eval("y = x"); }
the variable x will get mode DYNAMIC and y will get mode DYNAMIC_GLOBAL,
i.e. free variable references trigger dynamic lookups with a fast case
handling for global variables.
The CL introduces static resolution of free variables references in eval
code. If possible variable references are resolved to bindings belonging to
outer scopes of the eval call site.
This is achieved by deserializing the outer scope chain using
Scope::DeserializeScopeChain prior to parsing the eval code similar to lazy
parsing of functions. The existing code for variable resolution is used,
however resolution starts at the first outer unresolved scope instead of
always starting at the root of the scope tree.
This is a prerequisite for statically checking validity of assignments in
the extended code as specified by the current ES.next draft which will be
introduced by a subsequent CL. More specifically section 11.13 of revision 4
of the ES.next draft reads:
* It is a Syntax Error if the AssignmentExpression is contained in extended
code and the LeftHandSideExpression is an Identifier that does not
statically resolve to a declarative environment record binding or if the
resolved binding is an immutable binding.
TEST=existing tests in mjsunit
Review URL: http://codereview.chromium.org/8508052
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9999 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implements block scoped 'const' declared variables in harmony mode. They
have a temporal dead zone semantics similar to 'let' bindings, i.e. accessing
uninitialized 'const' bindings in throws a ReferenceError.
As for 'let' bindings, the semantics of 'const' bindings in global scope is not
correctly implemented yet. Furthermore assignments to 'const's are silently
ignored. Another CL will introduce treatment of those assignments as early
errors.
Review URL: http://codereview.chromium.org/7992005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9764 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
