An additional slide offset is exported into `shared-library`, which is used to
symbolize C++ stack on systems with ASLR (OS X).
This patch adds slide offset support in dumpcpp script.
BUG=v8:5048
Review-Url: https://codereview.chromium.org/2006813002
Cr-Commit-Position: refs/heads/master@{#36574}
Some tests, e.g. in test262, want to create a new same-origin
realm. This patch exposes a new function,
Realm.createAllowCrossRealmAccess(), which vends a new realm with
the same security token as the currently executing one.
Review-Url: https://codereview.chromium.org/1973363004
Cr-Commit-Position: refs/heads/master@{#36561}
Annex B 3.3 applies only for ordinary FunctionDeclarations, not
GeneratorDeclarations or AsyncFunctionDeclarations. This patch
- Skips applying Annex B 3.3 to async functions
- Adds a flag to refrain from applying it to generators
- UseCounter for how often duplicate function in block occurs
with generators (unclear how to measure need for hoisting from block)
BUG=v8:4806
Review-Url: https://codereview.chromium.org/1995863002
Cr-Commit-Position: refs/heads/master@{#36557}
Rewrite decodeURI and decodeURIComponent as builtin functions
and install them in the bootstrapper.
Delete unused runtime functions:
- TruncateString
- NewString
- OneByteSeqStringGetChar
- OneByteSeqStringSetChar
- TwoByteSeqStringGetChar
- TwoByteSeqStringSetChar
Add regression test for decoding large strings. Clusterfuzz detected
a problem with %TruncateString, see
https://bugs.chromium.org/p/chromium/issues/detail?id=612109#c6
This is automatically fixed by this rewrite because %TruncateString
is deleted anyways.
Crude benchmark on 585 decodeURI and decodeURIComponent tests
averaged over five runs:
* builtin functions
real 0m9.69s
user 2m39.8816s
sys 0m12.6398s
* JS functions calling into the runtime e.g., for %TruncateString
real 0m11.0598s
user 3m6.7026s
sys 0m13.5756s
By running:
$ time tools/run-tests.py --arch=x64 --mode=Release --buildbot
test262/built-ins/decodeURI* mjsunit/uri
>>> Running tests for x64.Release
BUG=v8:4912, chromium:612109
R=yangguo@chromium.org, bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/1994733003
Cr-Commit-Position: refs/heads/master@{#36543}
Removes the DONT_DELETE enum bit from the properties to make them
configurable.
Also, updates the regress-typedarray-length test to --
- Check for true boolean return value on deletion of these
properties.
- Check for undefined return value on trying to access these
properties after deletion.
BUG=v8:4902
LOG=Y
Review-Url: https://codereview.chromium.org/2001393004
Cr-Commit-Position: refs/heads/master@{#36528}
Intersection of types is used in several places,
if it yields the empty set, this indicates a type mismatch.
We should emit an error in this case.
Add the RECURSE() macro around IntersectResult to allow errors to propagate immediately.
BUG=614291
R=ahaas@chromium.org
TEST=asm-wasm
LOG=N
Review-Url: https://codereview.chromium.org/2011873002
Cr-Commit-Position: refs/heads/master@{#36525}
Previously we first created a temporary graph for the inlinee and then
copied over all the nodes to the actual graph. This however introduces
unnecessary complexity, and we can instead just create the inlinee
inside the target graph.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2006353003
Cr-Commit-Position: refs/heads/master@{#36508}
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/6248
Original issue's description:
> [keys] Simplify KeyAccumulator
>
> - Use KeyAccumulator::GetKeys directly instead of JSReceiver::GetKeys
> - Revert KeyAccumulator to single OrderedHashSet implementation.
> - Convert the OrderedHashSet in-place to a FixedArray
> - IndexedInterceptor indices are no longer combined and sorted with the object indices
>
> BUG=
>
> Committed: https://crrev.com/d3324df017046bcde247a5aef6d1b59bfae5908f
> Cr-Commit-Position: refs/heads/master@{#36485}
TBR=jkummerow@chromium.org,verwaest@chromium.org,cbruni@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.chromium.org/2010593002
Cr-Commit-Position: refs/heads/master@{#36486}
- Use KeyAccumulator::GetKeys directly instead of JSReceiver::GetKeys
- Revert KeyAccumulator to single OrderedHashSet implementation.
- Convert the OrderedHashSet in-place to a FixedArray
- IndexedInterceptor indices are no longer combined and sorted with the object indices
BUG=
Review-Url: https://codereview.chromium.org/1995263002
Cr-Commit-Position: refs/heads/master@{#36485}
Moved functionality of Script.{lineCount, lineFromPosition, sourceLine,
locationFromLine, and sourceSlice} into runtime functions.
R=yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2003303002
Cr-Commit-Position: refs/heads/master@{#36469}
Duplicate mjsunit/harmony/generators.js but explicitly require
--turbo-from-bytecode such that Clusterfuzz can thoroughly test the
new generators implementation.
BUG=v8:4907
Review-Url: https://codereview.chromium.org/2002983002
Cr-Commit-Position: refs/heads/master@{#36441}
This makes sure the deoptimizer can materialize sloppy arguments objects
with the FAST_SLOPPY_ARGUMENTS_ELEMENTS elements kind. TurboFan's escape
analysis treates those as normal JSObject types and hence materializes
them differently than Crankshaft does.
R=verwaest@chromium.org
TEST=mjsunit/regress/regress-crbug-613919
BUG=chromium:613919
Review-Url: https://codereview.chromium.org/2001133002
Cr-Commit-Position: refs/heads/master@{#36440}
The original peephole optimizer logic in the BytecodeArrayBuilder did
not respect source positions as it was written before there were
bytecode source positions. This led to some minor differences to
FCG and was problematic when combined with pending bytecode
optimizations. This change makes the new peephole optimizer fully
respect source positions.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/1998203002
Cr-Commit-Position: refs/heads/master@{#36439}
This makes escape analysis skip analyzing the code entry field within
JSFunction objects. Said field is an untagged pointer field and hence
cannot be tracked by an ObjectState node.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-613494
BUG=chromium:613494
Review-Url: https://codereview.chromium.org/1997353002
Cr-Commit-Position: refs/heads/master@{#36436}
The previous JavaScript version created way too many ConsStrings for
longer strings, i.e. when using String.fromCharCode together with
Function.prototype.apply and arrays of char codes.
This version now always allocates sequential strings and therefore uses
way less memory when turning longer character sequences into strings,
and therefore fixes the memory regression on Google Maps.
BUG=chromium:609831
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2004733002
Cr-Commit-Position: refs/heads/master@{#36427}
In VisitArrayLiteral(), we stopped creating boilerplates during
compilation. This created a bug, because we'd emit an HStoreKeyed with an
ElementsKind based on the initial elements kind of the boilerplate. Since
boilerplates may transition as part of elements transition feedback, this can
lead to incorrect values (storing a smi in a double array).
BUG=chromium:606021
Review-Url: https://codereview.chromium.org/2000673002
Cr-Commit-Position: refs/heads/master@{#36408}
In ES2015, the "byteLength" and "byteOffset" properties of DataViews are
getters on the prototype, so the previously-used strategy of special-casing
them using only the receiver map is invalid.
A future CL will need to use the same strategy which will be taken for
TypedArray "length", "byteLength", and "byteOffset": adding a prototype
chain check.
BUG=v8:5018, chromium:593634
Review-Url: https://codereview.chromium.org/1984043002
Cr-Commit-Position: refs/heads/master@{#36382}
Empty function names are allowed and are output as such, unnamed
functions or functions with no valid UTF-8 name are output as
"<WASM UNNAMED>", while the CallSite object returns null as the
function name.
R=titzer@chromium.org, yangguo@chromium.org
Review-Url: https://codereview.chromium.org/1970503004
Cr-Commit-Position: refs/heads/master@{#36348}
Remove kMakeHeapIterableMask since the heap is always iterable.
BUG=chromium:580959
LOG=n
Review-Url: https://codereview.chromium.org/1961373003
Cr-Commit-Position: refs/heads/master@{#36333}
This promotes the escape analysis from an experimental feature to be a
fully supported feature. The main goal is to unleach ClusterFuzz on the
implementation so that we can stabilize it.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/1989833002
Cr-Commit-Position: refs/heads/master@{#36324}
When setting a generator function's "prototype" property to a non-object, the
prototype of new generator instances should be %GeneratorPrototype%, not
%ObjectPrototype%.
R=verwaest@chromium.org
BUG=v8:5011
Review-Url: https://codereview.chromium.org/1982203003
Cr-Commit-Position: refs/heads/master@{#36313}
These guards are useless anyways once you make it throw the
effect/control linearizer because all memory operations and
calls are connected to the control and/or effect chain anyways
afterwards.
Drive-by-fix: Fail in the InstructionSelector if we ever see
a Guard node.
R=jarin@chromium.org
BUG=chromium:612142
Review-Url: https://codereview.chromium.org/1980383002
Cr-Commit-Position: refs/heads/master@{#36302}
This makes escape analysis treat all guard nodes in the graph as an
escaping use. We eventually want to properly handle guard nodes, this
just serves as a temporary workaround to get things going.
R=bmeurer@chromium.org
BUG=v8:602595
LOG=n
Review-Url: https://codereview.chromium.org/1972323004
Cr-Commit-Position: refs/heads/master@{#36286}
This adds back the instanceof operator support in the backends and
introduces a @@hasInstance protector cell on the isolate that guards the
fast path for the InstanceOfStub. This way we recover the ~10%
regression on Octane EarleyBoyer in Crankshaft and greatly improve
TurboFan and Ignition performance of instanceof.
R=ishell@chromium.orgTBR=hpayer@chromium.org,rossberg@chromium.org
BUG=chromium:597249, v8:4447
LOG=n
Review-Url: https://codereview.chromium.org/1980483003
Cr-Commit-Position: refs/heads/master@{#36275}
If the RegExp doesn't parse, then ES2015 specifies that
RegExp.prototype.compile does not mutate it. This patch changes
our RegExp implementation to follow that logic.
R=yangguo
Review-Url: https://codereview.chromium.org/1972093003
Cr-Commit-Position: refs/heads/master@{#36268}
Ordinary arrow functions have 'undefined' in their frame's receiver.
Generators restore the receiver to the frame based on one passed in
when they are constructed in CreateJSGeneratorObject.
This patch makes async arrow functions pass in 'undefined' for their
receiver so that they have the same behavior as ordinary arrow
functions, which avoids the issue of encountering TDZ when calling
an async arrow function in a subclass constructor before a super
call has returned.
BUG=v8:4483
Review-Url: https://codereview.chromium.org/1976813002
Cr-Commit-Position: refs/heads/master@{#36264}
This reverts commit 41d571dfe8.
Reason for revert: This patch breaks the correctness of the typedarray
properties such as length, byteOffset, byteLength.
The accessor check optimization code is dead code eliminated. A follow
up patch will fix this optimization correctly.
BUG=chromium:593634
Review-Url: https://codereview.chromium.org/1977983002
Cr-Commit-Position: refs/heads/master@{#36254}
We eagerly inserted Int32Mul for Math.imul during builtin lowering and
messed up with the types, which confused the representation selection.
This adds a proper NumberImul operator, and fixes the builtin reducer to
do the right thing according to the spec.
R=mstarzinger@chromium.org
BUG=v8:5006
LOG=n
Review-Url: https://codereview.chromium.org/1971163002
Cr-Commit-Position: refs/heads/master@{#36219}
Names passed for imports and exports are checked during decoding,
leading to errors if they are no valid UTF-8. Function names are not
checked during decode, but rather lead to undefined being returned at
runtime if they are not UTF-8.
We need to do these checks on the Wasm side, since the factory
methods assume to get valid UTF-8 strings.
R=titzer@chromium.org, yangguo@chromium.org
Review-Url: https://codereview.chromium.org/1967023004
Cr-Commit-Position: refs/heads/master@{#36208}
With this CL it is possible to compile a wasm module with multiple
threads in parallel. Parallel compilation works as follows:
1) The main thread allocates a compilation unit for each wasm function.
2) The main thread spawns WasmCompilationTasks which run on the
background threads.
3.a) The background threads and the main thread pick one compilation unit
at a time and execute the parallel phase of the compilation unit.
After finishing the execution of the parallel phase, the compilation
unit is stored in a result queue.
3.b) If the result queue contains a compilation unit, the main thread
dequeues it and finishes its compilation.
4) After the execution of the parallel phase of all compilation units has
started, the main thread waits for all WasmCompilationTasks to finish.
5) The main thread finalizes the compilation of the module.
I'm going to add some additional tests before committing this CL.
R=titzer@chromium.org, bmeurer@chromium.org, mlippautz@chromium.org, mstarzinger@chromium.org
Committed: https://crrev.com/17215438659d8ff2d7d55f95226bf8a1477ccd79
Cr-Commit-Position: refs/heads/master@{#36178}
Review-Url: https://codereview.chromium.org/1961973002
Cr-Commit-Position: refs/heads/master@{#36207}
Currently we do not check for @@isConcatSpreadable properly. If the Symbol is
set on the Array.prototype or Object.prototype the current fast paths fail.
This CL adds a fix to globally invalidate a isConcatSpreadable_protector.
Drive-by-fix: use named accessors for context variables
LOG=N
BUG=chromium:542504, v8:903
Review-Url: https://codereview.chromium.org/1409123003
Cr-Commit-Position: refs/heads/master@{#36201}
We got the condition wrong and actually deoptimized when the typed array
was not neutered. This fixes the deopt loop in Math.random and actually
many programs that use typed arrays.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/1970123002
Cr-Commit-Position: refs/heads/master@{#36194}
Reason for revert:
The ThreadSanitizer finds data races.
Original issue's description:
> [wasm] Implement parallel compilation.
>
> With this CL it is possible to compile a wasm module with multiple
> threads in parallel. Parallel compilation works as follows:
>
> 1) The main thread allocates a compilation unit for each wasm function.
> 2) The main thread spawns WasmCompilationTasks which run on the
> background threads.
> 3.a) The background threads and the main thread pick one compilation unit
> at a time and execute the parallel phase of the compilation unit.
> After finishing the execution of the parallel phase, the compilation
> unit is stored in a result queue.
> 3.b) If the result queue contains a compilation unit, the main thread
> dequeues it and finishes its compilation.
> 4) After the execution of the parallel phase of all compilation units has
> started, the main thread waits for all WasmCompilationTasks to finish.
> 5) The main thread finalizes the compilation of the module.
>
> I'm going to add some additional tests before committing this CL.
>
> R=titzer@chromium.org, bmeurer@chromium.org, mlippautz@chromium.org, mstarzinger@chromium.org
>
> Committed: https://crrev.com/17215438659d8ff2d7d55f95226bf8a1477ccd79
> Cr-Commit-Position: refs/heads/master@{#36178}
TBR=bmeurer@chromium.org,mlippautz@chromium.org,mstarzinger@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/1965243003
Cr-Commit-Position: refs/heads/master@{#36182}
The previous approach taken by FastNew[Sloppy,Strict,Rest]ArgumentsStub
looked at the function slot in order to skip stub frames
and find the JS frame. However, stub frames do not have a
function slot (in fact their fixed frame ends one slot
before the JS frame's function slot). Therefore, if this
location in the stub frame happens to have the function
object the create arguments stubs won't skip this frame
correctly.
Replace this approach with one where the stub is
specialized to either skip a frame if required (since
there will only ever be one extra frame on Ignition
the loop approach isn't necessary).
BUG=v8:4928
LOG=N
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_dbg
Review-Url: https://codereview.chromium.org/1949023003
Cr-Commit-Position: refs/heads/master@{#36181}
With this CL it is possible to compile a wasm module with multiple
threads in parallel. Parallel compilation works as follows:
1) The main thread allocates a compilation unit for each wasm function.
2) The main thread spawns WasmCompilationTasks which run on the
background threads.
3.a) The background threads and the main thread pick one compilation unit
at a time and execute the parallel phase of the compilation unit.
After finishing the execution of the parallel phase, the compilation
unit is stored in a result queue.
3.b) If the result queue contains a compilation unit, the main thread
dequeues it and finishes its compilation.
4) After the execution of the parallel phase of all compilation units has
started, the main thread waits for all WasmCompilationTasks to finish.
5) The main thread finalizes the compilation of the module.
I'm going to add some additional tests before committing this CL.
R=titzer@chromium.org, bmeurer@chromium.org, mlippautz@chromium.org, mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/1961973002
Cr-Commit-Position: refs/heads/master@{#36178}
Rather than pushing zero for the initial bytecode offset, we should push the
offset of the first bytecode handler, Smi tagged. This fixes the line number
for the top stack frame on overflow errors.
BUG=v8:4981
LOG=N
Review-Url: https://codereview.chromium.org/1950913004
Cr-Commit-Position: refs/heads/master@{#36137}
In the bytecode graphbuilder, translate the two generator-specific
bytecodes as a couple of runtime calls for now.
BUG=v8:4907
LOG=n
Review-Url: https://codereview.chromium.org/1957393004
Cr-Commit-Position: refs/heads/master@{#36134}
This implements declaration of lookup slots for variables and functions
within optimized code. Such a declaration only appears with top-level
eval code, which we only recently started handling in TurboFan.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/1962723002
Cr-Commit-Position: refs/heads/master@{#36125}
The bailout points for named and keyed property loads when doing super
property calls are not being prepared by full-codegen, even though we
are using them in TurboFan for deopts and stack traces.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-4971
BUG=v8:4971
LOG=n
Review-Url: https://codereview.chromium.org/1960083002
Cr-Commit-Position: refs/heads/master@{#36109}
The flag in question used to fall-back to Crankshaft whenever an OSR
request couldn't be handled by TurboFan. By now OSR in TurboFan is
sufficiently stabilized that one single --use-osr flag should do it.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/1960043002
Cr-Commit-Position: refs/heads/master@{#36102}
mjsunit/es6/mirror-collections fails with ignition because dead registers
may hold references to objects. This prevents GC from collecting
otherwise dead objects. Dead registers are not cleared because the cost
of clearing them outweighs its benefits. Hence, modifying this test to
work around this problem.
BUG=v8:4280,v8:4853
LOG=N
Review-Url: https://codereview.chromium.org/1945223002
Cr-Commit-Position: refs/heads/master@{#36098}
Some tests which fail with '--ignition --turbo --turbo-from-bytecode' pass with
just '--ignition'. Unskip these tests. Also group other tests with related
bugs.
BUG=v8:4680
LOG=N
Review-Url: https://codereview.chromium.org/1944413002
Cr-Commit-Position: refs/heads/master@{#36083}
This changes different locations to extract the reference to the wasm
object and the function index from the stack trace, and make it
available through all the APIs which process stack traces.
The javascript CallSite object now has the new methods isWasm(),
getWasmObject() and getWasmFunctionIndex(); the byte offset is
available via getPosition().
Function names of wasm frames should be fully functional with this
commit, position information works reliably for calls, but not for
traps like unreachable or out-of-bounds accesses.
R=titzer@chromium.org, yangguo@chromium.org
Review-Url: https://codereview.chromium.org/1909353002
Cr-Commit-Position: refs/heads/master@{#36067}
Scope analysis is over-conservative when treating variable resolutions
as possibly-shadowed by a sloppy eval. In the attached bug, this comes
into play since catch scopes have different behavior with respect to
the "calls eval" in eager vs lazy compilation (in the latter, they
are never marked as "calls eval" because CatchContexts don't have
an associated ScopeInfo).
This patch changes the scope-type check to also eliminate a few other
cases where shadowing isn't possible, such as non-declaration block scopes.
BUG=chromium:608279
LOG=n
Review-Url: https://codereview.chromium.org/1950803002
Cr-Commit-Position: refs/heads/master@{#36046}
Previously, the species protector was invalidated whenever the __proto__ of
an Array instance was manipulated. Then, if the map's new_target_is_base field
remained set, it was correct to conclude that GetPrototypeOf(array) was
%ArrayPrototype%. However, this choice caused the popular D3 framework to
invalidate the species protector, causing many functions to become slower.
This patch eliminates that aspect of the species protector. Instead, the check
is to look at the instance->map()->prototype(). It is valid to look directly
at the map's prototype slot, ignoring hidden prototypes and proxies, because
- This is only called on Array instances, so the receiver cannot be a Proxy.
- For hidden prototypes, any inaccuracy would only result in conservatively
taking the slow path.
Theoretically, this patch could make methods applied to arrays from other
contexts slower. However, the slowdown would only affect a particular array
instance and not have a global spill-over effect. Further, the slowdown could
be addressed by tracking, either in the instance's map or in the actual
prototype object, whether it is a %ArrayPrototype% from any context, in a way
which is cheap to query, and use that rather than comparing to the currently
executing native context.
In interactive testing, this patch led the OnShape CAD system to experience
faster load times (110+s -> 40s).
BUG=chromium:606207
LOG=Y
Review-Url: https://codereview.chromium.org/1936393002
Cr-Commit-Position: refs/heads/master@{#36033}
Unlike previous implementation where the 'continue' keyword was a feature of a return statement the keyword is now recognized as a part of expression. Error reporting was significantly improved.
--harmony-explicit-tailcalls option is now orthogonal to --harmony-tailcalls so we can test both modes at the same time.
This CL also adds %GetExceptionDetails(exception) that fetches hidden |start_pos| and |end_pos| values from the exception object.
BUG=v8:4915
LOG=N
Review-Url: https://codereview.chromium.org/1928203002
Cr-Commit-Position: refs/heads/master@{#36024}
This fixes a bug where returning from a class literal inside
a try-finally didn't restore the context properly when
entering the finally clause.
BUG=v8:4965
LOG=n
Review-Url: https://codereview.chromium.org/1952633002
Cr-Commit-Position: refs/heads/master@{#36021}
The inline allocation sequence in the optimizing compilers cannot deal
well with funky types like JSRegExp, which have some magic fields in
addition to the inobject properties. In Crankshaft we already use the
FastNewObjectStub for %_NewObject in general, so fix TurboFan to the same.
Hopefully one day we can kill %_NewObject completely.
R=jarin@chromium.org
BUG=chromium:609029
LOG=n
Review-Url: https://codereview.chromium.org/1943403004
Cr-Commit-Position: refs/heads/master@{#36006}
Compiler backends get their language mode from the current
function, but should instead be deriving it from the current scope.
This allows proper handling of the always-strictness of class declarations
and expressions, and in particular the treatment of 'eval' calls in an
extends clause as a strict eval.
Also fix the parser's RecordEvalCall logic to only reach out to the
DeclarationScope in sloppy mode, which fixes the strange case of a
sloppy function thinking it contains a sloppy eval when in fact
it contains only a strict eval.
BUG=v8:4970
LOG=n
Review-Url: https://codereview.chromium.org/1931003003
Cr-Commit-Position: refs/heads/master@{#36001}
The problem is actually not related to try-catch, so here is a test
without try-catch.
BUG=chromium:607493
LOG=n
Review-Url: https://codereview.chromium.org/1943883002
Cr-Commit-Position: refs/heads/master@{#35985}
The ECMA 402 implementation previously pushed directly to real
Arrays, which risks having observably incorrect behavior in the
presence of monkey patching. This patch uses InternalArrays instead
to avoid that hazard.
R=jshin@chromium.org,yangguo@chromium.org
BUG=chromium:604299
LOG=N
Review-Url: https://codereview.chromium.org/1923803002
Cr-Commit-Position: refs/heads/master@{#35949}
