We'd like wasm regressions to live under a subfolder of the mjsunit
regression folder.
BUG=
Review-Url: https://codereview.chromium.org/2344373002
Cr-Commit-Position: refs/heads/master@{#39483}
Normally the parser just uses AstConsStrings to concatenate, but some
types require an AstRawString. This patch adds an AstValueFactory
method which produces one from two AstRawStrings.
Review-Url: https://codereview.chromium.org/2348783002
Cr-Commit-Position: refs/heads/master@{#39482}
This patch implements a bug fix to the async/await specification described
at https://github.com/tc39/ecma262/pull/692#issuecomment-247488411
Namely, the intermediate values of Promises may be rejected, and they do
not have .then called on them anymore (now that the memory leak is fixed),
but they do not correspond do unhandled rejections. This change has been
tested manually with integration with Blink; once it is checked in and
rolled, then further tests can be added on the Blink side for the uncaught
rejection handler and async/await.
BUG=v8:4483
Review-Url: https://codereview.chromium.org/2338273007
Cr-Commit-Position: refs/heads/master@{#39480}
This patch closes a memory leak in async/await where the desugaring
was creating a situation analagous to that described in v8:5002.
Intermediate Promises were being kept alive, so a long-running loop
would cause linear memory usage on the heap. This patch returns
undefined to the 'then' callback passed into PerformPromiseThen
in order to avoid this hazard. Test expectations are fixed to remove
expecting extraneous events which occurred on Promises that are
now not given unnecessarily complex resolution paths before being
thrown away.
BUG=v8:5390
Review-Url: https://codereview.chromium.org/2334323006
Cr-Commit-Position: refs/heads/master@{#39479}
For denominators that are powers of two, replace Float64 division with
multiplication by the reciprocal.
Additionally, replace division by -1 with negation, and multiplication by two
with addition.
BUG=
Review-Url: https://codereview.chromium.org/2347573002
Cr-Commit-Position: refs/heads/master@{#39478}
Rename JSModule to Module and make it a Struct rather than a JSObject. We will
later add a separate JSModuleNamespace object to implement the 'import * as foo'
syntax.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2345823002
Cr-Commit-Position: refs/heads/master@{#39477}
This CL also cleans up related interface descriptors:
1) unused StoreTransitionDescriptor is removed and VectorStoreTransitionDescriptor is
renamed to StoreTransitionDescriptor.
2) on ia32/x87 architectures slot and vector are passed on the stack (dispatcher/handlers
cleanup will be addressed in a separate CL).
These two stub ports have to be combined in one CL because:
1) without changing the StoreTransitionDescriptor TF was not able to compile them
on ia32/x87 (because of lack of registers),
2) it was not possible to change the descriptor first because Crankshaft was not able
to deal with the stack allocated parameters in case of a stub failure.
TBR=jkummerow@chromium.org
BUG=v8:5269
Review-Url: https://codereview.chromium.org/2313093002
Cr-Commit-Position: refs/heads/master@{#39476}
Reason for revert:
Revert because this breaks V8's roll into Chromium. ASAN complains about memory accesses in a particular unit test.
Borked roll CL:
https://codereview.chromium.org/2348833002/
Reproduce breakage with:
1, args.gn:
v8_deprecation_warnings = true
use_goma = true
is_asan = true
2, ninja -C out/... content_browsertests
3, out/.../content_browsertests --gtest_filter=V8SamplingProfilerTest.*
Original issue's description:
> [Tracing] Remove unnecessary memory allocation in runtime call stats.
>
> Previously we didn't implement TRACE_STR_COPY when we write trace events to
> file, which causes us to allocate a growing independent memory chunk for dumped
> runtime call stats table. Since we now have a fully functional TRACE_STR_COPY,
> this memory allocation can be avoided, this patch removes it.
>
> BUG=v8:5089
>
> Committed: https://crrev.com/e1997bb7d780d12e3a89078e8dd652dcf1d90039
> Cr-Commit-Position: refs/heads/master@{#39462}
TBR=cbruni@chromium.org,fmeawad@chromium.org,lpy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5089
Review-Url: https://codereview.chromium.org/2349593004
Cr-Commit-Position: refs/heads/master@{#39475}
crrev.com/2339933002 and crrev.com/2314663002 were overlapping, so
this slipped through the cracks.
R=jochen@chromium.org
BUG=v8:4947, chromium:646794
Review-Url: https://codereview.chromium.org/2343093002
Cr-Commit-Position: refs/heads/master@{#39474}
Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup
variables that can be context loaded, without calling the runtime, as
long as there was no context extension by a sloppy eval along their
context chain.
BUG=v8:5263
Review-Url: https://codereview.chromium.org/2343633002
Cr-Commit-Position: refs/heads/master@{#39473}
The predicate in question should only trigger once and hence the stack
height should not be updated incrementally. This puts checks into place
ensuring this holds.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2333923008
Cr-Commit-Position: refs/heads/master@{#39472}
Reason for revert:
This approach is not good - breaks when we recompile.
Original issue's description:
> Preparse inner functions.
>
> This is an overly pessimistic approach where PreParser only keeps
> track of unresolved variables, but doesn't declare anything. This
> will result in context-allocating variables in the outer function
> unnecessarily, if the variable names clash with variable names
> used by the inner function (even if the variables are not the
> same). However, we have been unable to prove that this approach
> wouldn't be good enough for the practical purposes.
>
> Committed: https://crrev.com/e1341ca8fa486bb2c9e4236672a64ec7756a164d
> Cr-Commit-Position: refs/heads/master@{#39469}
TBR=adamk@chromium.org,vogelheim@chromium.org,nikolaos@chromium.org,nednguyen@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2349473004
Cr-Commit-Position: refs/heads/master@{#39471}
In ignition, arguments to function calls and function constructors are
pushed onto the stack before calling the function. It is required to check
that stack does not overflow when pushing the arguments.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/2335513004
Cr-Commit-Position: refs/heads/master@{#39470}
This is an overly pessimistic approach where PreParser only keeps
track of unresolved variables, but doesn't declare anything. This
will result in context-allocating variables in the outer function
unnecessarily, if the variable names clash with variable names
used by the inner function (even if the variables are not the
same). However, we have been unable to prove that this approach
wouldn't be good enough for the practical purposes.
Review-Url: https://codereview.chromium.org/2322243002
Cr-Commit-Position: refs/heads/master@{#39469}
During feedback typing (in SimplifiedLowering) we might be able to
constant-fold a bunch of ObjectIs<Type> predicates, i.e. because we
took type feedback on the input or we narrowed the type of a Phi
because of type feedback.
R=mvstanton@chromium.org
BUG=v8:5267,v8:5270
Review-Url: https://codereview.chromium.org/2342283002
Cr-Commit-Position: refs/heads/master@{#39468}
This ensures that {Compiler::EnsureBytecode} fails gracefully in case
the --ignition-filter flag prevents generation of bytecode for a certain
set of functions. This can be triggered via inlining.
R=rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2340293002
Cr-Commit-Position: refs/heads/master@{#39466}
- Smaller, more consistent streams API (Advance, Back, pos, Seek)
- Remove implementations from the header, in favor of creation functions.
Observe:
- Performance:
- All Utf16CharacterStream methods have an inlinable V8_LIKELY w/ a
body of only a few instructions. I expect most calls to end up there.
- There used to be performance problems w/ bookmarking, particularly
with copying too much data on SetBookmark w/ UTF-8 streaming streams.
All those copies are gone.
- The old streaming streams implementation used to copy data even for
2-byte input. It no longer does.
- The only remaining 'slow' method is the Seek(.) slow case for utf-8
streaming streams. I don't expect this to be called a lot; and even if,
I expect it to be offset by the gains in the (vastly more frequent)
calls to the other methods or the 'fast path'.
- If it still bothers us, there are several ways to speed it up.
- API & code cleanliness:
- I want to remove the 'old' API in a follow-up CL, which should mostly
delete code, or replace it 1:1.
- In a 2nd follow-up I want to delete much of the UTF-8 handling in Blink
for streaming streams.
- The "bookmark" is now always implemented (and mostly very fast), so we
should be able to use it for more things.
- Testing & correctness:
- The unit tests now cover all stream implementations,
and are pretty good and triggering all the edge cases.
- Vastly more DCHECKs of the invariants.
BUG=v8:4947
Review-Url: https://codereview.chromium.org/2314663002
Cr-Commit-Position: refs/heads/master@{#39464}
Ensure we can serialize a wasm compiled module even after it was
instantiated a few times.
BUG=
Review-Url: https://codereview.chromium.org/2339933003
Cr-Commit-Position: refs/heads/master@{#39463}
Previously we didn't implement TRACE_STR_COPY when we write trace events to
file, which causes us to allocate a growing independent memory chunk for dumped
runtime call stats table. Since we now have a fully functional TRACE_STR_COPY,
this memory allocation can be avoided, this patch removes it.
BUG=v8:5089
Review-Url: https://codereview.chromium.org/2342643004
Cr-Commit-Position: refs/heads/master@{#39462}
Rolling v8/build to 3f47a5e106127ae4e2567d64c615dc706054c819
Rolling v8/tools/clang to bd7e80b254a93d0a5cd8ecb994e47b1c827e253c
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2347783002
Cr-Commit-Position: refs/heads/master@{#39461}
This is one part of a WIP implementation of the stage-2 proposal to add
fields to classes: https://github.com/tc39/proposal-class-public-fields
See design doc:
https://docs.google.com/document/d/1WRtNm3ZLNJT1WVr8aq4RJuByYgfuAFAhj20LwTW6JVE/
This adds support for parsing fields in classes, including
infrastructure. In particular, it adds:
* Two booleans on function literal AST nodes
* Two compiler hints on SharedFunctionInfos representing said bools
* A new type of ClassLiteralProperty, FIELD
* Parser support for the syntax
* Syntax tests
* A flag to enable it.
Currently the fields are parsed and then droppped. Subsequent
patches will add semantics, mostly by desugaring in the parser and
the remainder in the non-crankshaft backends.
BUG=v8:5367
Review-Url: https://codereview.chromium.org/2315733003
Cr-Commit-Position: refs/heads/master@{#39459}
Previously, macro like PREPARE_FOR_EXECUTION_WITH_CALLBACK will end up calling
LOG_API, where we create a runtime call timer scope when we enable tracing with
runtime call stats, however since the flag will be enabled after calling
TRACE_EVENT_CALL_STATS_SCOPED, this will end up with incorrect timestamp. Thus,
we introduce a new macro
PREPARE_FOR_EXECUTION_WITH_CONTEXT_IN_RUNTIME_CALL_STATS_SCOPE, which will call
TRACE_EVENT_CALL_STATS_SCOPED inside it.
BUG=v8:5089
Review-Url: https://codereview.chromium.org/2344723004
Cr-Commit-Position: refs/heads/master@{#39458}
We don't need the context anymore for parsing, the scope info chain is
enough.
BUG=v8:5215
R=marja@chromium.org,jgruber@chromium.org,mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2342443004
Cr-Commit-Position: refs/heads/master@{#39457}
Reason for revert:
With fixes for frozen RegExps in https://codereview.chromium.org/2339443002 , it should be web-compatible to put RegExps in strict mode again, per spec.
Original issue's description:
> Revert of Put RegExp js code in strict mode (patchset #2 id:20001 of https://codereview.chromium.org/1776883005/ )
>
> Reason for revert:
> Found to break SAP Web IDE, and these semantics are not shipped in any other browser.
> Revert to legacy semantics while assessing web compatibility.
>
> BUG=chromium:624318
>
> Original issue's description:
> > Put RegExp js code in strict mode
> >
> > src/js/regexp.js was one of the few files that was left in sloppy
> > mode. The ES2017 draft specification requires that writes to
> > lastIndex throw when the property is non-writable, and test262
> > tests enforce this behavior. This patch puts that file in strict
> > mode.
> >
> > BUG=v8:4504
> > R=yangguo@chromium.org
> > LOG=Y
> >
> > Committed: https://crrev.com/80b1b2a45bbd9bf3d08e4e6516acfaaa8f438213
> > Cr-Commit-Position: refs/heads/master@{#34801}
>
> TBR=yangguo@chromium.org,adamk@chromium.org
>
> Committed: https://crrev.com/34880eb3dcf7492d44c0a3b45b6c888189f2c3c3
> Cr-Commit-Position: refs/heads/master@{#37449}
TBR=adamk@chromium.org,yangguo@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:624318
Review-Url: https://codereview.chromium.org/2344773002
Cr-Commit-Position: refs/heads/master@{#39456}
This was one of the paths inside StackGuard that lacked a runtime counter,
making it hard to assess what was going on.
BUG=
Review-Url: https://codereview.chromium.org/2346863002
Cr-Commit-Position: refs/heads/master@{#39455}
There is no zero length array usage in inspector codebase. We can safely remove template specialization.
It was reverted to revert another patch and is good by itself.
BUG=chromium:635948
TBR=jochen@chromium.org
Review-Url: https://codereview.chromium.org/2340193002
Cr-Commit-Position: refs/heads/master@{#39454}
To avoid a dependency on the heap during parsing, we only create a scope chain
without linking to the associated ScopeInfo objects before parsing. This is
enough to avoid special cases during parsing of arrow functions / eval.
Looking at the outer scope's variables during parsing was only needed for hosting
sloppy block functions inside eval. To be able to do this now, we hoist for the
outer-most eval scope after parsing, in DeclarationScope::Analyze.
DeclarationScope::Analyze is also where we replace the outer scope chain with the
fully deserialized version, so variables can be resolved.
Also, this unifies background and foreground thread parsing, as we don't have to
worry about ScopeInfos getting accessed before we're back on the main thread.
BUG=v8:5215
R=verwaest@chromium.org,marja@chromium.org,adamk@chromium.org
Review-Url: https://codereview.chromium.org/2306413002
Cr-Commit-Position: refs/heads/master@{#39452}
All parameters passed by reference must be labeled const.
If the object is mutable, then we pass by pointer.
BUG=
Review-Url: https://codereview.chromium.org/2336233006
Cr-Commit-Position: refs/heads/master@{#39451}
We used to intercept function definitions, but not declarations.
GenericNamedPropertySetterCallback now also intercepts function declarations.
For definitions, we call DeclareGlobal and then InitializeVarGlobal. For
declarations, we never call InitializeVarGlobal, thus we must check for
interceptors in DeclareGlobal.
If the semantics of a redeclaration are wrong, e.g., redeclaring a read-only
property, an exception is thrown independent of whether an interceptor is
installed. Usually, i.e., not during a declaration, we only throw if
the call is not successfully intercepted.
BUG=v8:5375
Review-Url: https://codereview.chromium.org/2334733002
Cr-Commit-Position: refs/heads/master@{#39450}
This CL implements the throw wasm opcode. This is a pre-requisite for
implementing try-catches in wasm.
BUG=
Review-Url: https://codereview.chromium.org/2339053003
Cr-Commit-Position: refs/heads/master@{#39449}
This handles the case where generating bytecode for inlining purposes
causes a stack overflow. We just abort inlining but also need to clear
pending exceptions.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-647217
BUG=chromium:647217
Review-Url: https://codereview.chromium.org/2339383002
Cr-Commit-Position: refs/heads/master@{#39448}
Port c7d7ca361d
Original commit message:
Add a notion of "invocation count" to the baseline compilers, which
increment a special slot in the TypeFeedbackVector for each invocation
of a given function (the optimized code doesn't currently collect this
information).
Use this invocation count to relativize the call counts on the call
sites within the function, so that the inlining heuristic has a view
of relative importance of a call site rather than some absolute numbers
with unclear meaning for the current function. Also apply the call site
frequency as a factor to all frequencies in the inlinee by passing this
to the graph builders so that the importance of a call site in an
inlinee is relative to the topmost optimized function.
Note that all functions that neither have literals nor need type
feedback slots will share a single invocation count cell in the
canonical empty type feedback vector, so their invocation count is
meaningless, but that doesn't matter since we only use the invocation
count to relativize call counts within the function, which we only have
if we have at least one type feedback vector (the CallIC slot).
See the design document for additional details on this change:
https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=v8:5267,v8:5372
LOG=N
Review-Url: https://codereview.chromium.org/2338413002
Cr-Commit-Position: refs/heads/master@{#39446}
The semantics of the {BailoutId} representing an OSR entry point is
different between the interpreter and the full code generator. These
semantics are hard-coded in various graph builders. We need to ensure
that the correct graph builder is chosen for OSR compilations.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-5380
BUG=v8:5380
Review-Url: https://codereview.chromium.org/2341663002
Cr-Commit-Position: refs/heads/master@{#39444}
Ignition requires that objects which will be inserted into the
constant pool are canonicalized (to enable off-thread bytecode
generation). We created a CanonicalizeHandleScope across parse/compile
however this impacts performance (~5-8% on CodeLoad).
Now we localize the CanonicalHandleScope to only the parse /
internalization and renumbering phases where objects are created which
could end up in the constant array pool. This seems to address
the performance regression.
BUG=v8:5203,chromium:634953
Review-Url: https://codereview.chromium.org/2318653002
Cr-Commit-Position: refs/heads/master@{#39443}
Reason for revert:
Regressions in telemetry benchmarks:
crbug.com/646819.
Original issue's description:
> [heap] Decouple old generation allocation limit from external memory.
>
> We check for external memory limit in Heap::ReportExternalMemoryPressure.
>
> BUG=chromium:616434
>
> Committed: https://crrev.com/672d079ccba686019fa1457c83b42c2e692ef88b
> Cr-Commit-Position: refs/heads/master@{#39374}
TBR=hpayer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:616434
Review-Url: https://codereview.chromium.org/2339033005
Cr-Commit-Position: refs/heads/master@{#39442}
When zeroing a floating point stack slot, store the zero register directly,
rather than storing zero moved to an FP register.
BUG=
Review-Url: https://codereview.chromium.org/2339943002
Cr-Commit-Position: refs/heads/master@{#39441}
This is a first implementation of inlining into graphs that have been
created using the {BytecodeGraphBuilder}. Note that inlining sticks to
graphs of the same kind, we only ever inline AstGraph into AstGraph or
BytecodeGraph into BytecodeGraph, no mixed inlining.
R=bmeurer@chromium.org,rmcilroy@chromium.org
TEST=cctest/test-run-inlining
BUG=v8:5251
Review-Url: https://codereview.chromium.org/2262033003
Cr-Commit-Position: refs/heads/master@{#39439}
Migrate the platform DatePrototype_GetField (and all wrappers) to
TurboFan.
BUG=v8:5049
Review-Url: https://codereview.chromium.org/2263533002
Cr-Commit-Position: refs/heads/master@{#39438}
Rolling v8/build to a34a5233778556481dfa869bff735fad2157f196
Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to e240fdcdb5880deb48156dbb9ccee0c28664cf88
Rolling v8/third_party/instrumented_libraries to 45f5814b1543e41ea0be54c771e3840ea52cca4a
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2347533002
Cr-Commit-Position: refs/heads/master@{#39436}
This flag has been flipped off since 52, so it is due for removal.
R=adamk@chromium.org,caitp@igalia.com
BUG=v8:3785
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng
Review-Url: https://codereview.chromium.org/2268633002
Cr-Commit-Position: refs/heads/master@{#39435}
In case of duplicate exports, always report the error for the very last
one.
(Fixed a bug.)
BUG=v8:5358,v8:1569
Review-Url: https://codereview.chromium.org/2340953002
Cr-Commit-Position: refs/heads/master@{#39434}
