- 09 Oct, 2018 11 commits
-
-
Sigurd Schneider authored
R=jarin@chromium.org Change-Id: Ib4dd0135e7ade3bbe5dd89ae8d2915ca6707f015 Bug: v8:6666 Reviewed-on: https://chromium-review.googlesource.com/c/1264275Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#56470}
-
Toon Verwaest authored
This will avoid queueing the error for any valid-syntax JS, whereas currently we'll queue it for any assignment expression that doesn't look like the start of an arrow function. The final error will look the same even if we delay queueing it. Since the formals weren't parenthesized we won't actually throw the queued error, but the tracked "binding pattern error". Change-Id: I80e9d8ef4fb8244829c274a7d656637080583769 Reviewed-on: https://chromium-review.googlesource.com/c/1270583Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#56469}
-
Toon Verwaest authored
This flag has been on by default for some time. Once https://chromium-review.googlesource.com/c/v8/v8/+/1270578 lands we need it to be able to find duplicate parameters (to be spec-compliant). Change-Id: I222023d7cd955127d3ecca42283b37063e962c58 Reviewed-on: https://chromium-review.googlesource.com/c/1270581 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Toon Verwaest authored
Now duplicate parameter detection depends on tracking of unresolved references. This also fixes finding duplicate parameters of arrow functions nested in other arrow functions. Change-Id: I644bfdc513244637345c1069e5c7e5fde713da63 Reviewed-on: https://chromium-review.googlesource.com/c/1270578 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Igor Sheludko authored
... by removing entries corresponding to read only roots (which are immortal immovable by definition) and using READ_ONLY_ROOT_LIST explicitly. This CL also renames the list to MUTABLE_IMMORTAL_IMMOVABLE_ROOT_LIST and moves Heap::RootIsImmortalImmovable() to RootsTable::IsImmortalImmovable(). Bug: v8:8238 Change-Id: I3e44a06d7a816955bc3471e788e883fb053b03d9 Reviewed-on: https://chromium-review.googlesource.com/c/1269035Reviewed-by:
Dan Elphick <delphick@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#56466}
-
Michael Achenbach authored
The regexp for finding resources to be pushed to Android devices was too lax. On empty strings it tried to check for more resources on a directory and hung. The last test262 roll contains tests with empty imports that started hanging in this way. TBR=neis@chromium.org NOTRY=true Bug: v8:7834 Change-Id: Ie58f1b18bdd99b7b40c1fb39b25e2f481932e0f3 Reviewed-on: https://chromium-review.googlesource.com/c/1270579Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#56465}
-
Michael Achenbach authored
This reverts commit 1dbcc78e. Reason for revert: Timeout has different reason. Test driver hangs. Original change's description: > [test] Bump shards after test262 roll > > TBR=sergiyb@chromium.org > NOTRY=true > > Bug: v8:7834 > Change-Id: Ibd4e57034d493a5cc1a28049e0db0e4bb9c8f996 > Reviewed-on: https://chromium-review.googlesource.com/c/1270576 > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56462} TBR=machenbach@chromium.org,sergiyb@chromium.org Change-Id: Ic81edff220ee375f21ecd3f2ac1c2e0eeaf53878 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7834 Reviewed-on: https://chromium-review.googlesource.com/c/1270577Reviewed-by:
-
Jaroslav Sevcik authored
This addresses bunch of problems introduced by the attempt to remove indexing by function names https://chromium-review.googlesource.com/c/1267496. Now I tested with the right version of the file :-) Change-Id: Idfc8a17a0890d0453d14b949388c34c36a0b64f5 Reviewed-on: https://chromium-review.googlesource.com/c/1270575Reviewed-by:
-
Michael Achenbach authored
TBR=sergiyb@chromium.org NOTRY=true Bug: v8:7834 Change-Id: Ibd4e57034d493a5cc1a28049e0db0e4bb9c8f996 Reviewed-on: https://chromium-review.googlesource.com/c/1270576Reviewed-by:
-
Jaroslav Sevcik authored
Change-Id: I588ada3eb4d47ce36fa84e1e2fd5014346c69dca Bug: chromium:866847 Reviewed-on: https://chromium-review.googlesource.com/c/1268215 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/63f397a..a7674ea Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/4fc4281..9ec8468 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I3df962f67c1264ec4642e9d43a62fafdcb1402cf Reviewed-on: https://chromium-review.googlesource.com/c/1270262Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#56460}
-
- 08 Oct, 2018 29 commits
-
-
Frank Tang authored
Also move some code from separated function into JSDateTimeFormat::Initialize as suggested in review of previous CL. Bug: v8:8066 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I6be61482759aa54890e8f9d86483436a1abcde87 Reviewed-on: https://chromium-review.googlesource.com/c/1252882 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#56459}
-
Sathya Gunasekaran authored
Fix spec non compliance by only trimming the unicode locales and not all extensions. Remove regexp and just use straightforward string manipulation. Bug: v8:5751 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ie95828a8f62834daf8cde189f408e95a14e796fe Reviewed-on: https://chromium-review.googlesource.com/c/1255556 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#56458}
-
Frank Tang authored
Bug: v8:8259 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I52e1f23453cb9c0010645b7b71b09d0643765d28 Reviewed-on: https://chromium-review.googlesource.com/c/1269042Reviewed-by:
-
Frank Tang authored
Move strings in heap-symbols.h that only used inside V8_INTL_SUPPORT under INTERNALIZED_STRING_LIST_GENERATOR_INTL so non intl users won't use unnecessary memory. Also avoid two NewStringFromStaticChars calls for string already defined in heap-symbols.h. Bug: v8:8256 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I65dbc34639064d6d4c7d1786405b8b3af666bc2a Reviewed-on: https://chromium-review.googlesource.com/c/1268761Reviewed-by:
-
Sathya Gunasekaran authored
As per https://unicode-org.atlassian.net/browse/ICU-20009?focusedCommentId=62380&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-62380 we can just use DateFormat::GetAvailableLocales for RelativeTimeFormat removing a lot of code. This patch also cleans up the code to be in line with the rest of V8. Bug: v8:5751 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I8df5b0e5a9a05c426aaa4f7fb9c67d7947301478 Reviewed-on: https://chromium-review.googlesource.com/c/1237298 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
-
Michael Lippautz authored
The notification is only used for testing and benchmarking purposes. Announcing low memory is usually done using MemoryPressure API. Bug: chromium:843903 Change-Id: I998018f7f5f3a0d06283aa6010228a9c86f12c39 Reviewed-on: https://chromium-review.googlesource.com/c/1269037Reviewed-by:
-
Benedikt Meurer authored
The Parser desugaring didn't use the AsyncReturnStatement consistently to return from async functions (aka resolve the .promise with the return value and return the .promise from the async function). Instead the Parser essentially had a copy of the BytecodeGenerator functionality. This change unifies the handling of returns from async functions. Bug: v8:7522, v8:8238 Change-Id: Ib00a60aee30d541b84835d9cc83e9937b7a39e26 Reviewed-on: https://chromium-review.googlesource.com/c/1269036Reviewed-by:
-
Adam Klein authored
Reading through some code today I happened to notice a few places where we were passing "ok" instead of "CHECK_OK", leading to the possibility of code continuing on past a syntax error. This fixes all such cases I found (through manual inspection) in parser-base.h Change-Id: I95ef0a08d0e0a537d86a73bb62929842a3f57a31 Reviewed-on: https://chromium-review.googlesource.com/c/1262998 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#56452}
-
Georgia Kouveli authored
Display the InstructionSequence before and after register allocation. Change-Id: If5169ae1af4f1fda95b3d150f9318ad11679caee Reviewed-on: https://chromium-review.googlesource.com/c/1258005 Commit-Queue: Martyn Capewell <martyn.capewell@arm.com> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#56451}
-
Alexei Filippov authored
Change-Id: I8843796be4a9da39fad96150593837189e452c07 Reviewed-on: https://chromium-review.googlesource.com/c/1262997Reviewed-by:
Ali Ijaz Sheikh <ofrobots@google.com> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#56450}
-
Georg Neis authored
When Turbofan gets triggered during bootstrapping (via --always-opt), some context fields still hold undefined rather than their actual value. Bug: v8:7790 Change-Id: Id87c593182fa8450ba9415d144d105281e48236f Reviewed-on: https://chromium-review.googlesource.com/c/1268240Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#56449}
-
Andreas Haas authored
R=clemensh@chromium.org bug: v8:8275 Change-Id: I4f0beb7064e1a87691e02890b5f96160b1b6c37a Reviewed-on: https://chromium-review.googlesource.com/c/1268157Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#56448}
-
Daniel Clifford authored
In the process: - Convert TryLabelStatements into TryLabelExpressions - Change TryLabelExpressions to support only single label blocks and de-sugar try/labels into nested try/label statements. This allows the code in a label block to goto subsequent labels in the same try/label statement. - Make otherwise expressions either take IdentifierExpressions which get converted into simple label names OR atomarStatements, which make useful non-label operations, like 'break' and 'continue', useful together with otherwise. Non-label otherwise statements get de-sugared into try/label blocks. Bug: v8:7793 Change-Id: Ie56ede6306e2a3182f6aa1bb8750ed418bda01db Reviewed-on: https://chromium-review.googlesource.com/c/1266997 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56447}
-
Toon Verwaest authored
Change-Id: I33426cdbec284f3f2f8d80b29788067efc56226b Reviewed-on: https://chromium-review.googlesource.com/c/1267942Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#56446}
-
Toon Verwaest authored
Always parse through ParseFunctionBody to avoid bugs with parameter/scope handling. Change-Id: Ia0e78c6b3127e99f92a6c772ba2be509f6379f5a Reviewed-on: https://chromium-review.googlesource.com/c/1268236 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Michael Starzinger authored
This adds basic support for decoding catch-all expressions as part of a try block. Note that control flow and code generation support is still missing. R=clemensh@chromium.org TEST=unittests/FunctionBodyDecoderTest.TryCatchAll BUG=v8:8091 Change-Id: I10a1aa3e3e0418e0a04965e8318c94f449a00bb4 Reviewed-on: https://chromium-review.googlesource.com/c/1268059 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Marja Hölttä authored
See https://chromium-review.googlesource.com/1219025 for the corresponding MaybeObject renaming. BUG=v8:7308 Change-Id: Ib454fd53d12f110da289e1d3e1e12411b016e557 Reviewed-on: https://chromium-review.googlesource.com/c/1267937Reviewed-by:
-
Benedikt Meurer authored
This adds support to the escape analysis to allow scalar replacement of (small) FixedArrays with element accesses where the index is not a compile time constant. This happens quite often when inlining functions that operate on variable number of arguments. For example consider this little piece of code: ```js function sum(...args) { let s = 0; for (let i = 0; i < args.length; ++i) s += args[i]; return s; } function sum2(x, y) { return sum(x, y); } ``` This example is made up, of course, but it shows the problem. Let's assume that TurboFan inlines the function `sum` into it's call site at `sum2`. Now it has to materialize the `args` array with the two values `x` and `y`, and iterate through these `args` to sum them up. The escape analysis pass figures out that `args` doesn't escape (aka doesn't outlive) the optimized code for `sum2` now, but TurboFan still needs to materialize the elements backing store for `args` since there's a `LoadElement(args.elements,i)` in the graph now, and `i` is not a compile time constant. However the escape analysis has more information than just that. In particular the escape analysis knows exactly how many elements a non escaping object has, based on the fact that the allocation must be local to the function and that we only track objects with known size. So in the case above when we get to `args[i]` in the escape analysis the relevant part of the graph looks something like this: ``` elements = LoadField[elements](args) length = LoadField[length](args) index = CheckBounds(i, length) value = LoadElement(elements, index) ``` In particular the contract here is that `LoadElement(elements,index)` is guaranteed to have an `index` that is within the valid bounds for the `elements` (there must be a preceeding `CheckBounds` or some other guard in optimized code before it). And since `elements` is allocated inside of the optimized code object, the escape analysis also knows that `elements` has exactly two elements inside (namely the values of `x` and `y`). So we can use that information and replace the access with a `Select(index===0,x,y)` operation instead, which allows us to scalar replace the `elements`, since there's no escaping use anymore in the graph. We do this for the case that the number of elements is 2, as described above, but also for the case where elements length is one. In case of 0, we know that the `LoadElement` must be in dead code, but we can't just mark it for deletion from the graph (to make sure it doesn't block scalar replacement of non-dead code), so we don't handle this for now. And for one element it's even easier, since the `LoadElement` has to yield exactly said element. We could generalize this to handle arbitrary lengths, but since there's a cost to arbitrary decision trees here, it's unclear when this is still beneficial. Another possible solution for length > 2 would be to have special stack allocation for these backing stores and do variable index accesses to these stack areas. But that's way beyond the scope of this isolated change. This change shows a ~2% improvement on the EarleyBoyer benchmark in JetStream, since it benefits a lot from not having to materialize these small arguments backing stores. Drive-by-fix: Fix JSCreateLowering to properly initialize "elements" with StoreElement instead of StoreField (which violates the invariant in TurboFan that fields and elements never alias). Bug: v8:5267, v8:6200 Change-Id: Idd464a15a81e7c9653c48c814b406eb859841428 Reviewed-on: https://chromium-review.googlesource.com/c/1267935 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: -
Benedikt Meurer authored
This change adds predicates to check whether a given JavaScript operator needs the "current context" or if any surrounding context (including the "native context") does it. For example JSAdd doesn't ever need the current context, but actually only the native context. In the BytecodeGraphBuilder we use this predicate to check whether a given operator needs the current context, and if not, we just pass in the native context. Doing so we improve the performance on the benchmarks given in the tracking bug significantly, and go from something around arrayMap: 476 ms. arrayFilter: 312 ms. arrayEvery: 241 ms. arraySome: 152 ms. to arrayMap: 377 ms. arrayFilter: 296 ms. arrayEvery: 191 ms. arraySome: 91 ms. which is an up to 40% improvement. So for idiomatic modern JavaScript which uses higher order functions quite a lot, not just the builtins provided by the JSVM, this is going to improve peak performance noticably. This also makes it possible to completely eliminate all the allocations in the aliased sloppy arguments example ```js function foo(a) { return arguments.length; } ``` concretely we don't allocate the function context anymore and we also don't allocate the arguments object anymore (the JSStackCheck was the reason why we did this in the past, because it was holding on to the current context, which also kept the allocation for the arguments alive). Bug: v8:6200, v8:8060 Change-Id: I1db56d00d6b510ce6337608c0fff16af96e95eef Design-Document: bit.ly/v8-turbofan-context-sensitive-js-operators Reviewed-on: https://chromium-review.googlesource.com/c/1267176Reviewed-by: -
Clemens Hammacher authored
On windows, the {NativeModule::committed_code_space_} counter can underflow because of a bug. This propagates to {WasmCodeManager::remaining_uncommitted_code_space_}, which can lead to over-allocation (more than {kMaxWasmCodeMemory} bytes of code space per module). We were also seeing this bug on UMA data (>1024 MB code space usage). R=ahaas@chromium.org Bug: chromium:893096 Change-Id: If3c9b3e7bdc9fc3caf1eccae991123409718b90f Reviewed-on: https://chromium-review.googlesource.com/c/1267943Reviewed-by:Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56440}
-
Toon Verwaest authored
This also precomputes "declares parameter containing sloppy eval" and reorders fields for better packing. Change-Id: I598ed658f79e7d83f6b844236fc60518d9cf9f26 Reviewed-on: https://chromium-review.googlesource.com/c/1267940Reviewed-by:
-
Hai Dang authored
This is a reland of ef2a19a2. Use AllocateJSArray to avoid allocating an empty fixed array. Original change's description: > Add fast path for spreading primitive strings. > > This improves the performance on primitive strings of > IterableToListWithSymbolLookup, which implements the > CreateArrayFromIterable bytecode. The fast path is only > taken if the string iterator protector is valid (that is, > String.prototype[Symbol.iterator] and > String.prototype[Symbol.iterator]().next are untouched). > > This brings spreading of primitive strings closer to the > performance of the string iterator optimizations. > (see https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8/). > > Bug: chromium:881273, v8:7980 > Change-Id: Ic8d8619da2f2afcc9346203613a844f62653fd7a > Reviewed-on: https://chromium-review.googlesource.com/1243110 > Commit-Queue: Hai Dang <dhai@google.com> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56329} Bug: chromium:881273, v8:7980 Change-Id: I746c57ddfc300e1032057b5125bc824adf5c2cd3 Reviewed-on: https://chromium-review.googlesource.com/c/1267497 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Mathias Bynens authored
Bug: v8:7834 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ie588d032136b164a2e1bcfacf3c22b1a3428f20e Reviewed-on: https://chromium-review.googlesource.com/c/1262676 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
-
Jaroslav Sevcik authored
Bug: chromium:893058 Change-Id: I679c5e645eda5e8e5eb97fa873d0e2ee8ce61e11 Reviewed-on: https://chromium-review.googlesource.com/c/1267938 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Michael Starzinger authored
R=clemensh@chromium.org BUG=v8:8263 Change-Id: I6149cc6b353d4676a4b9170c906fe37822020217 Reviewed-on: https://chromium-review.googlesource.com/c/1267941Reviewed-by:
-
Georg Neis authored
When generating code for element accesses, we used to constant-fold JSTypedArray receivers even when their buffers were on the JS heap. This required a call to MaterializeArrayBuffer, which hinders background compilation. Since the benefit of this optimization is believed to be small, we decided to remove it. Bug: v8:7790 Change-Id: I28d3a57b3d8f5b58b6e00e0bb8328b682a6fbd88 Reviewed-on: https://chromium-review.googlesource.com/c/1256831 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Georg Neis authored
Return the actual length even when the buffer is neutered (we used to return 0). This avoids confusion and makes the behavior consistent with byte_offset() and byte_length(). Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I998f12fa4a428f8555f62e1535247f571ab053f2 Reviewed-on: https://chromium-review.googlesource.com/c/1256768Reviewed-by:
-
Maya Lekova authored
Bug: chromium:892858 Change-Id: I97b0b239e3ee0a9073fdbd609fb26271dda64d6d Reviewed-on: https://chromium-review.googlesource.com/c/1267936 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
-
Jaroslav Sevcik authored
Using function ids is more reliable since there can be several functions or scripts with the same name. Also, that way we do not have to parse anything. Change-Id: If657141d0d6e27dabb49456e0275cce65e753541 Reviewed-on: https://chromium-review.googlesource.com/c/1267496Reviewed-by:
-
