BUG=v8:2943
LOG=Y
TEST=Unit tests for "real life" use cases, edge cases, various types of normalization.
==========================
This is identical to the previous CL
https://codereview.chromium.org/40133004/
with two differences:
* Added a dummy implementation of String.prototype.normalize to be used when v8 is compiled without intl support
* Rebased the the test files for webkit. That was the only reason for the previous failure (and revert).
Thank you,
Mihai
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/68133016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18972 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The webkit/function-apply-aliased.js test fails on simulators (both MIPS
and ARM) as the printed output does not match to the expected. The
failing test forces a stack overflow exception and the ToString()
operation of the exception object fails because of an other stack
overflow and returns an empty string.
The problem is that on hardware a common JS and C stack is used so the
stack overflow can be caught in C functions also while on simulator
separated JS and C stacks are used.
This patch adds a "sim" condition to test .status files to skip tests
only on simulator.
LOG=N
BUG=v8:3124
R=jkummerow@chromium.org, plind44@gmail.com
Review URL: https://codereview.chromium.org/139233005
Patch from Balazs Kilvady <kilvadyb@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18959 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
version is passing all the existing test + a bunch of new tests
(packaged in the change list, too).
The patch extends the SlotRef object to describe captured and duplicated
objects. Since the SlotRefs are not independent of each other anymore,
there is a new SlotRefValueBuilder class that stores the SlotRefs and
later materializes the objects from the SlotRefs.
Note that unlike the previous implementation of SlotRefs, we now build
the SlotRef entries for the entire frame, not just the particular
function. This is because duplicate objects might refer to previous
captured objects (that might live inside other inlined function's part
of the frame).
We also need to store the materialized objects between other potential
invocations of the same arguments object so that we materialize each
captured object at most once. The materialized objects of frames live
in the new MaterielizedObjectStore object (contained in Isolate),
indexed by the frame's FP address. Each argument materialization (and
deoptimization) tries to lookup its captured objects in the store before
building new ones. Deoptimization also removes the materialized objects
from the store. We also schedule a lazy deopt to be sure that we always
get rid of the materialized objects and that the optmized function
adopts the materialized objects (instead of happily computing with its
captured representations).
Concerns:
- Is the FP address the right key for a frame? (Note that deoptimizer's
representation of frame is different from the argument object
materializer's one - it is not easy to find common ground.)
- Performance is suboptimal in several places, but a quick local run of
benchmarks does not seem to show a perf hit. Examples of possible
improvements: smarter generation of SlotRefs (build other functions'
SlotRefs only for captured objects and only if necessary), smarter
lookup of stored materialized objects.
- Ideally, we would like to share the code for argument materialization
with deoptimizer's materializer. However, the supporting data structures
(mainly the frame descriptor) are quite different in each case, so it
looks more like a separate project.
Thanks for any feedback.
R=danno@chromium.org, mstarzinger@chromium.org
LOG=N
BUG=
Committed: https://code.google.com/p/v8/source/detail?r=18918
Review URL: https://codereview.chromium.org/103243005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18936 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
mostly to make sure that it is going in the right direction. The current
version is passing all the existing test + a bunch of new tests
(packaged in the change list, too).
The patch extends the SlotRef object to describe captured and duplicated
objects. Since the SlotRefs are not independent of each other anymore,
there is a new SlotRefValueBuilder class that stores the SlotRefs and
later materializes the objects from the SlotRefs.
Note that unlike the previous implementation of SlotRefs, we now build
the SlotRef entries for the entire frame, not just the particular
function. This is because duplicate objects might refer to previous
captured objects (that might live inside other inlined function's part
of the frame).
We also need to store the materialized objects between other potential
invocations of the same arguments object so that we materialize each
captured object at most once. The materialized objects of frames live
in the new MaterielizedObjectStore object (contained in Isolate),
indexed by the frame's FP address. Each argument materialization (and
deoptimization) tries to lookup its captured objects in the store before
building new ones. Deoptimization also removes the materialized objects
from the store. We also schedule a lazy deopt to be sure that we always
get rid of the materialized objects and that the optmized function
adopts the materialized objects (instead of happily computing with its
captured representations).
Concerns:
- Is there a simpler/more correct way to store the already-materialized
objects? (At the moment there is a custom root reference to JSArray
containing frames' FixedArrays with their captured objects.)
- Is the FP address the right key for a frame? (Note that deoptimizer's
representation of frame is different from the argument object
materializer's one - it is not easy to find common ground.)
- Performance is suboptimal in several places, but a quick local run of
benchmarks does not seem to show a perf hit. Examples of possible
improvements: smarter generation of SlotRefs (build other functions'
SlotRefs only for captured objects and only if necessary), smarter
lookup of stored materialized objects.
- Ideally, we would like to share the code for argument materialization
with deoptimizer's materializer. However, the supporting data structures
(mainly the frame descriptor) are quite different in each case, so it
looks more like a separate project.
Thanks for any feedback.
R=mstarzinger@chromium.org, danno@chromium.org
LOG=N
BUG=
Review URL: https://codereview.chromium.org/103243005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18918 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Throwing under FLAG_debug_code confuses the rest of our infrastructure
which expects a safe point at the site of call into the runtime
for throw. We were doing that to make a clusterfuzz test happy, but
the better solution is to assert/abort under debug_code, and prevent
clusterfuzz from fuzzing on internal APIs that crash on incorrect
values.
We'll need to alter the fuzzer to turn off fuzzing for:
string-natives.js
lithium/SeqStringSetChar.js
regress/regress-seqstrsetchar-ex3.js
regress/regress-seqstrsetchar-ex1.js
regress/regress-crbug-320922.js
So as to prevent the fuzzer from running
%_OneByteSeqStringSetChar() and
%_TwoByteSeqStringSetChar().
BUG=
R=hpayer@chromium.org, machenbach@chromium.org
Review URL: https://codereview.chromium.org/139903005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18878 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This reverts:
r18749 "Reland (and fix) "Add hydrogen support for ArrayPop, and remove the handwritten call stubs."",
r18790 "Remove ArrayPush from the custom call generators, and instead call directly to the handler in crankshaft.", and
r18798 "MIPS: Remove ArrayPush from the custom call generators, and instead call directly to the handler in crankshaft."
For causing crashes on Canary.
BUG=chromium:337686
LOG=N
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/146003006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18805 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We removed an HDiv by hand which was still used by an HChange. The
solution is letting dead code removal do the cleanup.
Removed a fragile "optimization" (looking through an HChange), too,
this obviously never triggered and is hard to get right given all our
global invariants and state/type/... changes.
The repro is a bit tricky, because you need inlining to make our
representations and types disagree in this case.
LOG=y
BUG=334708
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/143903016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18737 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch makes String::WriteUtf8 replace invalid code points (i.e. unmatched
surrogates) with the unicode replacement character when REPLACE_INVALID_UTF8 is
set. This is done to avoid creating invalid UTF-8 output which can lead to
compatibility issues with software requiring valid UTF-8 inputs (e.g. the
WebSocket protocol requires valid UTF-8 and terminates connections when invalid
UTF-8 is encountered).
R=dcarney@chromium.org
BUG=
Review URL: https://codereview.chromium.org/121173009
Patch from Felix Geisendörfer <haimuiba@gmail.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18683 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Recent changes in IC logic meant that CallStubs no longer use the Contextual bit. IsUndeclaredGlobal() needed to adjust for that.
In fact, now the CL has morphed to remove the notion of storing contextual state in the IC at all, it just becomes some extra ic state of the load ic. This took some adjustment in harmony code to use the global receiver for certain stores.
Now it's clearer that only LoadICs actually record any information about contextual or not.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/140943002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18660 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
When invoking a setter callback for a property using
JSObject::SetPropertyWithCallback(),the callback arguments includes
a correct pair of receiver and holder objects.
Such a pair of _possibly different_ arguments (receiver, holder) must
also be supplied when invoking the same setter callback from JITed
code, when the setter is invoked through the StoreCallbackProperty
stub.
An example where this matters are the accessor properties kept on the
global scope of Worker (i.e., properties kept on the global object
itself, and not on its prototype.) Conflating the receiver with the
holder leads to general confusion when attempting to fetch out the
wrapper object.
LOG=N
R=dcarney@chromium.org, dcarney
BUG=239669
Review URL: https://codereview.chromium.org/139263008
Patch from Sigbjorn Finne <sigbjornf@opera.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18658 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is done similar to weak embedded objects in optimized code (r17102). The
reference from optimized code to a cell is treated weakly in marking visitors
if the cell points to a JSObject. After marking we iterate over all cells
embedded in optimized code. If a cell is not marked but its value is marked,
then we revive the cell by marking it. Otherwise, the cell value is dead, so
we mark the code for deoptimization.
BUG=v8:2073
TEST=cctest/test-heap/CellsInOptimizedCodeAreWeak
LOG=Y
R=hpayer@chromium.org, mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/117483002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18616 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
From ES6 rev20 draft, closed generator returns completed object (the
value is `undefined` and done is `true`).
Since a error thrown in generator is propagated to the caller without
setting status of a thrown generator to "completed", once a generator is
suspended by a error, status becomes "executing" forever. This is filed
as v8:3096
LOG=N
BUG=v8:3097
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/136003003
Patch from Yusuke Suzuki <yusukesuzuki@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18591 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Add missing constants, predicates and functions to the Number
constructor to have it offer what ES6 now specifies.
That is, extend it with:
* isInteger(), isSafeInteger()
* parseInt(), parseFloat()
* EPSILON, MIN_SAFE_INTEGER, MAX_SAFE_INTEGER
LOG=N
R=mstarzinger@chromium.org
BUG=v8:3082
Review URL: https://codereview.chromium.org/124573002
Patch from Sigbjorn Finne <sigbjornf@opera.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18480 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
by escape analysis). Added several tests that expose the bug.
Summary:
LCodegen::AddToTranslation assumes that Lithium environments are
generated by depth-first traversal, but LChunkBuilder::CreateEnvironment
was generating them in breadth-first fashion. This fixes the
CreateEnvironment to traverse the captured objects depth-first.
Note:
It might be worth considering representing LEnvironment by a list
with the same order as the serialized translation representation
rather than having two lists with a subtle relationship between
them (and then serialize in a slightly different order again).
R=titzer@chromium.org, mstarzinger@chromium.org
LOG=N
BUG=
Review URL: https://codereview.chromium.org/93803003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18470 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In Runtime_GetLocalPropertyNames(), the hidden prototypes of an object
are also consulted when deriving the property name set. However, if
given a function object and its template was inherited from the
template of one of its hidden prototypes, that hidden prototype's
property accessors will be present on the object already. Unwanted
duplicates will therefore appear.
Hence, go through the property names that the hidden prototypes
contribute and remove any already occurring ones.
Assumed to be a rare constellation, so the cost of this extra pass is
considered acceptable.
LOG=N
R=dcarney@chromium.org, jochen@chromium.org, rossberg@chromium.org
BUG=269562
Review URL: https://codereview.chromium.org/116533003
Patch from Sigbjorn Finne <sof@opera.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18448 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch contains contributions from the following members of the
BlackBerry Web Technologies team:
Eli Fidler <efidler@blackberry.com>
Konrad Piascik <kpiascik@blackberry.com>
Jeff Rogers <jrogers@blackberry.com>
Cosmin Truta <ctruta@blackberry.com>
Peter Wang <peter.wang@torchmobile.com.cn>
Xiaobo Wang <xiaobwang@blackberry.com>
Ming Xie <mxie@blackberry.com>
Leo Yang <leoyang@blackberry.com>
R=bmeurer@chromium.org, jkummerow@chromium.org
Review URL: https://codereview.chromium.org/61153009
Patch from Cosmin Truta <ctruta@blackberry.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18430 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If concurrent recompilation finishes before OSR, then OSR replaces
the old optimized code without evicting it from the optimized code map.
New functions can get the old optimized code from the optimized code map,
but the old code could be already deoptimized.
BUG=330046
TEST=test/mjsunit/regress-330046.js
LOG=Y
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/109033003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18420 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
It's of much use when information about function calls is shown on the Events timeline in DevTools: instead of referencing to v8natives.js where bound functions are created, we'll be able to show real function data (name, resource, script line and column numbers) retrieved from original functions.
BUG=None
LOG=Y
R=yangguo@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/106763002
Patch from Alexandra Mikhaylova <amikhaylova@google.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18401 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The test was broken. V8 currently does not correctly lookup NativeDataProperty accessors attached to the PrototypeTemplate of FunctionTemplate (Issue 3066). As the result while(obj.shouldContinue) loop was immediately exiting and the test would terminate while RequestInterruptTestBase::InterruptThread would be still starting up. As the result later InterruptThread would try to access members of the test object which was destroyed.
The test was fixed:
- instead of attaching accessor to PrototypeTemplate we attach it to InstanceTemplate;
- an assertion was added to verify that we completed the test successfully due to interruptor firing not due to sporadic loop termination due to some unrelated bug.
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/109653010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18391 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We don't use the worker pool yet, however, there are tests. Yay. The
next step is to use the worker pool for parallel sweeping.
I've also started to move the platform related files into a sub
directory. The goal is to eventually build all the platform stuff as
a separate library which is used by d8 and cctest (and other embedders
that wish to use the default implementation) but not by chromium.
BUG=v8:3015
R=hpayer@chromium.org, svenpanne@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/104583003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18380 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Introduce API to temporarily interrupt long running JavaScript code.
It is different from termination API as interrupted JavaScript will continue to execute normally when registered InterruptCallback returns.
/**
* Request V8 to interrupt long running JavaScript code and invoke
* the given |callback| passing the given |data| to it. After |callback|
* returns control will be returned to the JavaScript code.
* At any given moment V8 can remember only a single callback for the very
* last interrupt request.
* Can be called from another thread without acquiring a |Locker|.
* Registered |callback| must not reenter interrupted Isolate.
*/
void RequestInterrupt(InterruptCallback callback, void* data);
/**
* Clear interrupt request created by |RequestInterrupt|.
* Can be called from another thread without acquiring a |Locker|.
*/
void ClearInterrupt();
Fix Hydrogen SCE pass to avoid eliminating stack guards too aggressively. Only normal JavaScript functions are guaranteed to have stack guard in the prologue. If function is a builtin or has a custom call IC it will lack one.
Changes from r18363:
- includes r18364 to fix compilation errors: removes debugging only code;
- makes interrupiton related tests not threaded, because they rely on having exclusive access to the V8 instance and the fact that they can only interrupt themselves, if they are interrupted from the outside they break;
- changes HasStackCheck predicate used during SCE pass to avoid handles dereference to make SCE compatible with parallel recompilation.
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/104823008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18375 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
