- 17 Jul, 2017 14 commits
-
-
Ulan Degenbaev authored
If the incremental marker discovers more marking work and the concurrent marking tasks have already exited, then new concurrent marking tasks are scheduled to help the main thread marker. BUG=chromium:694255 Change-Id: I559af62790e6034b23a412d3308ba8b6ae3d27c9 Reviewed-on: https://chromium-review.googlesource.com/574170Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#46703}
-
Leszek Swirski authored
This reverts commit a2fcdc7c. Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126) Original change's description: > [runtime] Move profiler ticks from SFI to feedback vector > > Instead of counting profiler ticks on the shared function info (which is > shared between native contexts), count them on the feedback vector > (which is not). This allows us to continue pushing optimization > decisions off the SFI, onto the feedback vector. > > Note that a side-effect of this is that ICs don't have to walk the stack > to reset profiler ticks, as they can access the feedback vector directly > from their feedback nexus. > > Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f > Reviewed-on: https://chromium-review.googlesource.com/544888 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46411} TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8 Reviewed-on: https://chromium-review.googlesource.com/574227 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46702}
-
Georgia Kouveli authored
Some of the benchmarks were pointing to the wrong test functions. Bug: Change-Id: I6f7850feec1da61bea7b8c1ac03c00d75400f458 Reviewed-on: https://chromium-review.googlesource.com/574023Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Cr-Commit-Position: refs/heads/master@{#46701}
-
jgruber authored
Bug: v8:6000 Change-Id: I2853d44d8bcf34b28630594cc9c2782046bd4b28 Reviewed-on: https://chromium-review.googlesource.com/573900Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46700}
-
Martyn Capewell authored
Most of these functions have become unusued due to Crankshaft's removal, so delete them. Bug: Change-Id: If4724c78a0b5c7b6179b22eb4068acd95dfdd29e Reviewed-on: https://chromium-review.googlesource.com/571011Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Martyn Capewell <martyn.capewell@arm.com> Cr-Commit-Position: refs/heads/master@{#46699}
-
Clemens Hammacher authored
There are wasm tests which are supposed to fail, but they fail for the wrong reason (because blocks do not declare their type). This CL fixes this, and changes the error output to contain the expected and observed results for better debuggability. R=titzer@chromium.org Change-Id: Ibbd7883e43677a91f858575578586c9e9d1641d5 Reviewed-on: https://chromium-review.googlesource.com/571810Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46698}
-
Michael Lippautz authored
Bug: chromium:738865 Change-Id: If710b60d33eea94bff7b621910006c2d941a7670 Reviewed-on: https://chromium-review.googlesource.com/571900Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46697}
-
Jaroslav Sevcik authored
Change-Id: Ib233e9801d5deed1acde36620d033d19957319d0 Bug: v8:6604 Reviewed-on: https://chromium-review.googlesource.com/573781Reviewed-by:
-
Michael Achenbach authored
This is for infra-side: https://chromium-review.googlesource.com/c/573544 NOTRY=true Bug: chromium:726584 Change-Id: I0dbe8cf8e107ad13d284dd2347935a225261abe8 Reviewed-on: https://chromium-review.googlesource.com/573545 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46695}
-
Michael Starzinger authored
This makes the runtime rely on the {HasBytecodeArray} predicate to determine whether code generated by TurboFan was build without any deoptimization support, as opposed to {asm_function}. R=rmcilroy@chromium.org BUG=v8:6589 Change-Id: Id124bed47a5fa02d31ff8fd3eee561b2df6c9226 Reviewed-on: https://chromium-review.googlesource.com/571786Reviewed-by: -
Yang Guo authored
Objects created during bootstrapping do not need a transition tree except for elements kind transitions. R=ishell@chromium.org Bug: v8:6596 Change-Id: I237b8b2792f201336e1c9731c815095dd06bc182 Reviewed-on: https://chromium-review.googlesource.com/571750Reviewed-by:
-
Jaroslav Sevcik authored
In many cases, this is performance neutral because we can fall off the JavaScript monomorphic fast path for the hash lookup. Once we store the hash code in known fixed position, this should get much faster. Change-Id: I3bb52ee6482fe2c35b7abe70c1d0c21935c6cc1d Reviewed-on: https://chromium-review.googlesource.com/566679 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
-
Jaroslav Sevcik authored
Change-Id: Ie59254ff0790a2db70c1f620f287f8de6387ad23 Bug: v8:5717 Reviewed-on: https://chromium-review.googlesource.com/573543Reviewed-by:
-
agrieve authored
BUG=chromium:738469 Review-Url: https://codereview.chromium.org/2975133002 Cr-Commit-Position: refs/heads/master@{#46690}
-
- 15 Jul, 2017 1 commit
-
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/9cb83ca..63efa35 Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/90038ee..af47a93 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/f6f6b65..844603c TBR=machenbach@chromium.org,hablich@chromium.org Change-Id: I114ee4d225032558289521a6ec2ff5a25898d9df Reviewed-on: https://chromium-review.googlesource.com/572529Reviewed-by:
v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#46689}
-
- 14 Jul, 2017 25 commits
-
-
Wez authored
Previous Fuchsia SDK versions provide an empty header file, for convenience, but this is no longer the case. Change-Id: Ica8d23cc38664b3ebe7093606da4c669d6043c73 Reviewed-on: https://chromium-review.googlesource.com/571763Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Wez <wez@chromium.org> Cr-Commit-Position: refs/heads/master@{#46688}
-
Alexey Kozyatinskiy authored
Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
-
erikchen authored
v8 now uses the same SDK as Chromium, even when built as a standalone project. The deployment target override has no effect. Bug: chromium:740693 Change-Id: I089f74d5ad1590ff7167564f83b0110620a92ef9 Reviewed-on: https://chromium-review.googlesource.com/565887Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Erik Chen <erikchen@chromium.org> Cr-Commit-Position: refs/heads/master@{#46686}
-
Wez authored
TBR: machenbach, hablich, kozyatinskiy Change-Id: Id5cbcc1260b69a68dded46651471bd1cfa57d3a3 Reviewed-on: https://chromium-review.googlesource.com/571114Reviewed-by:
-
Ross McIlroy authored
Changes the ShouldUseFullCodegen to use the flags on the literal instead of the SharedFunctionInfo. Also moves the setting of the SFI flags based on the literal to be in the final stage of unoptimized compilation since they are no longer needed on the SFI during compilation. This is in preparation to enable shared function infos to be created after bytecode generation (to enable off-thread bytecode generation). BUG=v8:5203, v8:6409 Change-Id: I15754979a704123b56dad9e1dfd5c3bb468b85c7 Reviewed-on: https://chromium-review.googlesource.com/570249 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Caitlin Potter authored
SuspendFlags was originally used by the suspend operation to determine which field to record the bytecode offset of a suspended generator, and the value the generator was resumed with. For async generators, await operations would use a separate field, in order to preserve the previous yield input value. This was important to ensure `function.sent` continued to function correctly. As function.sent is being retired, this allows the removal of support for that. Given that this was the only real need for SuspendFlags in the first place (with other uses tacked on as a hack), this involves several other changes as well: - Modification of MacroAssembler AssertGeneratorObject. No longer accepts a SuspendFlags parameter to determine which type of check to perform. - Removal of `flags` operand from SuspendGenerator bytecode, and the GeneratorStore js-operator. - Removal of `flags` parameter from ResumeGeneratorTrampoline builtins. - Removal of Runtime functions, interpreter intrinsics and AccessBuilders associated with the [[await_input_or_debug_pos]] field in JSAsyncGeneratorObject, as this field no longer exists. - Addition of a new `Yield` AST node (subclass of Suspend) in order to prevent the need for the other SuspendFlag values. BUG=v8:5855 TBR=bmeurer@chromium.org Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487 Reviewed-on: https://chromium-review.googlesource.com/570485 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46683}
-
Ben L. Titzer authored
R=clemensh@chromium.org Bug: Change-Id: I0fb6bdba7462acd1a6f86a9a378238dcb466a9e1 Reviewed-on: https://chromium-review.googlesource.com/571012Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#46682}
-
Daniel Clifford authored
Change-Id: I2056ab047b7c3e8ab00632fa13c67a7ea779f749 Reviewed-on: https://chromium-review.googlesource.com/571811Reviewed-by:
-
Enrico Bacis authored
Returning a double from ToFloat64 could lead to problems. If value_ has the bit representation of a signaling NaN (sNaN), then returning it as double can cause the signaling bit to flip, and value_ is returned as a quiet NaN (qNaN). The usage of the Double wrapper also, makes the function ToFloat64AsInt redundant, since the Double wrapper already has the AsUint64() method, which returns an uint64_t. R=ahaas@chromium.org Change-Id: I1e627b97b2fb6110fc702fe58f2b83eb343e9ca2 Reviewed-on: https://chromium-review.googlesource.com/563215 Commit-Queue: Enrico Bacis <enricobacis@google.com> Reviewed-by:
Martyn Capewell <martyn.capewell@arm.com> Reviewed-by:
-
Clemens Hammacher authored
This is a reland of 5648aad5. Previous compile error should be fixed by disabling strict aliasing assumptions on gyp: https://chromium-review.googlesource.com/c/571806 Original change's description: > [wasm] Don't store global handles in the interpreter > > Storing global handles in the interpreter is dangerous, because the > global handles are strong roots into the heap. The interpreter itself is > referenced from the heap via a Managed. Hence the interpreter keeps the > instance alive, while the instance keeps the Managed alive. So the GC > will never collect them. > > This CL refactors this to only store the handle to the instance object > while executing in the interpreter, and clearing it when returning. > It also removes the cache of import wrappers, as it should not be > performance critical, but keeps lots of objects alive. If it turns out > to be performance critical, we will have to reintroduce such a cache > stored in the WasmDebugInfo object. > > R=titzer@chromium.org > CC=ahaas@chromium.org > > Bug: chromium:610330 > Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb > Reviewed-on: https://chromium-review.googlesource.com/567058 > Reviewed-by: Ben Titzer <titzer@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46629} TBR=titzer@chromium.org Bug: chromium:610330 Change-Id: Ic7836b1b1a044a89f2138f0c76f92acd3a1b2f2b Reviewed-on: https://chromium-review.googlesource.com/570578 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
In gn, strict aliasing is disabled anyway. Enabling it for gyp can cause the compilation to fail on bots that still use gyp, or (even worse) can lead to miscompilation because the compiler exploits strict aliasing assumptions. R=machenbach@chromium.org Bug: chromium:628560 Change-Id: Ib756b8126a10d52f8c807ceda42dfc6dbda80ea6 Reviewed-on: https://chromium-review.googlesource.com/571806Reviewed-by:
-
Ross McIlroy authored
We should never try to compile unoptimized code for a function with AsmWasm data, since it either shouldn't have been created, or should be cleared before we reach here, so remove the check. Also change the check for optimizing using bytecode to be a check on whether the function HasBytecode. BUG=v8:5203, v8:6409 Change-Id: I472b123bb370f7929555e6162af02173834d01a1 Reviewed-on: https://chromium-review.googlesource.com/569969Reviewed-by:
-
Maya Lekova authored
Bug: v8:6558, v8:6557 Change-Id: If708d21d7ac4a02470dd547837443e74f9022cd9 Reviewed-on: https://chromium-review.googlesource.com/571783Reviewed-by:
-
jgruber authored
Bug: v8:6000 Change-Id: I8c068383300ba869a87f836504c84ea08fcff87e Reviewed-on: https://chromium-review.googlesource.com/568307Reviewed-by:
-
Yang Guo authored
This is to compare the the no-snapshot build to the snapshot build when creating an isolate or context. R=jgruber@chromium.org Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I503cde560b7897b945b3f9d2b445d0abcbfb5b60 Reviewed-on: https://chromium-review.googlesource.com/571744Reviewed-by:
-
Maya Lekova authored
- Add more conformance tests for proxy call and calling undetectable - This improves the performance of calling a proxy by ~5x Bug: v8:6558, v8:6557 Change-Id: I5fe78d7ca703cfe86a2a14e39f0b6d88bb8c8e03 Reviewed-on: https://chromium-review.googlesource.com/570023Reviewed-by:
-
Michael Starzinger authored
R=bmeurer@chromium.org BUG=v8:4698 Change-Id: I8917315d913f908b1631e82357a94f2f6cf0026f Reviewed-on: https://chromium-review.googlesource.com/571781Reviewed-by:
-
Ulan Degenbaev authored
This reverts commit 20d5048a. Revert "[heap] Ensure that concurrent marking tasks exit before heap tear down." This reverts commit 387f65d4. Reason: concurrent marking tasks waiting for a signal from the main thread is susceptible to deadlocks. We should instead re-schedule concurrent marking threads once they exit. BUG=chromium:694255 Change-Id: I20db2f26b42e960f4cc04506d9598c1187b8a003 Reviewed-on: https://chromium-review.googlesource.com/571800 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Michael Starzinger authored
This fixes a refactoring bug in the AstPrinter to actually print the try-block of {TryCatchStatement} and {TryFinallyStatement} nodes. R=neis@chromium.org Change-Id: I6448251c1eed3f85100902592a76dc7d3a614334 Reviewed-on: https://chromium-review.googlesource.com/571748Reviewed-by: -
Maya Lekova authored
Bug: v8:6558, v8:6557 Change-Id: Ibda4ac02f7c8f28b6e37664c10ffae34124c79b0 Reviewed-on: https://chromium-review.googlesource.com/571703Reviewed-by:
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: Iecd5fc789b74ae8bcb4bdcb98fcf248c8bc6f6e7 Reviewed-on: https://chromium-review.googlesource.com/568478 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Georg Neis authored
The affected passes are part of OptimizeGraph which runs on a background thread, so they must not access the heap (cast has a SLOW_DCHECK that looks at the object's type). I'm also changing Handle<T>::cast to assert that it's called in a scope allowing handle dereference. R=mstarzinger@chromium.org Bug: Change-Id: Ibae1e40ec8d57481387570c658eb7cb1ae5de3b9 Reviewed-on: https://chromium-review.googlesource.com/570403Reviewed-by:
-
Caitlin Potter authored
This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
-
Michael Lippautz authored
Bug: chromium:738865 Change-Id: I663be62e73e9ba4e2f1aaededc6937d5ca1db179 Reviewed-on: https://chromium-review.googlesource.com/571780 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
The code was already there, but there was a bug in it: Because of the missing reference, we were only updating a *copy* of the signature map, hence the update had no effect. This intentially is a minimal CL, in order to allow for easy backmerging. More mitigations and tests are coming in a separate CL. R=titzer@chromium.org Change-Id: Ifb462093f4b8f4d5380b6774636537c67c2b676c Reviewed-on: https://chromium-review.googlesource.com/570278Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46664}
-
