Implements the strong mode proposal's restrictions on property access.
To be fully explored in a followup: proxies, interceptors, access checks, load from super
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1168093002
Cr-Commit-Position: refs/heads/master@{#29109}
This invariant will save us some head ache.
The changes to test-debug/DebugStub is due to the fact that it abuses
the ability to set break points in code that has no debug break slots.
This is now no longer possible.
R=ulan@chromium.org
BUG=v8:4132
LOG=N
Review URL: https://codereview.chromium.org/1181013007
Cr-Commit-Position: refs/heads/master@{#29038}
The alternative of passing an object template at context creation is
unfeasible because we need a context to instantiate the template.
At the time we create the context from snapshot or bootstrap from
scratch, we would already need that template instance, leading to a
chicken-and-egg problem.
This is an alternative that is simpler and less intrusive.
R=domenic@chromium.org, jochen@chromium.org
Review URL: https://codereview.chromium.org/1182443002
Cr-Commit-Position: refs/heads/master@{#28938}
This will significantly simplify the serialization code, as well
as speeding it up (by triggering only a single allocation instead of O(size)
allocations).
BUG=chromium:478263
LOG=y
Review URL: https://codereview.chromium.org/1157843006
Cr-Commit-Position: refs/heads/master@{#28793}
This also fixes issues with
- kMaxUint32 being a valid length but not index cornercases
- exotic integer objects masking "exotic indexes" even though its in the prototype chain
- concating of holey sloppy arguments
BUG=v8:4137
LOG=n
Review URL: https://codereview.chromium.org/1159433003
Cr-Commit-Position: refs/heads/master@{#28754}
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}
Implements the strong mode proposal's restrictions on the behaviour of the
delete operator for strong objects.
Setting the strong bit is still wip, so this change will only affect those
objects that have the bit correctly set. The tests reflect this, and will be
expanded as more objects can be marked as strong.
Attempt 2, last version did not work with API.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1156573002
Cr-Commit-Position: refs/heads/master@{#28724}
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}
These return arrays representing the current contents of the given
Map/Set. They are similar to what would be returned by the JS code:
Array.from(collection)
except that they are guaranteed side-effect free.
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/1148383007
Cr-Commit-Position: refs/heads/master@{#28640}
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}
* Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols.
* In the long run we should do all hidden properties this way and get rid of the
hidden magic 0-length string with the zero hash code. The advantages include
less complexity and being able to do things from JS in a natural way.
* Initially, the performance of weak set regressed, because it's a little harder
to do the lookup in C++. Instead of heroics in C++ to make things faster I
moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects.
* This also changes hash codes of Smis so that they are always Smis.
Performance figures are in the comments to the code review. Summary: Most of js-perf-test/Collections is neutral. Set and Map with object keys are 40-50% better. WeakMap is -5% and WeakSet is +9%. After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(.
In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this. Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately). With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win.
In a similar vein we could give the magic zero hash code to the hash code
symbol. Then when we look up the hash code we would sometimes see the table
with all the hidden properties. This dual use of the field for either the hash
code or the table with all hidden properties and the hash code is rather ugly,
and this CL gets rid of it. I'd be loath to bring it back. On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL.
One worry is that the benchmark results above are more monomorphic than real
world code, so may be overstating the performance benefits of moving to JS. I
think this is part of a general issue we have with handling polymorphic code in
JS and any solutions there will benefit this solution, which boils down to
regular property access. Any improvement there will lift all boats.
R=adamk@chromium.org, verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1149863005
Cr-Commit-Position: refs/heads/master@{#28622}
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}
Deleting an in-bounds character index from a String object should always return
false.
BUG=
LOG=N
Review URL: https://codereview.chromium.org/1153673003
Cr-Commit-Position: refs/heads/master@{#28592}
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}
When the page is controlled by a ServiceWorker, the ServiceWorker can return an opaque (non-CORS cross origin) resource response.
We need to treat the messages from such script resource as opaque.
Committed: https://crrev.com/7a599c5e1242d3c5ab7515ee149623da90ae69ec
Cr-Commit-Position: refs/heads/master@{#28445}
Review URL: https://codereview.chromium.org/1140673002
Cr-Commit-Position: refs/heads/master@{#28459}
When the page is controlled by a ServiceWorker, the ServiceWorker can return an opaque (non-CORS cross origin) resource response.
We need to treat the messages from such script resource as opaque.
Review URL: https://codereview.chromium.org/1140673002
Cr-Commit-Position: refs/heads/master@{#28445}
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}
I know the bug has been closed but this seems like a simple addition that may
be useful in other ways as well.
BUG=v8:2180
LOG=N
Review URL: https://codereview.chromium.org/1128553002
Cr-Commit-Position: refs/heads/master@{#28261}
Tick event processor should not stay in a tight loop
when there's nothing to do. It can go sleep until next sample event.
LOG=N
BUG=v8:3967
Review URL: https://codereview.chromium.org/1118533003
Cr-Commit-Position: refs/heads/master@{#28211}
Reason for revert:
[Sheriff] Speculative revert. This seems to block the current roll:
https://codereview.chromium.org/1124463003/
This bisect also points at this CL:
https://codereview.chromium.org/1124523002/
Please prepare the chromium side tests before a reland.
Original issue's description:
> [V8] Use previous token location as EOS token location
>
> EOS token location is useless for users and messages.js are not ready for its location.
> With this CL we use location of token before EOS for it.
>
> LOG=Y
> BUG=chromium:480652
> R=yurys@chromium.org,yangguo@chromium.org
>
> Committed: https://crrev.com/81afc9313ce84350bcba9f84b255a77e97cd3726
> Cr-Commit-Position: refs/heads/master@{#28164}
TBR=yangguo@chromium.org,yurys@chromium.org,kozyatinskiy@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:480652
Review URL: https://codereview.chromium.org/1116233004
Cr-Commit-Position: refs/heads/master@{#28187}
EOS token location is useless for users and messages.js are not ready for its location.
With this CL we use location of token before EOS for it.
LOG=Y
BUG=chromium:480652
R=yurys@chromium.org,yangguo@chromium.org
Review URL: https://codereview.chromium.org/1100993003
Cr-Commit-Position: refs/heads/master@{#28164}
We shouldn't have shared state between isolates by default. The embedder
is free to pass the same allocator to all isolates it creates.
BUG=none
R=dcarney@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1116633002
Cr-Commit-Position: refs/heads/master@{#28127}
Reason for revert:
I'm reverting this while working on the regression fix
Original issue's description:
> Remove the weak list of views from array buffers
>
> Instead, views have to check their array buffer for whether
> it's neutered or not.
>
> BUG=v8:3996
> R=hpayer@chromium.org,dslomov@chromium.org,verwaest@chromium.org
> LOG=n
>
> Committed: https://crrev.com/5ae083a05a6743d6cb91585f449539f7846a5d8c
> Cr-Commit-Position: refs/heads/master@{#27995}
TBR=dslomov@chromium.org,hpayer@chromium.org,verwaest@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3996
Review URL: https://codereview.chromium.org/1061753008
Cr-Commit-Position: refs/heads/master@{#28014}
Reason for revert:
This was probably an infrastructure problem caused by the mac ninja/goma switch.
Original issue's description:
> Revert of Protect the emptiness of Array prototype elements with a PropertyCell. (patchset #7 id:120001 of https://codereview.chromium.org/1092043002/)
>
> Reason for revert:
> MAC GCSTRESS failure on new test.
>
> Original issue's description:
> > Protect the emptiness of Array prototype elements with a PropertyCell.
> >
> > Not just emptiness, but also a particular structure.
> >
> > BUG=v8:4044
> > LOG=N
>
> TBR=jkummerow@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4044
TBR=jkummerow@chromium.org,mvstanton@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4044
Review URL: https://codereview.chromium.org/1052253003
Cr-Commit-Position: refs/heads/master@{#28000}
Reason for revert:
MAC GCSTRESS failure on new test.
Original issue's description:
> Protect the emptiness of Array prototype elements with a PropertyCell.
>
> Not just emptiness, but also a particular structure.
>
> BUG=v8:4044
> LOG=N
TBR=jkummerow@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4044
Review URL: https://codereview.chromium.org/1099203004
Cr-Commit-Position: refs/heads/master@{#27998}
Instead, views have to check their array buffer for whether
it's neutered or not.
BUG=v8:3996
R=hpayer@chromium.org,dslomov@chromium.org,verwaest@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1094863002
Cr-Commit-Position: refs/heads/master@{#27995}
Not just emptiness, but also a particular structure.
BUG=v8:4044
LOG=N
Review URL: https://codereview.chromium.org/1092043002
Cr-Commit-Position: refs/heads/master@{#27993}
Add a finalize incremental marking mode for CollectAllGarbage to finalize incremental marking when incremental marking is in progress, but we want a full gc at a given CollectAllGarbage call site.
Default mode for CollectAllGarbage is finalize incremental marking and perform a full GC.
BUG=
Review URL: https://codereview.chromium.org/1082973003
Cr-Commit-Position: refs/heads/master@{#27831}
This avoids both a mysterious boolean argument ("insert") and lets
non-mutating lookups skip passing an allocator (in one such case,
we were passing a scary-looking ZoneAllocationPolicy(NULL)!).
Review URL: https://codereview.chromium.org/1074943002
Cr-Commit-Position: refs/heads/master@{#27799}
This makes the compilers agree on the source position of a message
generated by "throw new Error()", it points to the beginning of the
throw directive.
R=titzer@chromium.org
TEST=message/regress/regress-3995
BUG=v8:3995
LOG=N
Review URL: https://codereview.chromium.org/1049703002
Cr-Commit-Position: refs/heads/master@{#27775}
When debugging Handle leaks in io.js we found it very convenient to be
able to Seal some specific (root in our case) scope to prevent Handle
allocations in it, and easily find leakage.
R=yangguo
BUG=
Review URL: https://codereview.chromium.org/1079713002
Cr-Commit-Position: refs/heads/master@{#27766}
This allows loopy TurboFan code to be interrupted by placing a stack
check (i.e. JSStackCheck node) into each loop. Note that we currently
limit this to non-asm.js code. Also note that stack checks are actually
placed after loop headers and not at back-branches, which allows us to
reuse existing BailoutIds from Crankshaft.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1065923002
Cr-Commit-Position: refs/heads/master@{#27666}
This is a follow-up to 2d281e71ac and prevents bailouts on empty
script contexts in Crankshaft, which don't need allocation. Only
non-empty script contexts should cause a bailout.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1063373003
Cr-Commit-Position: refs/heads/master@{#27649}
This enables eager optimization of top-level code with TurboFan and
extends test coverage by triggering it with the --always-opt flag.
Script contexts are now also properly allocated in TurboFan.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1053063003
Cr-Commit-Position: refs/heads/master@{#27633}
Instead, please use v8::Isolate::RequestInterrupt to synchronize
to the main thread.
R=yurys@chromium.org
API=Removed v8::Debug::DebugBreakForCommand
LOG=Y
Review URL: https://codereview.chromium.org/1036863002
Cr-Commit-Position: refs/heads/master@{#27625}
In DevTools we've already used sourceURL in inline scripts.
This CL makes the behavior of the V8 in the same for Error.stack property and v8::StackTrace.
BUG=v8:3920
LOG=Y
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1044173002
Cr-Commit-Position: refs/heads/master@{#27554}
The current GC idle time handling heuristics are getting too complicated. Moreover, with longer idle time we are getting more full garbage collections. This CL shrinks the idle round window and reduces complexity in the case where we cause a full garbage collection.
BUG=chromium:468554
LOG=n
Review URL: https://codereview.chromium.org/1024043003
Cr-Commit-Position: refs/heads/master@{#27493}
since the old style weakness is slated for removal, we might as well reuse the name to limit confusion. additionally I simplified the callback type to a enum to either get internal field values or not
this should be a non-breaking change with the exception of PhantomPersistentValueMap, which is unused.
R=jochen@chromium.org, erikcorry@chromium.org
BUG=
Review URL: https://codereview.chromium.org/989153003
Cr-Commit-Position: refs/heads/master@{#27084}
This keeps dying maps alive for FLAG_retain_maps_for_n_gc garbage collections
to increase chances of them being reused for new objects in future and
decrease number of deoptimizations.
BUG=v8:3664
LOG=N
TEST=cctest/test-heap/MapRetaining
Review URL: https://codereview.chromium.org/980523004
Cr-Commit-Position: refs/heads/master@{#27040}
If function.name property has string type then stack frame will contain it otherwise DebugName from shared function info.
BUG=17356
LOG=Y
R=yurys@chromium.org
Review URL: https://codereview.chromium.org/917743002
Cr-Commit-Position: refs/heads/master@{#27025}
According to Source Map specification [1] source map url can be passed either as a magic comment at the end of script or as SourceMap http header. We already parse the former value and expose it on Script object. This change allows to unify the way we deal with source map urls received in http header by providing api for passing that url into the script being compiled.
source_map_url is intentionally not passed into CompilationCacheScript::Lookup. The cache is anyways disabled when debugger is on.
[1] https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit
LOG=Y
BUG=chromium:462572
Review URL: https://codereview.chromium.org/983603003
Cr-Commit-Position: refs/heads/master@{#27017}
Additionally handlify the "transition" field so that GC can stop caring about it.
BUG=
Review URL: https://codereview.chromium.org/935033003
Cr-Commit-Position: refs/heads/master@{#26718}
Function.prototype.toMethod was removed from ES6.
This removes the function and updates the tests to either
use %ToMethod or a dedicated syntax (using concise method
or a class).
BUG=v8:3330
LOG=N
R=dslomov@chromium.org, adamk
Review URL: https://codereview.chromium.org/914713002
Cr-Commit-Position: refs/heads/master@{#26559}
A new map wich references its keys weakly is added to v8.h. Internally it uses the same storage as JSWeakMap but doesn't depend on the JavaScript part of WeakMap implementation in weak-collection.js, hence it can be instantiated without entering any context.
BUG=chromium:437416
LOG=Y
Review URL: https://codereview.chromium.org/900123003
Cr-Commit-Position: refs/heads/master@{#26451}
A new map wich references its keys weakly is added to v8.h. Internally it uses the same storage as JSWeakMap but doesn't depend on the JavaScript part of WeakMap implementation in weak-collection.js, hence it can be instantiated without entering any context.
BUG=chromium:437416
LOG=Y
Review URL: https://codereview.chromium.org/891473005
Cr-Commit-Position: refs/heads/master@{#26425}
Applies to API implementation of O.p.toString
- Removes special handling of non-string @@toStringTag values (use builtinTag)
- Removes special handling of @@toStringTags which match [[Class]] names (remove ~ prefix)
- Add tests for non-string @@toStringTag values in test-api.cc
BUG=v8:3502
R=arv@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/892393003
Cr-Commit-Position: refs/heads/master@{#26415}
A new map wich references its keys weakly is added to v8.h. Internally it uses the same storage as JSWeakMap but doesn't depend on the JavaScript part of WeakMap implementation in weak-collection.js, hence it can be instantiated without entering any context.
BUG=chromium:437416
LOG=Y
Review URL: https://codereview.chromium.org/886473005
Cr-Commit-Position: refs/heads/master@{#26401}
For exception in promise we generate v8::Message API object from exception object. And in cases of Syntax or Reference Error we don't have enough information in exception object - we can't restore Error location from top stack frame.
In this patch three aditional private fields introduced for exception object. In case of Syntax Error we store line, column and script on Exception object and receive this information when restoring message.
BUG=443140
LOG=Y
R=yurys@chromium.org
Review URL: https://codereview.chromium.org/885043002
Cr-Commit-Position: refs/heads/master@{#26393}
In DevTools we need one more flag for script origin - is debugger script. We already have "is shared origin" flag. The new flag added by analogy with the old but new has accessor in script object.
R=yurys@chromium.org
Review URL: https://codereview.chromium.org/879553002
Cr-Commit-Position: refs/heads/master@{#26324}
Use std::numeric_limits<double>::quiet_NaN() and
std::numeric_limits<float>::quiet_NaN() instead.
Review URL: https://codereview.chromium.org/864803002
Cr-Commit-Position: refs/heads/master@{#26195}
This method circumvented JS semantics, and should not be used.
BUG=
Review URL: https://codereview.chromium.org/854493004
Cr-Commit-Position: refs/heads/master@{#26157}
See CompileTopLevel for similar logic which suppresses producing parser cache
when the debugger is active.
BUG=441130
LOG=n
Review URL: https://codereview.chromium.org/845643005
Cr-Commit-Position: refs/heads/master@{#26138}
Support for it is slow and difficult to implement, and it's not used in
Blink. An embedder that uses this feature will have to check the
argument types itself.
BUG=none
R=dcarney@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/848173002
Cr-Commit-Position: refs/heads/master@{#26058}
There might be a number of clients that would like to
setup an interrupt request on the Isolate.
The patch also deprecates ClearInterrupt API. As long as
the interrupt handler is called outside of locks there's no way
to guarantee that the handler will not be called after
ClearInterrupt was invoked as it might have already started execution.
Review URL: https://codereview.chromium.org/796623003
Cr-Commit-Position: refs/heads/master@{#25910}
This keeps dying maps alive for FLAG_retain_maps_for_n_gc garbage collections to increase chances of them being reused for new objects in future.
BUG=v8:3664
LOG=N
TEST=cctest/test-heap/MapRetaining
Review URL: https://codereview.chromium.org/794583003
Cr-Commit-Position: refs/heads/master@{#25887}
This test case ( added by git: 4c7effe56e ).
should has different implementation for Turbofan and crankshaft.
BUG=
Review URL: https://codereview.chromium.org/774163005
Cr-Commit-Position: refs/heads/master@{#25713}
Blink already has code for handling invalid cached data. The attached test
ensures that cached data is gracefully rejected if it cannot be used.
This also unifies parser cache and code cache handling.
R=yangguo@chromium.org
BUG=439889
LOG=N
Review URL: https://codereview.chromium.org/781203003
Cr-Commit-Position: refs/heads/master@{#25708}
When compiling with the macro DCHECK_ALWAYS_ON defined, DCHECKs and
supporting code gets compiled and enabled.
This increases test coverage for chromium release buildbots
BUG=v8:3731
R=jkummerow@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/760213005
Cr-Commit-Position: refs/heads/master@{#25701}
This introduces Hydrogen for %_GetPrototype. The code falls back on
runtime if the object needs access checks or if its prototype is a
hidden prototype.
BUG=None
LOG=Y
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/756423006
Cr-Commit-Position: refs/heads/master@{#25694}
Groups and implicit references are no longer relevant at this point.
Also add tests that fail if the first or second round of ephemeral
marking is omitted
BUG=none
R=mstarzinger@chromium.org,hpayer@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/761343004
Cr-Commit-Position: refs/heads/master@{#25606}
v8::Object already has GetIdentityHash on it. This change adds its counterpart to v8::Name.
BUG=chromium:437416
LOG=Y
Review URL: https://codereview.chromium.org/753373003
Cr-Commit-Position: refs/heads/master@{#25598}
Updates Object.prototype.toString() to use algorithm described in harmony drafts.
Currently, the behaviour is essentially the same as ES262's version, however this changes when internal structures
such as Promise make use of symbolToStringTag (as they are supposed to, see v8:3241), and changes further once
Symbol.toStringTag is exposed publicly.
BUG=v8:3241, v8:3502
LOG=N
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/546803003
Patch from Caitlin Potter <caitpotter88@gmail.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24783 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
1) Since we fill the output buffer both from the chunks and the conversion
buffer, it's possible that we run out of space and call CopyCharsHelper with 0
length. The underlying functions don't handle it gracefully, so check there.
2) There was a bug where we used to try to copy too many characters from the
beginning of the data chunk into the conversion buffer. Continuation bytes in
UTF-8 are of the form 0b10XXXXXX. If a byte is bigger than that, it's the first
byte of a new UTF-8 character and we should ignore it.
These two together (or maybe in combination with surrogates) are a probable
reason for crbug.com/420932.
3) The test data was off; \uc481 is \xec\x92\x81.
BUG=420932
LOG=N
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/662003003
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24725 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The problem was that there can be several multi-byte UTF-8 characters near the
splitting point of the data chunks, and the code didn't handle it properly.
This was also the source of crbug.com/417891 - I thought the crash can only
happen when V8 is passed invalid UTF-8 data, but it can also happen in the
abovementioned case. After the fix, we handle the valid UTF-8 case and also
guard against invalid UTF-8 data.
R=yangguo@chromium.org
BUG=chromium:417891
LOG=N
Review URL: https://codereview.chromium.org/654503002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24547 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
> We also initialize the Isolate on creation.
>
> This should allow for getting rid of the last remaining default isolate
> traces. Also, it'll speed up several isolate related operations that no
> longer require locks.
>
> Embedders that relied on v8::Isolate to return an uninitialized Isolate
> (so they can set ResourceConstraints for example, or set flags that
> modify the way the isolate is created) should either do the setup before
> creating the isolate, or use the recently added CreateParams to pass e.g.
> ResourceConstraints.
>
> BUG=none
> LOG=y
> R=svenpanne@chromium.org
>
> Review URL: https://codereview.chromium.org/469783002
BUG=none
LOG=y
TBR=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/583153002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We also initialize the Isolate on creation.
This should allow for getting rid of the last remaining default isolate
traces. Also, it'll speed up several isolate related operations that no
longer require locks.
Embedders that relied on v8::Isolate to return an uninitialized Isolate
(so they can set ResourceConstraints for example, or set flags that
modify the way the isolate is created) should either do the setup before
creating the isolate, or use the recently added CreateParams to pass e.g.
ResourceConstraints.
BUG=none
LOG=y
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/469783002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24052 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We can only set resource constraints before the isolate is initialized.
Since in the future, we want to initialize isolates at construction
time, we need to set constraints there.
It's possible to later modify the stack limit, so introduce an
Isolate::SetStackLimit method for that.
The SetResourceConstraints method will be deprecated. Users should pass
ResourceConstraints to Isolate::New, and use Isolate::SetStackLimit to
later modify the stack limit.
BUG=none
R=svenpanne@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/559993005
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23964 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
several API methods will automatically initialize it. During this
uninitialized state, code event handlers and function entry handlers can
be attached to the isolate.
This CL deprecates SetFunctionEntryHook and moves the configuration of
those handlers to the Isolate factory method.
This will allow for initializing the Isolate at creation time in the
future.
Users of V8::SetFunctionEntryHook should pass the entry hook to
Isolate::New instead. V8::SetJitCodeEventHandler should either be passed
to Isolate::New as well, or (if startup events are not required) invoked
via the Isolate.
BUG=none
LOG=y
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/570993002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23940 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Add new "Name" type to API that is a supertype of Symbol and String.
Object::SetDeclaredAccessor, Object::SetAccessorProperty, Template::Set,
Template::SetAccessorProperty, and Template::SetDeclaredAccessor now
take a Name as the property name instead of a String.
Add Object::SetAccessor, Template::SetNativeDataProperty, and
ObjectTemplate::SetAccessor overloads that can define accessors for
symbol-named properties.
R=dcarney@chromium.org, rossberg@chromium.org
BUG=v8:3394
TEST=cctest/test-api/TestSymbolProperties
LOG=Y
Review URL: https://codereview.chromium.org/459413002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23247 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
(parser or code) and to be explicit about cache consumption or production
(rather than making presence of cached_data imply one or the other.)
Also add a --cache flag to d8, to allow testing the functionality.
-----------------------------
API change
Reason: Currently, V8 supports a 'parser cache' for repeatedly executing the same script. We'd like to add a 2nd mode that would cache code, and would like to let the embedder decide which mode they chose (if any).
Note: Previously, the 'use cached data' property was implied by the presence of the cached data itself. (That is, kNoCompileOptions and source->cached_data != NULL.) That is no longer sufficient, since the presence of data is no longer sufficient to determine /which kind/ of data is present.
Changes from old behaviour:
- If you previously didn't use caching, nothing changes.
Example:
v8::CompileUnbound(isolate, source, kNoCompileOptions);
- If you previously used caching, it worked like this:
- 1st run:
v8::CompileUnbound(isolate, source, kProduceToCache);
Then, source->cached_data would contain the
data-to-be cached. This remains the same, except you
need to tell V8 which type of data you want.
v8::CompileUnbound(isolate, source, kProduceParserCache);
- 2nd run:
v8::CompileUnbound(isolate, source, kNoCompileOptions);
with source->cached_data set to the data you received in
the first run. This will now ignore the cached data, and
you need to explicitly tell V8 to use it:
v8::CompileUnbound(isolate, source, kConsumeParserCache);
-----------------------------
BUG=
R=marja@chromium.org, yangguo@chromium.org
Review URL: https://codereview.chromium.org/389573006
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22431 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The callbacks are per isolate, so we shouldn't get the isolate implicitly
from TLS. Also, we shouldn't allow calls to these methods prior to
initializing the respective isolate (and silently ignore them).
Esp. add a per-isolate API to set the stats counter callbacks and
make it possible to set the stats counter callback after the isolate
was touched.
Embedders should use e.g. isolate->SetCounterFunction(callback) instead
of v8::V8::SetCounterFunction(callback).
BUG=none
R=svenpanne@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/365153002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22223 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Temporarily reverting until we figure out how to handle the API cases that use accessors to lazily compute values.
dataAttributeGetterCustom in V8MessageEventCustom (at least) overwrites itself with the computed value using ForceSet. We can either force such clients to first use ForceDelete before caching, use some other caching mechanism; or provide an API for lazily computed properties.
TBR=dcarney@chromium.org
BUG=
Review URL: https://codereview.chromium.org/365903005
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22173 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If the embedder calls V8::TerminateExecution while we're running microtasks, bail out
and clear any pending microtasks.
All other exceptions are simply swallowed. No current Blink or V8 microtasks throw, this
just ensures something sane happens if another embedder decides to pass a throwing
microtask (or if ours unexpectedly throw due to, e.g., stack exhaustion).
BUG=371566
LOG=Y
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/294943009
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21574 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Now we remember new space's top pointer after the last GC to find out if there was a new space allocation since the last GC.
Unfortunately, this not completely safe - the debugger has a callback hook (that can call to JS) at the end of the GC epilogue that can in theory allocate and possibly make the heap non-iterable. We can only hope this does not happen.
BUG=373283
R=hpayer@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/291193005
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21431 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
Esp. get rid of PreCompile in tests, as it's going to be removed.
Notes:
- The new compilation API doesn't have a separate precompilation phase, so there
is no separate way to check for errors except checking the compilation
errors. Removed some tests which don't make sense any more.
- test-api/Regress31661 didn't make sense as a regression test even before the
compilation API changes, because Blink doesn't precompile this short scripts. So
detecting this kind of errors (see crbug.com/31661 for more information) cannot rely
on precompilation errors.
- test-parsing/PreParserStrictOctal has nothing to do with PreParser, and the comment
about "forcing preparsing" was just wrong.
- test-api/PreCompile was supposed to test that "pre-compilation (aka
preparsing) can be called without initializing the whole VM"; that's no longer
true, since there's no separate precompilation step in the new compile
API. There are other tests (test-parsing/DontRegressPreParserDataSizes) which
ensure that we produce cached data.
- Updated tests which test preparsing to use PreParser directly (not via the
preparsing API).
- In the new compilation API, the user doesn't need to deal with ScriptData
ever. It's only used internally, and needed in tests that test internal aspects
(e.g., modify the cached data before passing it back).
- Some tests which used to test preparse + parse now test first time parse +
second time parse, and had to be modified to ensure we don't hit the
compilation cache.
BUG=
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/225743002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20511 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Use the surrounding map (instead of Traits::Impl) for weak callback.
- Provide for a fast reference to a mapped value.
- Restructure Traits to accomondate for the first point above.
[Why?] As discussed, I proceeded to replace Impl with the map.
The problem I encountered with that version is that now the
Traits class depends on itself: The weak-related methods require the
map type in their signature. But the map type includes the Traits class
and hence the Traits class method signatures depend on the specific Traits class. That
makes them practically un-derivable: While you can derive a Traits class
from another one, since the compiler now expects methods with a different
signature. To accommodate, I pulled the dispose traits into the weak traits
class. I also removed the Impl*/MapType* parameter from the Dispose call,
since no implementation seems to need it.
R=dcarney@chromium.org
BUG=
Review URL: https://codereview.chromium.org/212893007
Patch from Daniel Vogelheim <vogelheim@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20326 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Distinguish between context bound scripts (Script) and context unbound scripts
(UnboundScript).
- Add ScriptCompiler (which will later contain functions for async compilation).
This is a breaking change, in particular, Script::New no longer exists (it is
replaced by ScriptCompiler::CompileUnbound). Script::Compile remains as a
backwards-compatible shorthand for ScriptCompiler::Compile.
Passing CompilerOptions with produce_data_to_cache = true doesn't do anything
yet; the only way to generate the data to cache is the old preparsing API. (To
be fixed in the next version.)
This is a fixed version of https://codereview.chromium.org/186723005/
BUG=
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/199063003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19925 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
