- 25 Sep, 2017 17 commits
-
-
Eric Holk authored
Previously, we would blindly register new handler data, leading to us leaking the old handler data. This meant we could then end up with overlapping handler data where the instruction offset and landing pads didn't line up right. Bug: v8:6841 Change-Id: Iedcd75925b8d9d59c8f9accf288cae954fdc568f Reviewed-on: https://chromium-review.googlesource.com/677632 Commit-Queue: Eric Holk <eholk@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48144}
-
Mostyn Bramley-Moore authored
Bug: chromium:746958 Change-Id: I81ad56e3bfbdc458c3e318927191f6c5e137c448 Reviewed-on: https://chromium-review.googlesource.com/680554Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com> Cr-Commit-Position: refs/heads/master@{#48143}
-
Michael Starzinger authored
This fixes the signatures of "Math.ceil", "Math.floor" and "Math.sqrt" from "(float?) -> float" to "(float?) -> floatish" which avoids using a resulting float value without coercing the value via explicit "fround" annotations. This ensures proper ECMAScript semantics are maintained. R=clemensh@chromium.org TEST=mjsunit/regress/regress-6838-2 BUG=v8:6838 Change-Id: Ib5821641265bc862184adb270e8dbf8c703fdfb0 Reviewed-on: https://chromium-review.googlesource.com/681694Reviewed-by:
-
Ali Ijaz Sheikh authored
This is a reland of ec952aaa. Included is a fix that ensures that top_on_previous_step_ is cleared when we release a page. Original change's description: > Reland "[profiler] proper observation of old space inline allocations" > > This is a reland of 672a41c3 > Original change's description: > > [profiler] proper observation of old space inline allocations > > > > Bug: chromium:633920 > > Change-Id: I9a2f4a89f6b9c0f63cb3b166b06a88a12f0a203c > > Reviewed-on: https://chromium-review.googlesource.com/631696 > > Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48043} > > Bug: chromium:633920 > Change-Id: I6fe743d31b8ff26f3858488d4c014c62d3c85add > Reviewed-on: https://chromium-review.googlesource.com/671127 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com> > Cr-Commit-Position: refs/heads/master@{#48085} Bug: chromium:633920 Change-Id: I8a0dcc4eaffc1f1d3ac5b3f8d344001cdae36606 Reviewed-on: https://chromium-review.googlesource.com/677407Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com> Cr-Commit-Position: refs/heads/master@{#48141}
-
Benedikt Meurer authored
When inlining based on SharedFunctionInfo rather than based on concrete JSFunction, we weren't able to properly optimize array, object and regexp literals inside the inlinee, because we didn't know the concrete FeedbackVector for the inlinee inside JSCreateLowering. This was because JSCreateLowering wasn't properly updated after the literals moved to the FeedbackVector. Now with this CL we also have the VectorSlotPair on the literal creation operators, just like we do for property accesses and calls, and are thus able to always access the appropriate FeedbackVector and optimize the literal creation. The impact is illustrated by the micro-benchmark on the tracking bug, which goes from createEmptyArrayLiteral: 1846 ms. createShallowArrayLiteral: 1868 ms. createShallowObjectLiteral: 2246 ms. to createEmptyArrayLiteral: 1175 ms. createShallowArrayLiteral: 1187 ms. createShallowObjectLiteral: 1195 ms. with this CL, so up to 2x faster now. Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin and cleanup the names of the other builtins to be consistent with the names of the TurboFan operators and Ignition bytecodes. Bug: v8:6856 Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097 Reviewed-on: https://chromium-review.googlesource.com/680656 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48140}
-
Michael Starzinger authored
This fixes the signature of "Math.min" and "Math.max" for integer values from "(int, int...) -> signed" to "(signed, signed..) -> signed" which properly distinguishes signed from unsigned values now. This is in sync with the spec errata (and ECMAScript semantics). R=clemensh@chromium.org TEST=mjsunit/regress/regress-6838-1 BUG=v8:6838 Change-Id: Id72836513dd86e93472a22cf1ac2e2d382ed4f23 Reviewed-on: https://chromium-review.googlesource.com/681357 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an embedded comparison. This gives better error messages and also does the right comparison for signed/unsigned mismatches. This will allow us to reenable the readability/check cpplint check. R=yangguo@chromium.org Bug: v8:6837 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I88e5afea1ad0fdf23a81b380e64ff356bbc20112 Reviewed-on: https://chromium-review.googlesource.com/681374Reviewed-by: -
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/48a2b7b..898597f Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/5af0a3a..cbc33b9 Rolling v8/third_party/android_tools: https://chromium.googlesource.com/android_tools/+log/e9d4018..aadb2fe Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/7149cbf..e3fe21f Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/40f6966..cf5e2ed Rolling v8/tools/swarming_client: https://chromium.googlesource.com/infra/luci/client-py/+log/42721e1..5e8001d TBR=machenbach@chromium.org,hablich@chromium.org Change-Id: I5881bcaa603d721167d1ed3e893d0171de617c04 Reviewed-on: https://chromium-review.googlesource.com/657634Reviewed-by:
v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48137}
-
Clemens Hammacher authored
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an embedded comparison. This gives better error messages and also does the right comparison for signed/unsigned mismatches. This will allow us to reenable the readability/check cpplint check. R=ulan@chromium.org Bug: v8:6837 Change-Id: I8d900f3c703dea6ee3bcc225a1d2754e91666b9d Reviewed-on: https://chromium-review.googlesource.com/671047 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: -
Clemens Hammacher authored
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an embedded comparison. This gives better error messages and also does the right comparison for signed/unsigned mismatches. This will allow us to reenable the readability/check cpplint check. R=jarin@chromium.org Bug: v8:6837 Change-Id: I712580c2a4326e06ee3d6d0eb4ff8c7d24f5fdb9 Reviewed-on: https://chromium-review.googlesource.com/671227 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48135}
-
Michael Achenbach authored
This ports: https://chromium-review.googlesource.com/c/544798/ This is needed to unblock rolling build into v8 at: https://chromium-review.googlesource.com/c/v8/v8/+/657634 Bug: chromium:593874, chromium:742655 Change-Id: Ie00f2d13cfd052881a84b6e0cb95c336b7d2581c Reviewed-on: https://chromium-review.googlesource.com/680815 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Sergiy Byelozyorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#48134}
-
Maya Lekova authored
Bug: Change-Id: I7cb8ace4183c0dcf34d71d1b378204383c17ba56 Reviewed-on: https://chromium-review.googlesource.com/678718Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Marja Hölttä authored
Track whether the async arrow func parameter list was simple or not; the information is already there, we just didn't pipe it through correctly. It's needed by PreParser so that it can create the correct Scope structure. Implementation notes: - I could've used async_classifier for transmitting the "is_simple" bit, but I made it explicit (it would be unnecessary to use ExpressionClassifier for this, as we're not classifying any expressions) instead. - I'm also moving work (setting parameter_list.is_simple) from Parser to ParserBase, and adding a DCHECK in Parser to assert that the work was indeed already done. BUG=v8:5516,chromium:765532 Change-Id: Iacf91b150d1b57996544b5e64baa7d91ac134445 Reviewed-on: https://chromium-review.googlesource.com/674695 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48132}
-
Benedikt Meurer authored
We can constant-fold JSLoadProperty(o, i) when o is a known object (i.e. TurboFan's context specialization provides a known non-null/-undefined constant value for it), i is a known array index and o["i"] is an element on the receiver, that is non-configurable and non-writable (i.e. o was frozen using Object.freeze earlier, or o is a String object). This significantly reduces execution time of the tagged templates micro-benchmarks (ES6 and Babel transpiled), when combined with the CL https://chromium-review.googlesource.com/c/v8/v8/+/677462, it goes from templateStringTagES5: 4552 ms. templateStringTagES6: 14185 ms. templateStringTagBabel: 7626 ms. to templateStringTagES5: 4550 ms. templateStringTagES6: 616 ms. templateStringTagBabel: 589 ms. so overall a solid 23x improvement on the ES6 benchmark. This is representative of the six-speed-templatestringtag-es6 benchmark. Bug: v8:6819, v8:6820, v8:6831 Change-Id: Ia45fbdf92977bfbe7400cfa60bd362b78086dc26 Reviewed-on: https://chromium-review.googlesource.com/677603Reviewed-by:
-
Ulan Degenbaev authored
This patch ensures that the concurrent marking tasks do not use more than the half of the available background threads. Bug: chromium:694255 Change-Id: I67d6eb3e717945f777d0711bd094630573c78661 Reviewed-on: https://chromium-review.googlesource.com/678636 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Michael Lippautz authored
Spaces sizes will be replaced with absolute values. Bug: Change-Id: I3d9f32b723ad8872a088f436bd279a0a3f66401e Reviewed-on: https://chromium-review.googlesource.com/680769Reviewed-by:
-
Michael Lippautz authored
Casting to HeapObject before checking whether the object actually is a HeapObject is undefined behavior. Bug: chromium:738743 Change-Id: I7be8dfbc18203c6be008af73549a915f9b6bd3de Reviewed-on: https://chromium-review.googlesource.com/680768Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#48128}
-
- 23 Sep, 2017 1 commit
-
-
Deepti Gandluri authored
Bug=v8:6842,v8:6532 Change-Id: I6ae1064e1e9a54c189311d6f34fc5fad85f13b7f Reviewed-on: https://chromium-review.googlesource.com/678594 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Reviewed-by:
Ben Smith <binji@chromium.org> Cr-Commit-Position: refs/heads/master@{#48127}
-
- 22 Sep, 2017 8 commits
-
-
Benedikt Meurer authored
Tagged templates were previously desugared during parsing using some combination of runtime support written in JavaScript and C++, which prevented some optimizations from happening, namely the constant folding of the template object in TurboFan optimized code. This CL adds a new bytecode GetTemplateObject (with a corresponding GetTemplateObject AST node), which represents the abstract operation in the ES6 specification and allows TurboFan to simply constant-fold template objects at compile time (which is explicitly supported by the specification). This also pays down some technical debt by removing the template.js runtime support and therefore should reduce the size of the native context (snapshot) a bit. With this change in-place the ES6 version microbenchmark in the referenced tracking bug is now faster than the transpiled Babel code, it goes from templateStringTagES5: 4552 ms. templateStringTagES6: 14185 ms. templateStringTagBabel: 7626 ms. to templateStringTagES5: 4515 ms. templateStringTagES6: 7491 ms. templateStringTagBabel: 7639 ms. which corresponds to a solid 45% reduction in execution time. With some further optimizations the ES6 version should be able to outperform the ES5 version. This micro-benchmark should be fairly representative of the six-speed-templatestringtag-es6 benchmark, and as such that benchmark should also improve by around 50%. Bug: v8:6819,v8:6820 Tbr: mlippautz@chromium.org Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc Reviewed-on: https://chromium-review.googlesource.com/677462Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Caitlin Potter <caitp@igalia.com> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48126}
-
Karl Schimpf authored
Fixes the collection of V8.WasmFuncctionSizeBytes.wasm for UMA stats. Bug: v8:6852 Change-Id: Ib25d249dd2856ffb8a3205e54ba052c1bc9a09cf Reviewed-on: https://chromium-review.googlesource.com/678448Reviewed-by:
-
Bill Budge authored
- Moves GetRandomMmapAddr from platform to v8::internal allocation primitives, in preparation for delegating this to the embedder. - Adds hint parameters to OS functions that used to use this function. Bug: chromium:756050 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Iad72e6eac9c08a3e22c2cd2b2905623b8e514ae0 Reviewed-on: https://chromium-review.googlesource.com/677777Reviewed-by:
-
Albert Mingkun Yang authored
TurboAssembler::CallRecordWriteStub contains info that could be used to conditionally skip generational write barrier or skip saving float-point registers. This commits uses those info in RecordWrite stub. Bug: chromium:749486 Change-Id: I41c9a593473e1f8863a09887fd2ce917f1d4fb3b Reviewed-on: https://chromium-review.googlesource.com/672527Reviewed-by:
-
Mostyn Bramley-Moore authored
BUILD is already defined in test/cctest/wasm/wasm-run-utils.h. Bug: chromium:746958 Change-Id: Icf577ce91424d9851d2db39658fd52c68c864995 Reviewed-on: https://chromium-review.googlesource.com/676843Reviewed-by:
-
Georgia Kouveli authored
Add padding for the interpreter registers when needed, to make the interpreter frame a multiple of 16 bytes. The padding needs to be added in the InterpreterEntryTrampoline and when generating an interpreter frame in the deoptimizer. It also needs to be considered when calculating the size of the interpreter frame during OSR and stack unwinding. Bug: v8:6644 Change-Id: Icfec94079cf0785fc8a2506ff555b5f9e89e3d13 Reviewed-on: https://chromium-review.googlesource.com/664563 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#48121}
-
Michael Lippautz authored
Bug: chromium:738865 Change-Id: I0b5dea276363aa5bf51eea0b7fde1f4f265a6360 Reviewed-on: https://chromium-review.googlesource.com/678354Reviewed-by:
-
Ulan Degenbaev authored
This changes CPU check to use 'target_cpu' instead of 'v8_target_cpu'. Bug: chromium:694255 Change-Id: Ic3ad5253e4e0b66b13e9f16a5842bcf49881fa52 Reviewed-on: https://chromium-review.googlesource.com/677994Reviewed-by:
-
- 21 Sep, 2017 14 commits
-
-
Aseem Garg authored
This change enables moving the WasmToJSWrapper off the GCed heap R=bradnelson@chromium.org,mtrofin@chromium.org,clemensh@chromium.org Bug: Change-Id: I1ea8810fa7b71bcb2a80a1390742db64872c5bb1 Reviewed-on: https://chromium-review.googlesource.com/665977Reviewed-by:
-
Jakob Kummerow authored
The code after the binary-search loop is unlikely to be reached, but not actually UNREACHABLE(). Restore the "return 0" that was there until a cleanup [1] removed it. [1] crrev.com/c/507287/2/src/date.cc Bug: chromium:767039 Change-Id: I9e007d3b7d693d4866ccc3e3cf2b71e78e9bd07f Reviewed-on: https://chromium-review.googlesource.com/675755Reviewed-by:
-
Martyn Capewell authored
This is mainly about clarifying the frame contents for each call type, though assertions on the even length of Push/PopRegList() are also added. Bug: v8:6644 Change-Id: I4dfe6ac2603e2bab895758e85d8dfe06770d8987 Reviewed-on: https://chromium-review.googlesource.com/672844Reviewed-by:
-
Pierre Langlois authored
This is a reland of c6b153fd Original change's description: > [cctest] Add fuzz tests for generating parallel moves. > > These new tests are somewhat similar to the existing gap resolver tests except > we use the code generator and eventually run the generated code. The main idea > is to cover cases that are difficult to hit, such as move from/to slots which > are out of range of loads and stores, but may happen nonetheless. > > At this time, the tests only make sure the code generator actually generated > some code, and that this code runs. In the future, it would be great to also > check that the moves were actually performed. > > Bug: v8:6553 > Change-Id: I089a25fa05b3a20649658bb8952926ab11f91d68 > Reviewed-on: https://chromium-review.googlesource.com/574850 > Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> > Reviewed-by: Bill Budge <bbudge@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47733} Bug: v8:6553 Change-Id: Ia3eac9d7e6a23e2f6fea839b71d460cb7ad6ff6e Reviewed-on: https://chromium-review.googlesource.com/645868Reviewed-by:
-
Bill Budge authored
- Changes encoding movups to one where destination is the first operand. Bug: v8:6843 Change-Id: Ie2f957403aa75b5490446b43e37c064e8055693f Reviewed-on: https://chromium-review.googlesource.com/676134Reviewed-by:
-
Bill Budge authored
This is a reland of f2cd10db Original change's description: > Reland "[Memory] Move VirtualMemory out of base:: platform." > > This is a reland of 4dd293d9 > Original change's description: > > [Memory] Move VirtualMemory out of base:: platform. > > > > - Moves base::VirtualMemory to v8::internal::VirtualMemory. > > - Makes VirtualMemory platform-independent by moving internals to new > > OS:: static methods, for each platform. > > > > This will make it easier to delegate memory management in VirtualMemory > > to V8::Platform, so that embedders like Blink can override it. We can't > > depend on V8::Platform in base/platform. > > > > Bug: chromium:756050 > > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng > > Change-Id: Iadfe230b6850bd917727a373f277afded9883adf > > Reviewed-on: https://chromium-review.googlesource.com/653214 > > Commit-Queue: Bill Budge <bbudge@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48048} > > Bug: chromium:756050 > Change-Id: Ib492c7c69f1833be127a571808301e96b84b8aa2 > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng > Reviewed-on: https://chromium-review.googlesource.com/671125 > Commit-Queue: Bill Budge <bbudge@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48084} Bug: chromium:756050 Change-Id: Ie596730b5cefc38137cab7fc1f76613f5af7b825 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Reviewed-on: https://chromium-review.googlesource.com/675283Reviewed-by:
-
Clemens Hammacher authored
The baseline compiler needs to know the depth in order to access the parent block. This is a small CL, but anything that can land before the big baseline CL reduced the complexity of the latter. R=ahaas@chromium.org Bug: v8:6600 Change-Id: I2e29cc974908438266adb4301026dfe5fbfb1990 Reviewed-on: https://chromium-review.googlesource.com/677301Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48112}
-
Marja Hölttä authored
There are some mysterious, unreproducible CHECK failures (inconsistent data). Add more information onto the stack (and thus, to minidumps) for debugging them. BUG=v8:5516,chromium:766693 Change-Id: Ic1ebc3036957ede4e3e1c1d287479897e54e40ed Reviewed-on: https://chromium-review.googlesource.com/677294Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#48111}
-
Clemens Hammacher authored
In the current implementation, compilation would fail because operator<< is not defined for enum classes. For others, the compiler finds more than one operator<<, so it fails because it's ambiguous. This CL fixes this by printing the integer value for enums, uses the operator<< for all values that support it, and prints "<unprintable>" otherwise. Also, lots of unit tests. R=ishell@chromium.org Bug: v8:6837 Change-Id: I895ed226672aa07213f9605e094b87af186ec2e4 Reviewed-on: https://chromium-review.googlesource.com/671016 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
And add some tests for (seemingly) previously uncovered cases. The additional check for unreachable code is not needed any more, since polymorphic stack values get assigned a specific type on their first use or validation anyway. Hence the first entry in the br_table will assign specific types to all polymorphic stack values, and type checking will fail if later entries do not match. R=rossberg@chromium.org CC=titzer@chromium.org Change-Id: I1d0f91f927a2aa5186f874112e91ebffa1f1b3a7 Reviewed-on: https://chromium-review.googlesource.com/675405Reviewed-by:
Andreas Rossberg <rossberg@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48109}
-
Ivica Bogosavljevic authored
Bug: Change-Id: Ia7bbbb2aba28ec36b470a1b23ebe38fc3a09e600 Reviewed-on: https://chromium-review.googlesource.com/657757 Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com> Reviewed-by:
Miran Karić <Miran.Karic@imgtec.com> Reviewed-by:
-
Ulan Degenbaev authored
This is a reland of 8c4a8250 Original change's description: > [heap] Enable concurrent marking for x86 and x64. > > Bug: chromium:694255 > Change-Id: I28c8c6e5ba6c84123f3951e822c132860cb22c1d > Reviewed-on: https://chromium-review.googlesource.com/641451 > Commit-Queue: Kentaro Hara <haraken@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Hannes Payer (slow) <hpayer@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48100} Bug: chromium:694255 TBR: mlippautz@chromium.org Change-Id: Ic36515dbd418c219bccbbf371126a4dfd66a466f Reviewed-on: https://chromium-review.googlesource.com/676966Reviewed-by:
-
Mostyn Bramley-Moore authored
Bug: chromium:746958 Change-Id: I0c1dfe1019b5324d322f5c7a6a2e6095c18f0b40 Reviewed-on: https://chromium-review.googlesource.com/676583Reviewed-by:
-
Marja Hölttä authored
This fix is two-fold: 1) Incremental UTF-8 decoding: Unify incorrect UTF-8 handling between V8 and Blink. Incremental UTF-8 decoding used to allow some overlong sequences / invalid code points which Blink treated as errors. This caused the decoder and the Blink UTF-8 decoder to produce a different number of bytes, resulting in random failures when scripts were streamed (especially, this was detected by the skipping inner functions feature which adds CHECKs against expected function positions). 2) Non-incremental UTF-8 decoding: return the correct amount of invalid characters. According to the encoding spec ( https://encoding.spec.whatwg.org/#utf-8-decoder ), the first byte of an overlong sequence / invalid code point generates an invalid character, and the rest of the bytes are not processed (i.e., pushed back to the byte stream). When they're handled, they will look like lonely continuation bytes, and will generate an invalid character each. As a result, an overlong 4-byte sequence should generate 4 invalid characters (not 1). This is a potentially breaking change, since the (non-incremental) UTF-8 decoding is exposed via the API (String::NewFromUtf8). The behavioral difference happens when the client is passing in invalid UTF-8 (containing overlong / surrogate sequences). However, afaict, this doesn't change the semantics of any JavaScript program: according to the ECMAScript spec, the program is a sequence of Unicode code points, and there's no way to invoke the UTF-8 decoding functionalities from inside JavaScript. Though, this changes the behavior of d8 when decoding source files which are invalid UTF-8. This doesn't change anything related to URI decoding (it already throws exceptions for overlong sequences / invalid code points). BUG: chromium:765608, chromium:758236, v8:5516 Bug: Change-Id: Ib029f6a8e87186794b092e4e8af32d01cee3ada0 Reviewed-on: https://chromium-review.googlesource.com/671020 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Franziska Hinkelmann <franzih@chromium.org> Reviewed-by:
-
