- 12 Oct, 2017 14 commits
-
-
Igor Sheludko authored
Bug: chromium:764219 Change-Id: I99d1192c5c0f2b8bf47e0f193a0c4d9c00477466 Reviewed-on: https://chromium-review.googlesource.com/712454 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#48492}
-
Pierre Langlois authored
When an immediate does not fit an add instruction we use a temporary register to hold the value, using movw/movt to encode it. However, in order to remove a use of r9 in TurboFan's code generator, we need to cope with no scratch registers being available. That is to say that the destination and source registers are the same, and `ip` is not available to use. In this case, we can split an add instruction into a sequence of additions: ``` UseScratchRegisterScope temps(...); Register my_scratch = temps.Acquire(); __ add(r0, r0, Operand(0xabcd); // add r0, r0, #0xcd // add r0, r0, #0xab00 ``` As a drive-by fix, make the disassembler test fail if we expected a different number of instructions generated. Bug: v8:6553 Change-Id: Ib7fcc765d28bccafe39257f47cd73f922c5873bf Reviewed-on: https://chromium-review.googlesource.com/685014Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#48491}
-
Clemens Hammacher authored
The VALIDATE macro should only be used for tests that do not have any side effect, because the side effect will only be executed if validation is active or in debug builds (because the condition is DCHECKed there). The TypeCheckBreak method has side effects since a while, since it inserts unreachable values on the stack. This did not lead to failures so far, since we only have validating users of the WasmFullDecoder. This will change once we have general lazy compilation of wasm modules, e.g. for tier-up. R=titzer@chromium.org Change-Id: I7b34dfd9297122616fa9ebdf899d9f44ca60273b Reviewed-on: https://chromium-review.googlesource.com/715416 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48490}
-
Clemens Hammacher authored
R=titzer@chromium.org Change-Id: I26261e16a9db2b4b9622b1d4a3eab959fa24b7e3 Reviewed-on: https://chromium-review.googlesource.com/713496Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48489}
-
Georg Neis authored
R=jkummerow@chromium.org Bug: v8:6791 Change-Id: Id050eb583af2977e27a91f6ff9ab82c72df0ca2e Reviewed-on: https://chromium-review.googlesource.com/711849Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#48488}
-
Georg Neis authored
R=jkummerow@chromium.org Bug: v8:6791 Change-Id: Id499a47cbb545c7ba4bffd1c1935846be6025b5e Reviewed-on: https://chromium-review.googlesource.com/712255 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#48487}
-
Georg Neis authored
Also add tests for Object::SameValue. R=jkummerow@chromium.org Bug: v8:6791 Change-Id: I0611044dcfee4c6ba836629cf82d1589135e4ab0 Reviewed-on: https://chromium-review.googlesource.com/712034Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#48486}
-
Georg Neis authored
R=jkummerow@chromium.org Bug: v8:6791 Change-Id: I7e99a8aa2aa65e78a8d4288f496d496600063bfe Reviewed-on: https://chromium-review.googlesource.com/712534 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#48485}
-
Ulan Degenbaev authored
Bug: Change-Id: I9e4b2e1157f36dacb24f7a0d0c43d31c84de8488 Reviewed-on: https://chromium-review.googlesource.com/712397Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#48484}
-
Jungshik Shin authored
- remove unused Runtime_GetLanguageTagVariants - add test for another related bug (chromium:770452) as well as for chromium:770450 . Bug: chromium:770450, chromium:770452 Test: intl/general/invalid-locale.js Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I4496a4a5421000faa0e37aed85fea21ceb487998 Reviewed-on: https://chromium-review.googlesource.com/710816Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Jungshik Shin <jshin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48483}
-
Benedikt Meurer authored
This reverts commit 4cf47645. Reason for revert: Broken effect chains detected by Clusterfuzz. Playing it safe for the 63 branch. Original change's description: > Reland^3 "[turbofan] eagerly prune None types and deadness from the graph" > > This fixes the issues > https://bugs.chromium.org/p/chromium/issues/detail?id=772873 > and https://bugs.chromium.org/p/chromium/issues/detail?id=772872. > > One problem was that mutating an effect node into Unreachable confused > the LoadElimination sidetables, so I just always create a new node now. > > The other problem was that UpdateBlockControl() was executed after > UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input. > So now I make sure that UpdateEffectPhi() is always executed last. > > This is a reland of 6ddb5e7d > Original change's description: > > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph" > > > > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the > > graph end. This fixes issues with later phases running DeadCodeElimination and > > introducing new DeadValue nodes when processing uses of Unreachable. > > > > This is a reland of 3c4bc27f > > Original change's description: > > > Reland "[turbofan] eagerly prune None types and deadness from the graph" > > > > > > This is a reland of e1cdda25 > > > Original change's description: > > > > [turbofan] eagerly prune None types and deadness from the graph > > > > > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that > > > > depend on them, we introduce a {DeadValue} node representing an impossible value > > > > that can occur at any position in the graph. The extended {DeadCodeElimination} > > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > > > > the effect chain when possible. The remaining uses of {DeadValue} are handled > > > > in {EffectControlLinearizer}, where we always have access to the effect chain. > > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > > > > of a node with type {None} as dead. > > > > > > > > Bug: chromium:741225 > > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > > > > Reviewed-on: https://chromium-review.googlesource.com/641250 > > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > > Cr-Commit-Position: refs/heads/master@{#48208} > > > > > > Bug: chromium:741225 > > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 > > > Reviewed-on: https://chromium-review.googlesource.com/692034 > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#48232} > > > > Bug: chromium:741225 > > Change-Id: I5702ec34856c075717162153adc765774453c45f > > Reviewed-on: https://chromium-review.googlesource.com/702264 > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48366} > > Bug: chromium:741225 > Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f > Reviewed-on: https://chromium-review.googlesource.com/709214 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48469} TBR=jarin@chromium.org,tebbi@chromium.org Change-Id: Icf6a6af4feaafd4bde28cb7b996735ff91bb3810 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:741225 Reviewed-on: https://chromium-review.googlesource.com/715096Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48482}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/adaf9e5..ddb142b Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/a48a6af..072921b Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/08cb956..21d33b1 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/b3169f9..0c09c7a Rolling v8/tools/luci-go: https://chromium.googlesource.com/chromium/src/tools/luci-go/+log/9f54aa9..45a8a51 TBR=machenbach@chromium.org,hablich@chromium.org Change-Id: I7796e40539570a9eca5dbca27d4cb69dbe62e5b3 Reviewed-on: https://chromium-review.googlesource.com/714698Reviewed-by: v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#48481}
-
Jaroslav Sevcik authored
In the current implementation of hash code for objects (identity hash), we do not bother to shift the hash when we retrieve it from the hash-length bitfield in a property array. (Even worse, we store shifted value even if we do not have property array or inside dictionaries.) That means that the hash-code for objects is always divisible by 1024. Since our hash table uses a simple masking with (2^logsize - 1) to obtain the bucket, we get terrible hash collisions - essentially, our hash table degenerates to a linked list for fewer than 1024 elements. This CL always shifts the hash code so that the value in the lowest 21 bits is uniformly distributed. This results in big improvements on medium to large hash tables. A program storing 1M elements into a WeakMap gets roughly 17x faster. A program retrieving 1M elements from a Map improves even more dramatically (>100x). const a = []; for (let i = 0; i < 1e6; i++) a[i] = {}; const m = new Map(); console.time("Map.set"); for (let i = 0; i < 1e6; i++) { m.set(a[i], i); } console.timeEnd("Map.set"); console.time("Map.get"); let s = 0; for (let i = 0; i < 1e6; i++) { s += m.get(a[i]); } console.timeEnd("Map.get"); const w = new WeakMap(); console.time("WeakMap.set"); for (let i = 0; i < 1e6; i++) { w.set(a[i], i); } console.timeEnd("WeakMap.set"); Before the fix: Map.set: 157.575000 Map.get: 28333.182000 WeakMap.set: 6923.826000 After the fix: Map.set: 178.382000 Map.get: 185.930000 WeakMap.set: 409.529000 Note that Map does not suffer from the hash collision on insertion because it uses chaining (insertion into linked list is fast regardless of size!), and we cleverly avoid lookup in the hash table on update if the key does not have identity hash yet. This is in contrast to the WeakMap, which uses open-addressing, and deals with collisions on insertion. Bug: v8:6916 Change-Id: Ic5497bd4501e3b767b3f4acb7efb4784cbb3a2e4 Reviewed-on: https://chromium-review.googlesource.com/713616Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48480}
-
Jakob Kummerow authored
and add the implementations for BitwiseNot, Increment, Decrement. This CL teaches the respective bytecode handlers about BigInts, and collects kBigInt type feedback for them (which TF discards for now, substituting "any"). Bug: v8:6791 Change-Id: I4e802b301b9702d8270bda400edd7e885e6b11b9 Reviewed-on: https://chromium-review.googlesource.com/706101 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48479}
-
- 11 Oct, 2017 26 commits
-
-
Jungshik Shin authored
This reverts commit d9a25842. Reason for revert: I'm reverting this CL for a few reasons. #2 is the most significant and I should have thought of that before making a switch. Sorry for that. 1) perf-regression: http://crbug.com/769706 2) http://crbug.com/612010 : ICU timezone update is not propagated to zygote process so that new tabs will hold on to an old timezone even after a timezone change on Linux and Chrome OS. 3) http://crbug.com/754053 : OS timezone detection issues on macOS 10.13, Ubutu 16, RHEL 7, SuSe Linux 12 or newer. ; it's being fixed. So, it actually ok. 4) http://crbug.com/771868 : timezone wrong in gmail: If it's due to #3, we're fine because it's fixed. If not, we need to look more. Original change's description: > Enable icu-timezone-data by default > > This will introduce a new behavior on POSIX(-like) platforms. Timezone > names inside parentheses after GMT offset will not be 3-4 letter > abbreviation any longer. They'll be human-readable names in the current > default locale. This matches the current Windows behavior. > > new Date(2017, 5, 22).toString() > new Date(2017, 11, 22).toString() > > Current: > > Thu Jun 22 2017 00:00:00 GMT-0700 (PDT) > Fri Dec 22 2017 00:00:00 GMT-0800 (PST) > > New in en-US locale: > > Thu Jun 22 2017 00:00:00 GMT-0700 (Pacific Daylight Time) > Fri Dec 22 2017 00:00:00 GMT-0800 (Pacific Standard Time) > > New in German locale: > > Thu Jun 22 2017 00:00:00 GMT-0700 (Nordamerikanische Westküsten-Sommerzeit) > Fri Dec 22 2017 00:00:00 GMT-0800 (Nordamerikanische Westküsten-Normalzeit) > > BUG=v8:6031, v8:2137, v8:6076 > TEST=mjsunit/icu-date-lord-howe.js, mjsunit/icu-date-to-string.js > > Change-Id: I4e7fd8b3ddae5c7779e220c4c101e45904fcdc01 > Reviewed-on: https://chromium-review.googlesource.com/625164 > Commit-Queue: Jungshik Shin <jshin@chromium.org> > Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47953} TBR=adamk@chromium.org,littledan@chromium.org,jshin@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:6031, v8:2137, v8:6076, chromium:769706, chromium:612010, chromium:771868 Change-Id: I60d75467ee21975d3a235344b01c0d2d44a7da96 Reviewed-on: https://chromium-review.googlesource.com/713404Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Jungshik Shin <jshin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48478}
-
Alexey Kozyatinskiy authored
This roll includes: - [inspector_protocol] fixed compatibility with latest jinja 2.9.6 - [inspector_protocol] removed unused variable - Follow up on alph's review comments. - Provide default escape implementation for latin and wide strings. - Allow escaping utf8 strings in embedders that operate std::string. - Upload inspector_protocol changes to Gerrit by default - [inspector_protocol] Fix building with non-ASCII paths - [inspector_protocol] added StringUtil::toDouble method as requirement - Add const char* overloads to ErrorSupport BUG=chromium:743313 R=dgozman@chromium.org Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ic81a62c638bf592ae65c84055d53d926e50715ac Reviewed-on: https://chromium-review.googlesource.com/713538Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#48477}
-
John Barboza authored
Port fc413158 Original Commit Message: ObjectTriple isn't used since f1ec44e2. Delete it, and simplify CEntryStub on all backends. R=martyn.capewell@arm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I4897783bb848e016d93731585e6891033fa4d4cf Reviewed-on: https://chromium-review.googlesource.com/714022Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#48476}
-
Aseem Garg authored
This CL adds an uma stat to track the throughput of lazy compilation for wasm functions in KB/s. BUG=chromium:770618 R=kschimpf@chromium.org,bradnelson@chromium.org,isherman@chromium.org Change-Id: Iad06cfb1f185f7e2ab6b0198282c03c3d8f29e2e Reviewed-on: https://chromium-review.googlesource.com/706276 Commit-Queue: Aseem Garg <aseemgarg@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Brad Nelson <bradnelson@chromium.org> Cr-Commit-Position: refs/heads/master@{#48475}
-
Eric Holk (eholk) authored
This is a reland of cc237d87 Original change's description: > Reland "[wasm] trap handlers: fall back on old signal handler" > > This is a reland of ee4fe896 > Original change's description: > > [wasm] trap handlers: fall back on old signal handler > > > > This is primarily needed to test D8 under ASan. ASan installs a signal handler > > early in the process startup to show stack traces from crashes. We need to make > > sure that if V8 does not handle a signal then the existing handler gets a > > chance. > > > > This change only applies when using V8's default signal handler. When > > integrating with the embedder's signal handler the behavior is unchanged. > > > > Bug: chromium:771948 > > Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe > > Reviewed-on: https://chromium-review.googlesource.com/705823 > > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> > > Commit-Queue: Eric Holk <eholk@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48429} > > Bug: chromium:771948 > Change-Id: Ide307091c432fd933c48f89c51851b8dce44dd30 > Reviewed-on: https://chromium-review.googlesource.com/710114 > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> > Commit-Queue: Eric Holk <eholk@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48435} Bug: chromium:771948 Change-Id: I781dfe356a728760090b6ccfa58212096e8f20c8 Reviewed-on: https://chromium-review.googlesource.com/713956Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48474}
-
John Barboza authored
Port 193dcf76 Original Commit Message: Pair some stack ops so that they deal with an even numbers of registers, add padding around profile entry calls, and delete some unused macro assembler code. R=martyn.capewell@arm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I017ccc699839b04bc7295d00c45e315f7cf074c1 Reviewed-on: https://chromium-review.googlesource.com/713996Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Reviewed-by: Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#48473}
-
Wez authored
There are currently no decisions based on the CPU implementor, variant or part values for ARM64, and the code to fetch those values was not compatible with Fuchsia/ARM64. Bug: chromium:772031 Change-Id: I2305fc7a97d8c0a24bb0ad115447665976e5814a Reviewed-on: https://chromium-review.googlesource.com/706642Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Rodolph Perfetta <rodolph.perfetta@arm.com> Commit-Queue: Wez <wez@chromium.org> Cr-Commit-Position: refs/heads/master@{#48472}
-
Jakob Kummerow authored
This CL teaches the respective bytecode handlers and standalone stubs about BigInts, and collects "kBigInt" type feedback for them. Just like for other binary ops, that feedback is converted to "any" for TurboFan for now. Bug: v8:6791 Change-Id: I0709cc77dc248dad506207c7b35b63c80b1ef96a Reviewed-on: https://chromium-review.googlesource.com/699424Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#48471}
-
Leszek Swirski authored
AST printing was printing the literal of the ParseInfo, which is the current function being parsed. However, for eager compilation of inner literals, this may not be the function being compiled, which is in the CompilationInfo. So, for --print-ast, we have to get the FunctionLiteral from CompilationInfo. Bug: chromium:771653 Change-Id: I2088e1f1f7b8a3d664aae65cab699a641e5fd302 Reviewed-on: https://chromium-review.googlesource.com/712354Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#48470}
-
Tobias Tebbi authored
This fixes the issues https://bugs.chromium.org/p/chromium/issues/detail?id=772873 and https://bugs.chromium.org/p/chromium/issues/detail?id=772872. One problem was that mutating an effect node into Unreachable confused the LoadElimination sidetables, so I just always create a new node now. The other problem was that UpdateBlockControl() was executed after UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input. So now I make sure that UpdateEffectPhi() is always executed last. This is a reland of 6ddb5e7d Original change's description: > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph" > > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the > graph end. This fixes issues with later phases running DeadCodeElimination and > introducing new DeadValue nodes when processing uses of Unreachable. > > This is a reland of 3c4bc27f > Original change's description: > > Reland "[turbofan] eagerly prune None types and deadness from the graph" > > > > This is a reland of e1cdda25 > > Original change's description: > > > [turbofan] eagerly prune None types and deadness from the graph > > > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that > > > depend on them, we introduce a {DeadValue} node representing an impossible value > > > that can occur at any position in the graph. The extended {DeadCodeElimination} > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > > > the effect chain when possible. The remaining uses of {DeadValue} are handled > > > in {EffectControlLinearizer}, where we always have access to the effect chain. > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > > > of a node with type {None} as dead. > > > > > > Bug: chromium:741225 > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > > > Reviewed-on: https://chromium-review.googlesource.com/641250 > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#48208} > > > > Bug: chromium:741225 > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 > > Reviewed-on: https://chromium-review.googlesource.com/692034 > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48232} > > Bug: chromium:741225 > Change-Id: I5702ec34856c075717162153adc765774453c45f > Reviewed-on: https://chromium-review.googlesource.com/702264 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48366} Bug: chromium:741225 Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f Reviewed-on: https://chromium-review.googlesource.com/709214 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48469}
-
Jan Krems authored
This is a reland of ed6f00fb Original change's description: > [modules] Implement import.meta proposal > > Rewrites references to import.meta to a new GetImportMetaObject runtime > call. Embedders can define a callback for creating the meta object using > v8::Isolate::SetHostGetImportMetaObjectCallback. If no callback has been > provided, an empty object with null prototype is created. > > This adds an example implementation to d8 that sets meta.url. > > Bug: v8:6693 > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng > Change-Id: I6871eec79da45bba81bbbc84b1ffff48534c368d > Reviewed-on: https://chromium-review.googlesource.com/707902 > Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48433} TBR=adamk@chromium.org Bug: v8:6693 Change-Id: Ie2d746ad996a56ed6ff50b832f320fe44e02f231 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Reviewed-on: https://chromium-review.googlesource.com/712834Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#48468}
-
Michael Achenbach authored
Bug: v8:6917 Change-Id: I3889cd0d059c3473a7b83eb298734a7a6a8a1de5 Reviewed-on: https://chromium-review.googlesource.com/712175Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48467}
-
Eric Holk authored
This reverts commit b0ced926. Reason for revert: Build breakage - https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/20832 Original change's description: > Track committed array buffer size rather than allocation length > > WebAssembly creates ArrayBuffers with large allocations where only a small > amount is committed. The uncommitted address space should not be counted as used > memory. Doing so can lead to the GC spending unnecessary time collecting memory > when there is not really pressure. > > Bug: > Change-Id: Ife7b84e9858e87faabc360a61f887b2fda6d99db > Reviewed-on: https://chromium-review.googlesource.com/710227 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Eric Holk <eholk@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48462} TBR=mlippautz@chromium.org,eholk@chromium.org Change-Id: Ib7b28a7bbc8ffc11e0bf8c4bb16b2da61cbdbd5f No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/712835Reviewed-by: Eric Holk <eholk@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48466}
-
Georgia Kouveli authored
Adds some necessary padding to ensure the frame is 16-byte aligned. We don't yet consider the bailout state, which will be handled separately. This patch also improves the code generated for ContinueTo*Builtin* stubs. Finally, it adds a test that checks the return value for Array.map in the case where a LAZY deopt results in a topmost builtin continuation frame - this is easy to break if the padding for the result is done incorrectly in NotifyBuiltinContinuation, but was not detected by existing tests. Bug: v8:6644 Change-Id: Id1a294950cdf535e2bfdb0ed27c67f077ec34f8a Reviewed-on: https://chromium-review.googlesource.com/704835 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48465}
-
Clemens Hammacher authored
Instead of using the size of the whole code object, just use the size of the instructions, because only there faults can happen. R=eholk@chromium.org Bug: v8:5277 Change-Id: Ia5768891ec3c1ee5ad8affc9486e044d79e23146 Reviewed-on: https://chromium-review.googlesource.com/712536Reviewed-by: Eric Holk <eholk@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48464}
-
Andreas Rossberg authored
Only change over original: Init sig_index to 0 at function-body-decoder-impl.h:168, to make MSAN happy on error path. R=titzer@chromium.org Change-Id: I9ac17215360523b656b10d2466201001b65992c0 Reviewed-on: https://chromium-review.googlesource.com/712655Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Andreas Rossberg <rossberg@chromium.org> Cr-Commit-Position: refs/heads/master@{#48463}
-
Eric Holk authored
WebAssembly creates ArrayBuffers with large allocations where only a small amount is committed. The uncommitted address space should not be counted as used memory. Doing so can lead to the GC spending unnecessary time collecting memory when there is not really pressure. Bug: Change-Id: Ife7b84e9858e87faabc360a61f887b2fda6d99db Reviewed-on: https://chromium-review.googlesource.com/710227Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48462}
-
Michael Achenbach authored
Prepared by: https://chromium-review.googlesource.com/c/chromium/tools/build/+/712036 Bug: chromium:772804 Change-Id: Ib6ace7510962e5f00008c2f2c5f87f339363d995 Reviewed-on: https://chromium-review.googlesource.com/708258Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48461}
-
Michael Achenbach authored
Currently it's hard to reason about the hung tests on worker processes. This adds simple output when we're trying to kill a hung process. Change-Id: Iae5e14dac70a8149c074043dd00cbf10e4d5f3de Reviewed-on: https://chromium-review.googlesource.com/712455Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48460}
-
Pierre Langlois authored
This patch is a first step towards target independent tests for the CodeGenerator's AssembleMove and AssembleSwap methods. The tests on top of which this builds would only make sure that no assertions were triggered while generating moves, and that the hardware is happy executing them. We want to do more and check that the generated code performs correctly. In a nutshell, this introduces a facility that can do the following: - Setup an environment with registers and stack slots initialised with random values. - Perform a list of randomly generated moves and/or swaps on those. - Return the resulting environment. This is a first step and therefore is lacking a few things which will be implemented as follow-ups: - Support for kSimd128 moves and swaps. - Support large offsets for stack moves, as well as positive and negative. - Compare the resulting environment against the result of a reference simulation. For more background information, see this design document: https://docs.google.com/document/d/1KpioxCmtiB_9RaPaRidZPVtKlZ2BaNKGPYUjKFihhK0 Bug: v8:6848 Change-Id: Ie7dc837f4444df010ab58c64b722d40ee5d2af72 Reviewed-on: https://chromium-review.googlesource.com/677398Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#48459}
-
Ulan Degenbaev authored
The optimization keeps dying maps alive for several GCs to mitigate code deoptimization with weak maps. This patch disables the optimization to see if it still needed. Bug: Change-Id: Ie5717967ad56858e6ae546c90fde73e8d5bcc4ec Reviewed-on: https://chromium-review.googlesource.com/712598Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#48458}
-
Ben L. Titzer authored
R=clemensh@chromium.org Bug: Change-Id: I54e4d02cd5665d3ba3fd2e91da05599a915c0317 Reviewed-on: https://chromium-review.googlesource.com/712654Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48457}
-
Michael Lippautz authored
Bug: Change-Id: Id3373279f2d985f7899cf893c1f63692b97166b7 Reviewed-on: https://chromium-review.googlesource.com/704655 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#48456}
-
Michael Achenbach authored
This reverts commit e44fdc70. Reason for revert: Breaks msan: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/17482 Original change's description: > [wasm] [multival] Allow function types as block types > > Changes the binary encoding of multi-return blocks to contain a function type index instead of a vector of value types. > > Cf. https://github.com/WebAssembly/multi-value/blob/master/proposals/multi-value/Overview.md#binary-format > > Bug: v8:6672 > Change-Id: I506d9323bfd6dba1e7a24c8590bcf5a08b68c433 > Reviewed-on: https://chromium-review.googlesource.com/599807 > Reviewed-by: Ben Titzer <titzer@chromium.org> > Commit-Queue: Andreas Rossberg <rossberg@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48453} TBR=titzer@chromium.org,rossberg@chromium.org Change-Id: Ia711d16ec6bd1c0731a96d38b8661f05be71f64b No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6672 Reviewed-on: https://chromium-review.googlesource.com/712634Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48455}
-
Ulan Degenbaev authored
The concurrent marker visits arrays with fast SMI elements because they have the same visitor id as arrays with tagged elements. Visiting concurrently with memmove can be unsafe depending on memmove implementation. Bug: chromium:694255 Change-Id: Ic6c2cae8761e5b1b042e4274d4f90ac59f32d91f Reviewed-on: https://chromium-review.googlesource.com/712158 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#48454}
-
Andreas Rossberg authored
Changes the binary encoding of multi-return blocks to contain a function type index instead of a vector of value types. Cf. https://github.com/WebAssembly/multi-value/blob/master/proposals/multi-value/Overview.md#binary-format Bug: v8:6672 Change-Id: I506d9323bfd6dba1e7a24c8590bcf5a08b68c433 Reviewed-on: https://chromium-review.googlesource.com/599807Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Andreas Rossberg <rossberg@chromium.org> Cr-Commit-Position: refs/heads/master@{#48453}
-