- 03 Oct, 2017 4 commits
-
-
Benedikt Meurer authored
THe change in https://chromium-review.googlesource.com/695108 flushed out an issue with the IC::UpdatePolymorphicIC logic, where we'd try to stay MONOMORPHIC or POLYMORPHIC as long as the internalized name doesn't change. But the calling code already does the internalization for keyed accesses with Strings, so we need to double check that the same combination of (map, handler) is not already in the list, and properly go to MEGAMORPHIC state if there's such a pair already. This seriously tanked the six-speed-object-literals-ext-es5.js benchmark on AWFY. Bug: v8:6367, v8:6278, v8:6344 Change-Id: I90ea88d1fe61c165990c0a10d4a8687ffe351986 Reviewed-on: https://chromium-review.googlesource.com/695307Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48268}
-
Mostyn Bramley-Moore authored
Avoid F5 symbol clash. Bug: chromium:770684 Change-Id: I9e851c1fe5abbdc4d032b7efdd0462c96d0c8ef3 Reviewed-on: https://chromium-review.googlesource.com/696063Reviewed-by:
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/ce6d3d8..05cc4b1 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/8ec7b14..3f41f93 TBR=machenbach@chromium.org,hablich@chromium.org Change-Id: Ibf166d33a133519e0c4ce36b20a42aa391f48c8b Reviewed-on: https://chromium-review.googlesource.com/696523Reviewed-by:
v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#48266}
-
Alexey Kozyatinskiy authored
In V8Debugger code we don't expect task_id == null, e.g. asyncTaskStartedForStepping will trigger debug break on null as task_id. Let's filter task_id == null out. This issue is originally filed in Node.js: https://github.com/nodejs/node/issues/15464 R=dgozman@chromium.org Bug: none Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Icc9f96105b3c91ee1b102d545a7817f7ee93394c Reviewed-on: https://chromium-review.googlesource.com/695808Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#48265}
-
- 02 Oct, 2017 14 commits
-
-
Michael Starzinger authored
This makes sure that helper methods on the {TranslatedState} class stick to the counting scheme used by {OptimizedFrame::Summarize} within the stack-walker. Both now treat {kJavaScriptBuiltinContinuation} as real JavaScript frames. R=jarin@chromium.org TEST=mjsunit/regress/regress-crbug-770543 BUG=chromium:770543 Change-Id: Icda65a7efb487470d39ebf648767a488ebf2e5f1 Reviewed-on: https://chromium-review.googlesource.com/695123 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48264}
-
Michael Starzinger authored
R=jarin@chromium.org Change-Id: I6f2e70d231d2c28c77bee121e98317f3f506fce4 Reviewed-on: https://chromium-review.googlesource.com/691975 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Michael Starzinger authored
This makes sure the deoptimizer properly materializes heap objects, even when the top-most frame happens to be a stub-frame. Without this step the {arguments_marker} would leak into user-land and most likely be treated as an undefined value. R=jarin@chromium.org TEST=mjsunit/regress/regress-crbug-769852 BUG=chromium:769852 Change-Id: I4ba17501c5d7e68d1f402b7c2cc5ccb0fb7bfb05 Reviewed-on: https://chromium-review.googlesource.com/691996Reviewed-by: -
Benedikt Meurer authored
Until now keyed accesses to properties with string or symbol keys were only optimized properly while the IC was monomorphic and would go megamorphic as soon as there's another receiver map, even if the name was still the same (i.e. the same symbol or internalized string). This was a weird performance-cliff, that'll hurt modern code especially because for symbols you can only access them via keyed loads and stores. This CL fixes the state machine inside the ICs to properly transition to POLYMORPHIC state (and stay there) as long as the new name matches the previously recorded name. The FeedbackVector and TurboFan were already able to deal with this and didn't need any updates. On the micro-benchmark from the tracking bug we go from testStringMonomorphic: 429 ms. testSymbolMonomorphic: 431 ms. testStringPolymorphic: 429 ms. testSymbolPolymorphic: 5621 ms. to testStringMonomorphic: 429 ms. testSymbolMonomorphic: 429 ms. testStringPolymorphic: 429 ms. testSymbolPolymorphic: 430 ms. effectively eliminating the overhead for symbols completely, and yielding a 13.5x performance boost. This also seems to yield a 1% improvement on the ARES6 ML benchmark, because it eliminates the KEYED_LOAD_ICs for the Symbol.species lookups. Bug: v8:6367, v8:6278, v8:6344 Change-Id: I879fe56387b4c56203c1ad8ef8cafb6cc4c32897 Reviewed-on: https://chromium-review.googlesource.com/695108Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48261}
-
Mathias Bynens authored
The context is the following proposal to make JSON a subset of JavaScript: https://github.com/tc39/proposal-json-superset There’s interest in performing a side investigation to answer the question of what would happen if we stopped treating U+2028 and U+2029 as `LineTerminator`s *entirely*. (Note that this is separate from the proposal, which just changes how these characters are handled in ECMAScript strings.) This is technically a breaking change, and IMHO it would be wonderful if we could get away with it, but no one really has any data on whether or not we could. Adding this use counter lets us get that data. BUG=v8:6827 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ia22e8db1634df4d3f965bec8e1cfa11cc7b5e9aa Reviewed-on: https://chromium-review.googlesource.com/693155 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#48260}
-
Michael Lippautz authored
Bug: Change-Id: I2b1ae2f475e780606fa07db2cf861eb2537207d6 Reviewed-on: https://chromium-review.googlesource.com/695223Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#48259}
-
Camillo Bruni authored
Change-Id: I3b7e5f4fb9bc6cdad3582e19099fb97b2a0c7cb0 No-Try: true Reviewed-on: https://chromium-review.googlesource.com/684185Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#48258}
-
Benedikt Meurer authored
The KEYED_STORE_IC was never able to deal with stores to typed arrays where the value being stored is not already a Number (i.e. either a Smi or a HeapNumber). By extending it to also handle Oddballs (i.e. true, false, undefined and null) and teaching TurboFan to also perform the appropriate check plus the truncation to Number, we can easily support this use case as well. On the micro-benchmark in the bug report, we go from typedArrayStoreBool: 2975 ms. typedArrayStoreInt: 44 ms. to typedArrayStoreBool: 43 ms. typedArrayStoreInt: 44 ms. so that's roughly a 70x performance boost. Bug: chromium:287773 Change-Id: I227419aeabc3f5b6793aa280a95448d03ac2f2dd Reviewed-on: https://chromium-review.googlesource.com/691731 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Ben L. Titzer authored
R=gdeepti@chromium.org Bug: Change-Id: Ic2e519d24354b3327a92daa0d4d6e06c9ca4605e Reviewed-on: https://chromium-review.googlesource.com/687056 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48256}
-
Clemens Hammacher authored
With --wasm-trace-memory, both compiled code and the interpreter will output each memory load or store. This helps to debug miscompilations in emscripten or in V8, like the referenced bug. R=titzer@chromium.org Bug: chromium:718858 Change-Id: I90704d164975b11c65677f86947ab102242d5153 Reviewed-on: https://chromium-review.googlesource.com/684316Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48255}
-
Benedikt Meurer authored
The TypedArray.prototype[Symbol.toStringTag] getter is currently the best (and as far as I can tell only definitely side-effect free) way to check whether an arbitrary object is a TypedArray - either generally TypedArray or a specific one like Uint8Array. Using the getter is thus emerging as the general pattern to detect TypedArrays, even Node.js now adapted it starting with https://github.com/nodejs/node/pull/15663 for the isTypedArray and isUint8Array type checks in lib/internal/util/types.js now. The getter returns either the string with the TypedArray subclass name (i.e. "Uint8Array") or undefined if the receiver is not a TypedArray. This can be implemented with a simple elements kind dispatch, instead of checking the instance type and then loading the class name from the constructor, which requires a loop walking up the transition tree. This CL ports the builtin to CSA and TurboFan, and changes the logic to a simple elements kind check. On the micro-benchmark mentioned in the referenced bug, the time goes from testIsArrayBufferView: 565 ms. testIsTypedArray: 2403 ms. testIsUint8Array: 3847 ms. to testIsArrayBufferView: 566 ms. testIsTypedArray: 965 ms. testIsUint8Array: 965 ms. which presents an up to 4x improvement. Bug: v8:6874 Change-Id: I9c330b4529d9631df2f052acf023c6a4fae69611 Reviewed-on: https://chromium-review.googlesource.com/695021Reviewed-by:
-
Daniel Clifford authored
Change-Id: Iac4a95a0c094472d887d89bbf5d6189988c56f7c Reviewed-on: https://chromium-review.googlesource.com/692016 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48253}
-
Deepti Gandluri authored
Bug: V8:6532 Change-Id: I6713e1c01ec669b7fa9a09bb75fbecff12f6cc22 Reviewed-on: https://chromium-review.googlesource.com/685949 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Ben Smith <binji@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#48252}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/b376554..ce6d3d8 TBR=machenbach@chromium.org,hablich@chromium.org Change-Id: Idda412143f1ff00ca10e8822acb5a0754372ee29 Reviewed-on: https://chromium-review.googlesource.com/694681Reviewed-by:
-
- 01 Oct, 2017 2 commits
-
-
Bill Budge authored
- Moves leak sanitizer code to callers of OS:: Memory functions. - Changes signature of OS::ReleasePartialRegion to be more generic, removing the parameters that only make sense as part of VirtualMemory. Bug: chromium:756050 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2f1401c9b0856b2eaf36b80b5f141e935ef63e1c Reviewed-on: https://chromium-review.googlesource.com/685741Reviewed-by:
-
v8-autoroll authored
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b6bab93..8ec7b14 TBR=machenbach@chromium.org,hablich@chromium.org Change-Id: Ifd4855bf671093c4494776ff16d4a58a0ef4eade Reviewed-on: https://chromium-review.googlesource.com/693092Reviewed-by:
-
- 30 Sep, 2017 5 commits
-
-
Mostyn Bramley-Moore authored
Remove more "using" statements. Bug: chromium:746958 Change-Id: I2f9c45b1ff1d51fc58b7a702fee046ba3c6a7c17 Reviewed-on: https://chromium-review.googlesource.com/693862Reviewed-by:
-
Benedikt Meurer authored
This improves performance of ArrayBuffer.isView by roughly 2.5x itself, and enables optimizations across ArrayBuffer.isView calls, i.e. map checks can be eliminated across. This was discovered in a related Node pull request (https://github.com/nodejs/node/pull/15663). Bug: v8:6868 Change-Id: I1d56ec385f8daa0e1d44d3bc4d6c9a5558ba4522 Reviewed-on: https://chromium-review.googlesource.com/691660Reviewed-by:
-
Tobias Tebbi authored
This reverts commit 3c4bc27f. Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=770257 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} TBR=jarin@chromium.org,tebbi@chromium.org Change-Id: Ied8da411a9c8cbe4ed2e1d3e98a76162c2834c97 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:741225 chromium:770257 Reviewed-on: https://chromium-review.googlesource.com/693235Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#48246}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/57716b3..b376554 Rolling v8/third_party/android_tools: https://chromium.googlesource.com/android_tools/+log/aadb2fe..ca9dc72 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/9a255f5..b6bab93 TBR=machenbach@chromium.org,hablich@chromium.org Change-Id: I2fca7ada80048172b8dd07124a06a5064df165e9 Reviewed-on: https://chromium-review.googlesource.com/693082Reviewed-by:
-
Eric Holk authored
In JS to Wasm wrappers, arguments have to be converted from JavaScript's representation to Wasm's representation. Because of property accessors, this can result in JavaScript or even asm.js/Wasm code being run. We were previously setting this flag before doing the parameter conversions, and if these conversions triggered a Wasm property getter then we would try to set the flag twice. With this change, we wait until after all argument conversions are done to set the flag. Bug: chromium:769846 R=bradnelson@chromium.org Change-Id: Ia4b56df45619dcad69f3750bb33cacfedcaeb5b2 Reviewed-on: https://chromium-review.googlesource.com/693414 Commit-Queue: Brad Nelson <bradnelson@chromium.org> Reviewed-by:
Brad Nelson <bradnelson@chromium.org> Cr-Commit-Position: refs/heads/master@{#48244}
-
- 29 Sep, 2017 15 commits
-
-
Jakob Kummerow authored
Changing "DoubleDigitGreaterThan", which was consuming the result of a multiplication, to "ProductGreaterThan", which performs both steps. Bug: v8:6791 Change-Id: I7dbad350ff9b8228e11682d9691a1574ea5b0b58 Reviewed-on: https://chromium-review.googlesource.com/683614Reviewed-by:
Daniel Ehrenberg <littledan@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#48243}
-
Eric Holk authored
This reverts commit 1f99c66b. Reason for revert: Test timeouts on Win64 Debug: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/19226 Original change's description: > [wasm] always allocate memory when guard regions are needed > > When using trap handlers, memory references do not get any checks inserted. This > means there is no check for a null memory as happens when the memory size is > 0. Normally this would be correctly caught as an out of bounds access, since the > low memory addresses are not normally mapped. However, if they were mapped for > some reason, we would not catch the out of bounds access. > > The fix is to ensure WebAssembly instances always have a guard region even if > the memory is size 0. > > Bug: chromium:769637 > Change-Id: I2d0f8c107563236c3780eb7746c2f820e319c65f > Reviewed-on: https://chromium-review.googlesource.com/693137 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Eric Holk <eholk@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48240} TBR=gdeepti@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: I4065b367c6cfffe8dd601b67cd53ad54759ae96a No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:769637 Reviewed-on: https://chromium-review.googlesource.com/692918Reviewed-by:
Eric Holk <eholk@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48242}
-
Jakob Kummerow authored
based on the existing Number.parseInt. Bug: v8:6791 Change-Id: I9169a4695807a3e435e343d239431ae7f6ccf2a1 Reviewed-on: https://chromium-review.googlesource.com/685990Reviewed-by:
-
Eric Holk authored
When using trap handlers, memory references do not get any checks inserted. This means there is no check for a null memory as happens when the memory size is 0. Normally this would be correctly caught as an out of bounds access, since the low memory addresses are not normally mapped. However, if they were mapped for some reason, we would not catch the out of bounds access. The fix is to ensure WebAssembly instances always have a guard region even if the memory is size 0. Bug: chromium:769637 Change-Id: I2d0f8c107563236c3780eb7746c2f820e319c65f Reviewed-on: https://chromium-review.googlesource.com/693137Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48240}
-
Jakob Kummerow authored
It was working fine for bases 2, 4, and 16; but not for 8 and 32. We have to take carryover from one digit to the next into account when bits_per_character is not a divisor of kDigitBits. Bug: v8:6791 Change-Id: Ia2cd13bdddb04b8abf1e4381e66ba4c88826fbf9 Reviewed-on: https://chromium-review.googlesource.com/685813Reviewed-by:
-
Michael Lippautz authored
Bug: chromium:738865 Change-Id: I070982d8a4fe2595673ca727973ad8b723050c2f Reviewed-on: https://chromium-review.googlesource.com/692255Reviewed-by:
-
Toon Verwaest authored
TBR: ofrobots@google.com, yangguo@chromium.org Bug: Change-Id: I6cb0704acabf9a7f2334de539a6600db8607baef Reviewed-on: https://chromium-review.googlesource.com/691720 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48237}
-
Michael Achenbach authored
This ports: https://chromium-review.googlesource.com/c/chromium/src/+/688742 TBR=agable@chromium.org Bug: chromium:731091 Change-Id: I99b6bfcc769a5f3c429668c2d36518bcac80f3cf Reviewed-on: https://chromium-review.googlesource.com/692634Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48236}
-
Yang Guo authored
Change the default to false. Block coverage will need to be enabled explicitly via inspector protocol, which is already being done. R=franzih@chromium.org Bug: v8:6738 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I08684ce7b501981bc376a6bc6181fabac9628a63 Reviewed-on: https://chromium-review.googlesource.com/689234Reviewed-by:
Franziska Hinkelmann <franzih@chromium.org> Reviewed-by:
-
Georgia Kouveli authored
This reverts commit 1cc93be0. Reason for revert: http://crbug.com/769976 Original change's description: > [arm64] Add slot copier to masm and use in builtins > > Abstract some stack slot copies through a macro assembler function. This > eliminates some non-paired stack operations. > > Bug: v8:6644 > Change-Id: Icaa3ebb1bec42587ad461bd548a4225c7b4e5d15 > Reviewed-on: https://chromium-review.googlesource.com/685238 > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Martyn Capewell <martyn.capewell@arm.com> > Cr-Commit-Position: refs/heads/master@{#48177} TBR=rmcilroy@chromium.org,martyn.capewell@arm.com,bmeurer@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:6644 Change-Id: I9044df7c2be028748d85b7007008331a2aa8173f Reviewed-on: https://chromium-review.googlesource.com/691874 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#48234}
-
Yang Guo authored
And some refactoring to the existing code for LiveEdit. R=jarin@chromium.org Change-Id: Ic1d626db9722b39cbcd83bf6878fc24d6094e612 Reviewed-on: https://chromium-review.googlesource.com/687014 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
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/692034Reviewed-by:
-
Marja Hölttä authored
We were unnecessarily storing everything as uint32_t, even though many items in the preparsed scope data can be stored as uint8_t. This CL also adds an (internal) API which abstracts away the actual data storing, so the backing store can be made even more efficient (e.g., use only 1-3 bytes for some uint32_t values, if they fit) without affecting other parts of the code. BUG=v8:5516,chromium:762492 Change-Id: I7cd4d91dc11f87f8aec9c7584044a6f2a59b73ba Reviewed-on: https://chromium-review.googlesource.com/684182 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#48231}
-
Predrag Rudic authored
Change-Id: Id2eef89f0eba3c59bcdb490e7d986b4b3af0ff9b Reviewed-on: https://chromium-review.googlesource.com/657677Reviewed-by:
Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com> Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com> Cr-Commit-Position: refs/heads/master@{#48230}
-
Marja Hölttä authored
Verify that both UTF-8 decoders (incremental and non-incremental one) match the expectations. Also cleanup / harden the UTF-8 handling code, as suggested in https://chromium-review.googlesource.com/c/v8/v8/+/671020/ . BUG=chromium:765608 Change-Id: I6344d62ca15b75ac8e333421c94c4aa35ab8190d Reviewed-on: https://chromium-review.googlesource.com/681217 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
-
