- 14 Jul, 2017 6 commits
-
-
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:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46658}
-
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:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> Cr-Commit-Position: refs/heads/master@{#46657}
-
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:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46656}
-
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:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#46655}
-
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:
v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#46654}
-
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:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46653}
-
- 13 Jul, 2017 34 commits
-
-
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}
-
Adam Klein authored
The tail call implementation is hidden behind the --harmony-tailcalls flag, which is off-by-default (and has been unstaged since February). It is known to be broken in a variety of cases, including clusterfuzz security issues (see sample Chromium issues below). To avoid letting the implementation bitrot further on trunk, this patch removes it. Bug: v8:4698, chromium:636914, chromium:724746 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I9cb547101456a582374fdf7b1a3f044a9ef33e5c Reviewed-on: https://chromium-review.googlesource.com/569069 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Adam Klein authored
Commit f37d7264 limited inner function parsing to function declarations, to allow function expressions to be eagerly-compiled if the parser discovered that they are immediately invoked. But it's not only declarations that won't be immediately invoked: methods and accessors are in the same boat, and should be treated the same. This patch reverses the logic to exclude function expressions from inner lazy treatment, thus making both function declarations and methods/accessors inner-lazy-parseable. Bug: v8:5501 Change-Id: I71a57667e52fcb917362ba629667c4c84ae29011 Reviewed-on: https://chromium-review.googlesource.com/569180Reviewed-by:
-
Ross McIlroy authored
We only optimize functions which are already compiled, so there is no need to ensure baseline in pipeline.cc, and since ast-graph-builder doesn't do inlining, there are no other uses. BUG=v8:5203, v8:6409 Change-Id: I830c8868d50363f61193a96d9a5774e059a1af0e Reviewed-on: https://chromium-review.googlesource.com/570033 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46649}
-
Ross McIlroy authored
These are no longer necessary since we only have one optimizing compiler. Also avoid changing --turbo-filter when --no-opt is set, and instead explicitly check both the FLAG_opt and FLAG_turbo_filter in GetOptimizedCode to check whether optimization is disabled. BUG=v8:6408 Change-Id: I0948f788e8ff111c08022270d86c22f848da300a Reviewed-on: https://chromium-review.googlesource.com/568484 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
R=ahaas@chromium.org Change-Id: Ie2e7f1c527c69ddc998d9c2437475ccea26ebb86 Reviewed-on: https://chromium-review.googlesource.com/570045 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#46647}
-
Clemens Hammacher authored
The WhichPowerOf2 function now takes arbitrary integer arguments, and hence subsumes the WhichPowerOf2_64 function. R=mstarzinger@chromium.org Change-Id: I0692a17bbbe0074425d7c330342bc6fa34fb9d5c Reviewed-on: https://chromium-review.googlesource.com/568495 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
sreten.kovacevic authored
Found issue with BuildChangeEndianness. There is difference between load and store case. Load depends primarily on MachineRepresentation, while store depends on ValueType. TEST=wasm-spec-tests/tests/endianness TEST=wasm-spec-tests/tests/memory TEST=wasm-spec-tests/tests/memory_trap Bug: Change-Id: I437f611107daad2f425a67fcc068e874822e0f58 Reviewed-on: https://chromium-review.googlesource.com/558882Reviewed-by:
-
jgruber authored
Both labeled blocks: l0: { break l0; } and blocks containing jump statements (break, return, continue) require a continuation counter to correctly display coverage. Bug: v8:6000 Change-Id: I3ae8ddd3d9f6c087622482b86014dd583b774b71 Reviewed-on: https://chromium-review.googlesource.com/568024Reviewed-by: -
Georg Neis authored
In my previous CL, I completely disabled the processing of inlining stacks when generating code comments. This CL restores the feature at least for runs without concurrent recompilation. In other words, if you use --code-comments and want to see nice source positions, you must also use --no-concurrent-recompilation. Bug: v8:6048 Change-Id: Ief7e52a4046cb74e02b1783dbace19534093c588 Reviewed-on: https://chromium-review.googlesource.com/570021 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#46643}
-
Yang Guo authored
This also makes sure 6.0 and 6.1 have the same constants exposed in v8.h. Bug: v8:6592 R=bmeurer@chromium.org Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I3afc0e5e4495594c76229555aab148ac78388f80 Reviewed-on: https://chromium-review.googlesource.com/569618 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
-
Georg Neis authored
In debug mode (SLOW_DCHECK), Handle<T>::cast accesses the object to check its type. Obviously we can no longer do that now that we run on a background thread. NOTE: I think there are other parts of TF that suffer from the same problem. I will look into fixing those as well. Bug: v8:6048, v8:6590 Change-Id: I9abfdf30f1899cdb0c8b9078b0cf71463d608251 Reviewed-on: https://chromium-review.googlesource.com/570054Reviewed-by:
-
Andreas Haas authored
This is the x64 implementation of the CL https://codereview.chromium.org/2763593002 Original message: [wasm][arm] Add an additional stack check for functions with big frames. Stack overflow checks are typically implemented as part of the TurboFan graph of a function. This means that the stack check code is executed after frame construction. When a frame is too big, though, there may not be enough space on the stack anymore to throw the stack overflow exception after frame construction. With this CL we do an additional stack check before frame construction for functions with big frames. As discussed offline with mstarzinger, I do this change currently only for WebAssembly. This CL contains only the changes for arm. I will do the other platforms in separate CLs. R=titzer@chromium.org Bug: v8:6318 Change-Id: Id4a8ea3ee76c37132e86a7c4e5d05d3bd86df44a Reviewed-on: https://chromium-review.googlesource.com/565562 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#46640}
-
Ulan Degenbaev authored
BUG=chromium:694255 Change-Id: Id874d7427b52f5c2d1d7ae72d321cad8277f8082 Reviewed-on: https://chromium-review.googlesource.com/570035 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Igor Sheludko authored
... that have computed name and/or require home object. This should give us the opportunity to implement initialization of name and home object values in a stub. Bug: v8:6459 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I47a1a2c185e120e86c793733cce737811f895291 Reviewed-on: https://chromium-review.googlesource.com/512802Reviewed-by:
Andreas Rossberg <rossberg@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46638}
-
Michael Starzinger authored
This is a reland of ec6da23b Original change's description: > [flags] Remove some dead Crankshaft flags. > > R=bmeurer@chromium.org > BUG=v8:6408 > > Change-Id: I34abbcdc2fc47df44938bac0e59f9982c935c657 > Reviewed-on: https://chromium-review.googlesource.com/569963 > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46631} Bug: v8:6408 Change-Id: I8a856e25d56e27bccb79588b2e5ee4369d7c5fe5 Reviewed-on: https://chromium-review.googlesource.com/570050Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46637}
-
Michael Lippautz authored
Bug: chromium:738865 Change-Id: Iff9a2e606559dc5587589e53c5e8060ef65f72a5 Reviewed-on: https://chromium-review.googlesource.com/570028Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46636}
-
Ross McIlroy authored
Removes the --ignition flag which is now on by default. Adds a --stress-fullcodegen flag which enables running all functions supported by fullcodegen to be compiled by fullcodegen. This will enable moving parser internalization later when we are not stressing fullcodegen or compiling asm.js functions. BUG=v8:5203, v8:6409, v8:6589 Change-Id: I7fa68016d4e734755434ec0b4e749ef65ffa7f4e Reviewed-on: https://chromium-review.googlesource.com/565569 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Daniel Ehrenberg authored
Additionally, drive-by add a test inspired by a worrying TODO in the parser. Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng,master.tryserver.v8:v8_linux64_msan_rel,v8_linux64_tsan_rel,v8_linux_arm64_dbg,v8_linux_gc_stress_dbg,v8_linux_noi18n_rel_ng,v8_linux_nosnap_rel Change-Id: I693a858a638753f8c1091f2f9086710f628b40dd Reviewed-on: https://chromium-review.googlesource.com/553677Reviewed-by:
-
Michael Lippautz authored
Bug: chromium:738865 Change-Id: I065c4e63a437daaeba8b42826f91ddd5c1b542e4 Reviewed-on: https://chromium-review.googlesource.com/570161Reviewed-by:
-
Michael Starzinger authored
This reverts commit ec6da23b. Reason for revert: Requires infrastructure changes first. Will reland after changes have happened. Original change's description: > [flags] Remove some dead Crankshaft flags. > > R=bmeurer@chromium.org > BUG=v8:6408 > > Change-Id: I34abbcdc2fc47df44938bac0e59f9982c935c657 > Reviewed-on: https://chromium-review.googlesource.com/569963 > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46631} TBR=mstarzinger@chromium.org,bmeurer@chromium.org Change-Id: Iee077911ae7d877c6a9d2edb548e3c04345b47ce No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6408 Reviewed-on: https://chromium-review.googlesource.com/570049Reviewed-by:
-
Michael Starzinger authored
R=bmeurer@chromium.org BUG=v8:6408 Change-Id: I34abbcdc2fc47df44938bac0e59f9982c935c657 Reviewed-on: https://chromium-review.googlesource.com/569963Reviewed-by:
-
Clemens Hammacher authored
This reverts commit 5648aad5. Reason for revert: Compile error on mips: https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/10732 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,clemensh@chromium.org Change-Id: Ifadfb885f937f37bb3eab4732a97f20ff40c2583 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:610330 Reviewed-on: https://chromium-review.googlesource.com/569962Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46630}
-
Clemens Hammacher authored
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/567058Reviewed-by:
-
Pierre Langlois authored
When disassembling some instructions we would print `r12`, which can be confusing when the rest of the disassembly consistently uses `ip`. Bug: Change-Id: Id4cfc5805ef102a0845cdaaa8390e618ee981b19 Reviewed-on: https://chromium-review.googlesource.com/570038Reviewed-by:
-
Clemens Hammacher authored
There is just one version now, called IsPowerOfTwo. It accepts any integral type. There is one slight semantical change: Called with kMinInt, it previously returned true, because the argument was implicitly casted to an unsigned. It's now (correctly) returning false, so I had to add special handlings of kMinInt in machine-operator-reducer before calling IsPowerOfTwo on that value. R=mlippautz@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,ishell@chromium.org,yangguo@chromium.org Change-Id: Idc112a89034cdc8c03365b778b33b1c29fefb38d Reviewed-on: https://chromium-review.googlesource.com/568140Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46627}
-
Clemens Hammacher authored
This CL changes the USE macro to accept more than one parameter. This is particularly interesting for calling a method on each type in a parameter pack, as in: template<typename... T> void foo(T&&... ts) { USE(do_something(ts)...); } Drive-by fix: Allow to pass arbitrary types to USE, including references. This might prevent a copy for pass-by-value. R=ishell@chromium.org, tebbi@chromium.org Also-by: tebbi@chromium.org Change-Id: I544e83bb996aaa638e7512295973dd3e742254bc Reviewed-on: https://chromium-review.googlesource.com/567507Reviewed-by: -
Yang Guo authored
This is for backwards ABI compatibility to version 6.0. R=bmeurer@chromium.org Bug: v8:6592 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I20f3fa79324511c6e393ddaad50880f22ef6df77 Reviewed-on: https://chromium-review.googlesource.com/569758Reviewed-by:
-
Clemens Hammacher authored
It's ok that the instance of the called code object is different from the caller instance. This happens if one instance calls an exported function of another instance. R=ahaas@chromium.org Bug: chromium:739768 Change-Id: I6afa8332a9b33fe32e9332cdca573053f058421d Reviewed-on: https://chromium-review.googlesource.com/568494Reviewed-by:
-
Clemens Hammacher authored
It used to be module-relative, but since we switched to decoding sections individually, the offsets would be section-relative. This CL fixes this by adding the buffer offset to the reported locations. R=ahaas@chromium.org Change-Id: I27240832e5cbd625d6b952678503252017dd83f3 Reviewed-on: https://chromium-review.googlesource.com/568488 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Igor Sheludko authored
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:
-
Clemens Hammacher authored
The DCHECK is supposed to check that the read in the next line does not read out of bounds. Hence we have to use {pc} and not {pc_}. I accidentally triggered this while writing an unrelated test case, but now fail to reproduce. R=ahaas@chromium.org Change-Id: Ia3fa9a9874866dc14180b22b9af526459fbda495 Reviewed-on: https://chromium-review.googlesource.com/568487Reviewed-by: -
Michael Starzinger authored
This correctly types values loaded via {LoadElement} nodes from arrays of HOLEY_DOUBLE_ELEMENTS elements kind as {Type::NumberOrHole}. Even though "the hole" is still encoded as a tagged NaN, the type system still needs to consider it as a potential hole value. R=bmeurer@chromium.org TEST=mjsunit/regress/regress-crbug-736575 BUG=chromium:736575 Change-Id: Ib869284900a4affb2ddaa1d2a96df9443dba6921 Reviewed-on: https://chromium-review.googlesource.com/567180Reviewed-by: -
Andreas Haas authored
The instruction sequence consumes a significant amount of memory, so it should be deallocated as early as possible. This CL separates the zone which is used by the code generator from the zone which is used by the instruction selector. Thereby we can delete the instruction selector zone, which contains the instruction sequence, already after AssembleCode, and not only after FinalizeCode. For WebAssembly this means that the instruction sequence gets deleted on the background tasks already and does not stay alive until the main threads deletes it. R=bmeurer@chromium.org, neis@chromium.org CC=mtrofin@chromium.org Change-Id: I090a2140ca05ae3bcc66268b0eddb08846fea690 Reviewed-on: https://chromium-review.googlesource.com/566831 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Reviewed-by:
-
