- 17 Jul, 2017 2 commits
-
-
Jaroslav Sevcik authored
Change-Id: Ie59254ff0790a2db70c1f620f287f8de6387ad23 Bug: v8:5717 Reviewed-on: https://chromium-review.googlesource.com/573543Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#46691}
-
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 36 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:
Ross McIlroy <rmcilroy@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:
Ulan Degenbaev <ulan@chromium.org> Reviewed-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:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#46680}
-
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 Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46671}
-
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}
-
Pierre Langlois authored
The "test-disasm-arm64/DISASM_debug" test would fail on hardware because we expected a "hlt" instruction instead of "brk". The former is specific to running inside the simulator. Bug: Change-Id: I7a5a3d4c1a93d03bbf4c934037c565d27379c2b5 Reviewed-on: https://chromium-review.googlesource.com/570442Reviewed-by:
-
Yang Guo authored
This is to make debugging serialization easier by having a way to inspect the object graph. Serializer::PrintStack() can be invoked from the debugger to print the current traversal path. R=jgruber@chromium.org Change-Id: Ie67408ade7989dc559904821b3f009fdfe3e459f Reviewed-on: https://chromium-review.googlesource.com/571219Reviewed-by:
-
Ulan Degenbaev authored
BUG=chromium:694255 Change-Id: I37fc1cd98b3808df0e14f637d53adc777c391341 Reviewed-on: https://chromium-review.googlesource.com/570999Reviewed-by:
-
Michael Achenbach authored
This reverts commit b90e83f5. Reason for revert: Blocks roll: https://chromium-review.googlesource.com/c/570002/ Confirmed by: https://chromium-review.googlesource.com/c/571700/2 Original change's description: > [runtime] Add shortcuts for elements kinds transitions. > > The shortcuts ensure that field type generalization is properly > propagated in the transition graph. > > Bug: chromium:738763 > Change-Id: Id701a6f95ed6ea093c707fbe0bac228f1f856e9f > Reviewed-on: https://chromium-review.googlesource.com/567992 > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46622} TBR=jkummerow@chromium.org,ishell@chromium.org Change-Id: I5ede80db6bc209f16c6fd43f6bf3c8865c9577d8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:738763 Reviewed-on: https://chromium-review.googlesource.com/571741Reviewed-by:
-
jgruber authored
The new message lets us know which directory is involved and what we can do to fix it. Bug: Change-Id: Icfcb92b35b1ef2644649789b1e8473cb6ae50336 Reviewed-on: https://chromium-review.googlesource.com/571702Reviewed-by:
-
jgruber authored
Bug: v8:6000 Change-Id: Ia50108ebbf838e210d95cb268858394e6a66c88d Reviewed-on: https://chromium-review.googlesource.com/567990 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Juliana Franco authored
It is not clear why we need this BuildTranslation. The intent of this commit is to check if any tests fail. Bug: Change-Id: Ibc8a0914a1483138cfb6234e0fdf87acc0681408 Reviewed-on: https://chromium-review.googlesource.com/567922Reviewed-by:
-
Ulan Degenbaev authored
Currently every VirtualMemory allocation on 64-bit systems uses a random 46-bit address hint for ASLR. This leads to wired page leak on MacOS discovered by Erik Chen (see crbug.com/700928 and https://chromium-review.googlesource.com/c/557958/): "The Darwin kernel [as of macOS 10.12.5] does not clean up page directory entries [PDE] created from mmap or mach_vm_allocate, even after the region is destroyed. Using a virtual address space that is too large causes a leak of about 1 wired [can never be paged out] page per call to mmap(). The page is only reclaimed when the process is killed." This patch changes VirtualMemory to accept the hint parameter explicitly. On MacOS the hints are confined to 4GB contiguous region. Algorithm: - On startup, set heap.mmap_region_base_ to a random address. - For each mmap use heap.mmap_region_base_ + (random_offset % (4*GB)). BUG=chromium:700928 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2ae6a024e02fbe63f940105d7920b57c19abacc6 Reviewed-on: https://chromium-review.googlesource.com/558876 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
This CL inlines the following builtins into TurboFan - %MapIteratorPrototype%.next - %SetIteratorPrototype%.next following the design that we are using for Array iteration already (different instance types for the different kinds of iterators). Details can be found in the relevant design document at: https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8 The key to great performance here is to ensure that the inlined code allows escape analysis and scalar replacement of aggregates to remove the allocations for the iterator itself as well as the iterator results and potential key/value arrays in the simple case of a for-of loop (and by extension also in other constructs that reduce to for-of loops internally), i.e.: const s = new Set; // ... do something with s for (const x of s) { // ... } Here the for-of loop shouldn't perform any allocations of helper objects. Drive-by-fix: Replace the ExistsJSMapWithness in JSBuiltinReducer with a more general HasInstanceTypeWitness, similar to what's in JSCallReducer. Also migrate the {Map,Set}.prototype.size getter inlining to the JSBuiltinReducer, so that everything is in a single place. R=jgruber@chromium.org Bug: v8:6344, v8:6571, chromium:740122 Change-Id: I09cb506fe26ed3e10d7dcb2f95ec4415e639582d Reviewed-on: https://chromium-review.googlesource.com/570159Reviewed-by:
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/f64cb20..9cb83ca Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/c2827ae..5ad1454 Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/1286055..90038ee TBR=machenbach@chromium.org,hablich@chromium.org Change-Id: I8cf7fdad1eafcf43c4fc2a4d6399c634005ff0ad Reviewed-on: https://chromium-review.googlesource.com/571488Reviewed-by:
-
Sathya Gunasekaran authored
Only allow BindingIdentifier in BindingRestPattern and ValidReferenceExpression in AssignmentRestPattern. Also updated to a better, actionable error message. Bug: v8:6500, v8:6513 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ifaba2f85c20bc20e263267e8c76d50a27075b87d Reviewed-on: https://chromium-review.googlesource.com/550559 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
-
- 13 Jul, 2017 1 commit
-
-
Sathya Gunasekaran authored
TBR=bmeurer@chromium.org Bug: v8:6404 Change-Id: Ic813f885449178d10527834356c33da658e2cf06 Reviewed-on: https://chromium-review.googlesource.com/569183 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#46652}
-
