This cleanup is necessary to make HCallWithDescriptor support passing arguments on the stack.
BUG=v8:5407
Review-Url: https://codereview.chromium.org/2352163004
Cr-Commit-Position: refs/heads/master@{#39590}
Minidumps have gotten bigger stack ranges leading to long load times when using
grokdump's web interface. A major factor seems to be the output size of the
generated table. Using shorter class names and avoiding quotes for most
attributes we can get a significant size reduction.
BUG=
Review-Url: https://codereview.chromium.org/2352303002
Cr-Commit-Position: refs/heads/master@{#39589}
This removes an optimization from the code generator that tries to
materialize certain constants (i.e. context and closure) from the
stackframe when possible. This does not work with Harmony tail calls
which are split into several instructions. There have already been
numerous bugs in this optimization, it is too fragile in its current
form.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-648539
BUG=chromium:648539
Review-Url: https://codereview.chromium.org/2357583003
Cr-Commit-Position: refs/heads/master@{#39583}
After parsing a function, if there's no masking declaration in the function scope, DeclareFunctionVar will also bind the function name to a variable. It will either bind it to the const/const-legacy function_ variable, or to a dynamic non-local if the function calls sloppy eval.
Even if the variable is masked or sloppy eval is called, we still declare the function-var. The client immediately sets up the variable by assigning the resulting function to it.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2274133002
Cr-Commit-Position: refs/heads/master@{#39581}
When we added the new MachineRepresentation::kTaggedSigned and
MachineRepresentation::kTaggedPointer, we didn't extend the logic
for memory operand covering, and so for map checks and other
comparisons with fields we'd always need an additional register.
This fixes that and does reduce register pressure in some cases.
R=jarin@chromium.org
BUG=v8:5267,v8:5270
Review-Url: https://codereview.chromium.org/2354863003
Cr-Commit-Position: refs/heads/master@{#39575}
Runtime.evaluate can return result by value. We need to provide more details why method call was failed.
BUG=chromium:645640
R=dgozman@chromium.org,alph@chromium.org
Review-Url: https://codereview.chromium.org/2345263003
Cr-Commit-Position: refs/heads/master@{#39574}
- Add a new container object to store the data required for
PromiseResolveThenableJob.
- Create a new runtime function to enqueue the microtask event with
the required data.
This patches causes a 4% regression in the bluebird benchmark.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2314903004
Cr-Commit-Position: refs/heads/master@{#39571}
Rolling v8/base/trace_event/common to 199985e01e17b5a4888f83648b7cc119779e9245
Rolling v8/build to 4803815de7294778a1496c4e7f3e84ee48e243ef
Rolling v8/buildtools to 57649e5e2001ba1f5e5d45f5a838c616ea0e9cb9
Rolling v8/tools/clang to cca919b21f2436ba1585f7e9de2702ba64fbd8bf
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2360463002
Cr-Commit-Position: refs/heads/master@{#39570}
This patch gives the ability for the embedder to ask for the
module requests of a module, and to pass a ResolveCallback
into Module::Instantiate().
In d8, I've implemented a simple module_map that's used
along with this API to allow loading, compiling, instantiating,
and evaluating a whole tree of modules.
No path resolution is yet implemented, meaning that all
import paths are relative to whatever directory d8 runs
in. And no imports are linked to the exports of the
requested module.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2351113004
Cr-Commit-Position: refs/heads/master@{#39569}
This patch ensures that variables like .new_target aren't overwritable
using with scopes. It does this by ensuring that scope analysis does
not consider with scopes (or eval scopes) for such 'synthetic variables',
similarly to how the 'this' variable was already handled.
The patch also adds a DCHECK for the dynamic parallel to this case,
replacing a previous unreachable path for a particular instance.
BUG=v8:5405
Review-Url: https://codereview.chromium.org/2353623002
Cr-Commit-Position: refs/heads/master@{#39567}
This patch uses temporaries rather than unresolved variables for
.promise and .debug_is_active. For .promise, a new field is added
to the FunctionState, similarly to .generator_object. This change
fixes a bug where .promise was locally shadowable by with, affecting
program semantics.
BUG=v8:5405
Review-Url: https://codereview.chromium.org/2359513002
Cr-Commit-Position: refs/heads/master@{#39566}
To improve performance, this patch makes Promise.all and Promise.race not
perform correct catch prediction when the debugger is not open. The case
may come up if Promise.race or Promise.all is called, then DevTools is
open, then a component Promise is rejected. In this case, the user would
falsely get an exception event even if the "pause on caught exceptions"
box is unchecked. There are tests which triggered this case; however, it
seems both unlikely and and acceptable to have an event in this case.
Many analogous events are already produced when DevTools is enabled
during the operation of a program.
BUG=v8:3093
Review-Url: https://codereview.chromium.org/2350363002
Cr-Commit-Position: refs/heads/master@{#39565}
This patch knits together Promises returned by async/await such that when
one async function awaits the result of another one, catch prediction works
across the boundaries, whether the exception comes synchronously or
asynchronously. Edges are added in three places:
- When a locally uncaught await happens, if the value passed into await
is a Promise, from the awaited value to the Promise under construction
in the broader async function
- From a "throwaway" Promise, which may be found on the Promise debug
stack, to the Promise under construction in the async function that
surrounds it
- When a Promise is resolved with another Promise (e.g., when returning a
Promise from an async function)
In this reland, the caught tests are broken up into four parts to avoid
timeouts.
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2346363004
Cr-Commit-Position: refs/heads/master@{#39564}
The CreateArrayLiteral bytecode handler now directly inlines the FastCloneShallowArrayStub.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2341743003
Cr-Commit-Position: refs/heads/master@{#39562}
Fix a typo in TypeFeedbackVector::ComputeCounts, where we would not
skip the interpreter binary/compare op IC slots for fullcodegen, and
thus mess up the heuristics for tearing up.
TBR=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2353513006
Cr-Commit-Position: refs/heads/master@{#39560}
This is some initial cleanup to keep /src clean. The
AccountingAllocator is actually exclusively used by zones and this
common subfolder makes that more clear.
BUG=v8:5409
Review-Url: https://codereview.chromium.org/2344143003
Cr-Commit-Position: refs/heads/master@{#39558}
Here we only change the type of the slot set fields to atomic values and use CAS to change the state. There is no change in behavior or semantics of the slot set.
BUG=chromium:648568
Review-Url: https://codereview.chromium.org/2353553003
Cr-Commit-Position: refs/heads/master@{#39557}
Full code uses patching ICs for this feedback, and the interpreter uses
the type feedback vector. It's a good idea to code the vector slots
appropriately as ICs so that the runtime profiler can better gauge if
the function is ready for tiering up from Ignition to TurboFan.
As is, the feedback is stored in "general" slots which can't be
characterized by the runtime profiler into feedback states.
This CL addresses that problem. Note that it's also important to
carefully exclude these slots from the profiler's consideration when
determining if you want to optimize from Full code.
BUG=
Review-Url: https://codereview.chromium.org/2342853002
Cr-Commit-Position: refs/heads/master@{#39555}
- Eliminates *all* copies in the process.
- Moves (nearly) all functionality into Scanner::BookmarkScope.
- Significant code reduction.
[Needs to be rebased once crrev.com/2347883002 lands. All changes in *parser* are from that CL.]
R=marja@chromium.org
BUG=v8:4947
Review-Url: https://codereview.chromium.org/2341323002
Cr-Commit-Position: refs/heads/master@{#39554}
This makes sure generator functions are marked as optimizable for all
configurations where the BytecodeGraphBuilder is used. Note that as
usual AstNumbering is just a heuristic and the underlying compiler can
still bailout from optimization when the compilation pipeline chooses
another compiler that does not support generator functions.
R=bmeurer@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2353793003
Cr-Commit-Position: refs/heads/master@{#39553}
Due to a typo, long branches were emitted instead of short branches, and the
code would stop working at all in the situation when long branches must be
emitted. This patche fixes this issue.
TEST=mjsunit/wasm/embenchen/lua_binarytrees
BUG=
Review-Url: https://codereview.chromium.org/2351143002
Cr-Commit-Position: refs/heads/master@{#39552}
The implicit assignment to the induction variable in a ForInStatement
has been ignored by the AST loop assignment analysis. This was hidden
for cases where the parser introduced a ".for" temporary, but triggers
when the variable is declared outside the loop.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-647887
BUG=chromium:647887
Review-Url: https://codereview.chromium.org/2356733002
Cr-Commit-Position: refs/heads/master@{#39551}
This will allow to simplify the miss part of store IC handlers when we decide
to pass value/slot/vector on the stack.
BUG=v8:5407
Review-Url: https://codereview.chromium.org/2351643005
Cr-Commit-Position: refs/heads/master@{#39549}
This means we can no longer take the closure's context to parse, but
need to rely on the outer scope info.
Since it's not possible to get that, however, for lazy functions, we
introduce a new field to SharedFunctionInfo that stores the outer scope
info whenever available.
BUG=v8:5215
R=marja@chromium.org,verwaest@chromium.org,jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2358503002
Cr-Commit-Position: refs/heads/master@{#39548}
Removes some unnecessary probing in TemplateHashMapImpl, in
particular probing a second time in LookupOrInsert after the
first probe came up with an empty value.
Review-Url: https://codereview.chromium.org/2349163002
Cr-Commit-Position: refs/heads/master@{#39545}
... because the latter automatically respects the desired calling convention.
BUG=v8:5407
Review-Url: https://codereview.chromium.org/2350423002
Cr-Commit-Position: refs/heads/master@{#39543}