- 24 Oct, 2018 40 commits
-
-
Junliang Yan authored
R=joransiu@ca.ibm.com Change-Id: I154b3cac455d44a84f7d6363758841310010d749 Reviewed-on: https://chromium-review.googlesource.com/c/1296683 Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#56969}
-
Junliang Yan authored
R=joransiu@ca.ibm.com Change-Id: Ic9a6a9055e3f05ef64723d995228673ee48eb994 Reviewed-on: https://chromium-review.googlesource.com/c/1296682Reviewed-by:
-
Peter Marshall authored
This would allow SP to be a nonsense value, which would confuse the CPU profiler when the signal handler read the SP before it was restored. Bug: v8:8355 Change-Id: If108c8cf00467904fe0f4f26fddc2e3122afcd93 Reviewed-on: https://chromium-review.googlesource.com/c/1298032Reviewed-by:
Martyn Capewell <martyn.capewell@arm.com> Reviewed-by:
Alexei Filippov <alph@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#56967}
-
Toon Verwaest authored
This allows us to use one underlying buffer rather than 3, and allows memory to be freed as we're growing the vector. Change-Id: I45c178a31e8f6d3ee44d3319ce8bca2db2460d33 Reviewed-on: https://chromium-review.googlesource.com/c/1297328Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#56966}
-
Tom Tan authored
This is a reland of fcbb023b Original change's description: > Add Windows ARM64 ABI support to V8 > > This change added Windows ARM64 ABI support, major things are: > 1. Excluding x18 register from any usage because it is reserved as > platform register. Preserve alignment after the change. > 2. Fix the assumption of LP64 in arm64 backend. Windows ARM64 is > still LLP64. > 3. Stack guard page probe for large allocation on stack. > > Reference: > Windows ARM64 ABI: > https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2017 > > Bug: chromium:893460 > Change-Id: I325884ac8dab719154a0047141e18a9fcb8dff7e > Reviewed-on: https://chromium-review.googlesource.com/c/1285129 > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56881} CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_arm64_dbg_recipe TBR=mlippautz@chromium.org Bug: chromium:893460 Change-Id: Icc45fd091c33f7df805842a70236b79b14756f52 Reviewed-on: https://chromium-review.googlesource.com/c/1297300 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#56965}
-
Jakob Kummerow authored
This CL gives a first look at the new way to represent tagged object pointers in C++. It adds infrastructure in Handles and the garbage collector to deal with the new object type, and ports a first class to the new world. Design overview: https://goo.gl/Ph4CGz Bug: v8:3770 Change-Id: I3e37fbf399612f95540cb386710a595069fb9d55 Reviewed-on: https://chromium-review.googlesource.com/c/1292673Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Frank Tang authored
Add position to the return of %SegmentIterator%.next() which newly added to the spec in https://github.com/tc39/proposal-intl-segmenter/pull/42 Bug: v8:8305 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I8de7102acb670a6c529ab3e35601c78a8dc7703c Reviewed-on: https://chromium-review.googlesource.com/c/1278636Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Daniel Ehrenberg <littledan@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#56963}
-
Georg Neis authored
Bug: v8:7790 Change-Id: I14bac46ef7457ea142f79f96fc5a2018d429dcc8 Reviewed-on: https://chromium-review.googlesource.com/c/1297323 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56962}
-
Frank Tang authored
Remove TODO that is already done Uncomment two working tests. Bug: v8:5751 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Icb28d84e92812996c2928e90961d75508ba4c401 Reviewed-on: https://chromium-review.googlesource.com/c/1296933Reviewed-by:
-
Dan Elphick authored
Creates the hash_seed byte array in RO_SPACE and moves the root from STRONG_MUTABLE_IMMOVABLE_ROOT_LIST to STRONG_READ_ONLY_ROOT_LIST. Bug: v8:8191 Change-Id: I3b044fbb3e51eb5d21ac2e68a54076623865b9d2 Reviewed-on: https://chromium-review.googlesource.com/c/1297959 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
-
Aseem Garg authored
R=clemensh@chromium.org,kozyatinskiy@chromium.org Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ic6c7e2eaa4463d945d00eb1e1123d7d1731b34db Reviewed-on: https://chromium-review.googlesource.com/c/1297671Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Commit-Queue: Aseem Garg <aseemgarg@chromium.org> Cr-Commit-Position: refs/heads/master@{#56959}
-
Ross McIlroy authored
BuildClassBoilerplate accessed the native context to get the class_function_descriptors. Baseline compilation should be native context independent, so we shouldn't access the native context at all. As it happens, class_function_descriptors wasn't used so can just be removed. BUG=chromium:898076, v8:8041 Change-Id: If9c0edf3dfde68c76ea87820f9d4b080aac6d60e Reviewed-on: https://chromium-review.googlesource.com/c/1298033Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56958}
-
Caitlin Potter authored
There are several core changes in this stub: 1) add a version of KeyedStoreGenericGenerator::SetPropertyInLiteral() which supports indexed properties directly, witthout KeyedStore 2) add a code stub for SetPropertyInLiteral which uses the version supporting indexed properties 3) Use the code stub in CloneObjectIC, rather than using the smaller special-cased version which does not handle Names. Item 1) involves a refactoring which adds a nice way to reuse code in KeyedStoreGenericAssembler, which allows deleting a bunch of copy/pasted code. This makes it easy to reuse the index handling in KeyedStoreGeneric() without adding adding a bunch more duplicated handling. Because of this, I consider this to be somewhat of a cleanup, though if the copied code is preferred, I'm happy to revert to that. Item 2) is needed for Object.fromEntries(), as it's better to not require falling back to the slow path if a key happens to be an Smi --- but this is also optional. Item 3) benefits the codebase by allowing Object.fromEntries() to use this fast path without calling into the runtime, and without duplicating code which is also used by CloneObjectIC. I am skeptical that this should affect performance significantly. I've run ObjectLiteralSpread tests, and the mean of scores over 100 runs is somewhat surprising: CloneObjectIC --- the only user of this code, has an increased average score, while the polyfill cases score slightly worse --- However, the overall changes are small and likely flukes. The complete processed test output is below: ``` // Mean of 100 runs of each benchmark Babel-ObjectLiteralSpread: -----+---------------------------+---------------------------+------- | With patch | Without patch | diff Mean | 11530.87 | 12142.92 | -5.04% -----+---------------------------+---------------------------+------- BabelAndOverwrite-ObjectLiteralSpread: -----+---------------------------+---------------------------+------- | With patch | Without patch | diff Mean | 10881.41 | 11260.81 | -3.37% -----+---------------------------+---------------------------+------- ObjectAssign-ObjectLiteralSpread: -----+---------------------------+---------------------------+------- | With patch | Without patch | diff Mean | 6188.92 | 6358.55 | -2.67% -----+---------------------------+---------------------------+------- ObjectAssignAndOverwrite-ObjectLiteralSpread: -----+---------------------------+---------------------------+------- | With patch | Without patch | diff Mean | 6112.80 | 6275.54 | -1.61% -----+---------------------------+---------------------------+------- ObjectSpread-ObjectLiteralSpread: -----+---------------------------+---------------------------+------- | With patch | Without patch | diff Mean | 51942.93 | 50713.17 | +3.46% -----+---------------------------+---------------------------+------- ObjectSpreadAndOverwrite-ObjectLiteralSpread: -----+---------------------------+---------------------------+------- | With patch | Without patch | diff Mean | 51375.23 | 50833.29 | +2.09% -----+---------------------------+---------------------------+------- ``` BUG=v8:8238, v8:8021 R=ishell@chromium.org, jkummerow@chromium.org Change-Id: I43e102fc461ffd389b5d6810a73f86e5012d7dee Reviewed-on: https://chromium-review.googlesource.com/c/1277751 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#56957}
-
Toon Verwaest authored
Bug: v8:8365 Change-Id: Ie938073551bf1af6fb59ac1c395e7fabbcfdebd7 Reviewed-on: https://chromium-review.googlesource.com/c/1298034Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#56956}
-
Michael Starzinger authored
This adds back another register to the record write stub to have one additional register on top of the parameter register as allocation general purpose register. It has only been recently reduced to just four registers due to embedded builtins. This is needed to be able to tail call a record write stub. R=ulan@chromium.org CC=jgruber@chromium.org BUG=v8:8341 Change-Id: Id16f9e96d611a871fbe1180581eaf14275a7332e Reviewed-on: https://chromium-review.googlesource.com/c/1297955Reviewed-by:
-
Sathya Gunasekaran authored
Change-Id: I8ce540dcd1dd5384f96d1c47c9784fdfb0933c1e Reviewed-on: https://chromium-review.googlesource.com/c/1298029Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#56954}
-
Lei Zhang authored
GN should understand action outputs, so the header generated by the run_torque action do not need to be separately listed in another source_set. Change-Id: I309e8c012eb0a0597a247806d36658c1d6e5d97b Reviewed-on: https://chromium-review.googlesource.com/c/1297680Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Lei Zhang <thestig@chromium.org> Cr-Commit-Position: refs/heads/master@{#56953}
-
Hai Dang authored
Bug: v8:7980 Change-Id: Ic4c72b02c196b296105a6ddf9c3af9fb699ef8c5 Reviewed-on: https://chromium-review.googlesource.com/c/1297327Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Hai Dang <dhai@google.com> Cr-Commit-Position: refs/heads/master@{#56952}
-
Michael Starzinger authored
R=ulan@chromium.org BUG=v8:8238 Change-Id: Idf6b3d4035b392dd1b20ff3e4cbdb60cdaada054 Reviewed-on: https://chromium-review.googlesource.com/c/1297325Reviewed-by:
-
Jaroslav Sevcik authored
Bug: v8:5495, v8:8361 Change-Id: I7a03c7a4897b15112b978d232754076ad8753c4e Reviewed-on: https://chromium-review.googlesource.com/c/1297311Reviewed-by:
-
Sergiy Byelozyorov authored
R=machenbach@chromium.org No-Try: true No-Tree-Checks: true Bug: chromium:892433 Change-Id: Id323739be44ea55d73c712059520d7f5e684c97e Reviewed-on: https://chromium-review.googlesource.com/c/1280304Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
This changes the ReceiverOrOddball feedback on JSStrictEqual to ReceiverOrNullOrUndefined feedback, which can also safely be consumed by JSEqual (we cannot generally accept any oddball here since booleans trigger implicit conversions, unfortunately). Thus we replace the previously introduced CheckReceiverOrOddball with CheckReceiverOrNullOrUndefined, and drop CheckOddball, since we will no longer collect Oddball feedback separately. TurboFan will then turn a JSEqual[ReceiverOrNullOrUndefined] into a sequence like this: ``` left = CheckReceiverOrNullOrUndefined(left); right = CheckReceiverOrNullOrUndefined(right); result = if ObjectIsUndetectable(left) then ObjectIsUndetectable(right) else ReferenceEqual(left, right); ``` This significantly improves the peak performance of abstract equality with Receiver, Null or Undefined inputs. On the test case outlined in http://crbug.com/v8/8356 we go from naive: 2946 ms. tenary: 2134 ms. to naive: 2230 ms. tenary: 2250 ms. which corresponds to a 25% improvement on the abstract equality case. For regular code this will probably yield more performance, since we get rid of the JSEqual operator, which might have arbitrary side effects and thus blocks all kinds of TurboFan optimizations. The JSStrictEqual case is slightly slower now, since it has to rule out booleans as well (even though that's not strictly necessary, but consistency is key here). This way developers can safely use `a == b` instead of doing a dance like `a == null ? b == null : a === b` (which is what dart2js does right now) when both `a` and `b` are known to be Receiver, Null or Undefined. The abstract equality is not only faster to parse than the tenary, but also generates a shorter bytecode sequence. In the test case referenced in http://crbug.com/v8/8356 the bytecode for `naive` is ``` StackCheck Ldar a1 TestEqual a0, [0] JumpIfFalse [5] LdaSmi [1] Return LdaSmi [2] Return ``` which is 14 bytes, whereas the `tenary` function generates ``` StackCheck Ldar a0 TestUndetectable JumpIfFalse [7] Ldar a1 TestUndetectable Jump [7] Ldar a1 TestEqualStrict a0, [0] JumpIfToBooleanFalse [5] LdaSmi [1] Return LdaSmi [2] Return ``` which is 24 bytes. So the `naive` version is 40% smaller and requires fewer bytecode dispatches. Bug: chromium:898455, v8:8356 Change-Id: If3961b2518b4438700706b3bd6071d546305e233 Reviewed-on: https://chromium-review.googlesource.com/c/1297315Reviewed-by: -
Michael Achenbach authored
Also use low experiment percentage on CQ, since the builder's output is unused. NOTRY=true TBR=sergiyb@chromium.org Bug: chromium:830557 Change-Id: Id024ab16e2944ec5e94b0209672ed6b77ae322a8 Reviewed-on: https://chromium-review.googlesource.com/c/1296466Reviewed-by:
Sergiy Byelozyorov <sergiyb@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#56947}
-
peterwmwong authored
This is a reland of ec969ea3 Temporarily removes high memory usage test. Original change's description: > [builtins] Fix Array.p.join length overflow and invalid string length handling > > - Fixes and simplify allocating the temporary fixed array for ToString-ed elements. > - When the array size is greater than representable by an intptr, it overflowed into a negative value causing a non-negative assert to fail. > - Simplify fallback behavior by always allocating a conservatively sized temporary fixed array. Previously, if the array had dictionary elements, the temporary fixed array was sized based on %GetNumberDictionaryNumberOfElements() and then resized when entering the fallback. > > - Fixes related invalid string length handling. When the running total of the resulting string length overflowed or exceeded String::kMaxLength, a RangeError is thrown. Previously, this thrown RangeError bypassed JoinStackPop and left the receiver on the stack. > > Bug: chromium:897404 > Change-Id: I157b71ef04ab06125a5b1c3454e5ed3713bdb591 > Reviewed-on: https://chromium-review.googlesource.com/c/1293070 > Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56907} Bug: chromium:897404 Change-Id: I4995893f6f9724b26c231d05619ad65dbccc7223 Reviewed-on: https://chromium-review.googlesource.com/c/1297675Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Cr-Commit-Position: refs/heads/master@{#56946}
-
Daniel Clifford authored
TBR=tebbi@chromium.org NOTRY=true Change-Id: I2c5a1fc18efbbef7fd407000fa560bb75e5dc145 Reviewed-on: https://chromium-review.googlesource.com/c/1297324 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by:
Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56945}
-
Hai Dang authored
Previously StringToList use the length of the original string, which is not the right value: we expect the length of the new array to be the number of characters (codepoints). Bug: v8:7980 Change-Id: I2efca5715323c4399cb45c53871ae349207f3458 Reviewed-on: https://chromium-review.googlesource.com/c/1297320 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Toon Verwaest authored
This additionally optimizes ExpressionListToExpression in the parser to allocate Nary if possible. This allows us to drop unnecessary intermediate objects in the parser, and avoids all the work altogether in the preparser. Change-Id: I4a7d0ec3a28624c94ed85959d291e54eb81ffce3 Reviewed-on: https://chromium-review.googlesource.com/c/1297952 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
For implementing wasm GC we need to revisit all places where we hold WasmCode*. This CL reduces these places. R=mstarzinger@chromium.org Bug: v8:8217 Change-Id: I869e3c1817a3b9a24ab6aa281c0688bdf890dd33 Reviewed-on: https://chromium-review.googlesource.com/c/1297951Reviewed-by:
-
Hannes Payer authored
This is a reland of 1d837093 Original change's description: > [heap] Clean-up MemoryChunk allocation area constants. > > Change-Id: I8ba59546ab93c7af98bc5ece2f0160628844dd92 > Reviewed-on: https://chromium-review.googlesource.com/c/1280584 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Hannes Payer <hpayer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56908} Change-Id: I110b70ee5cb5609e54e24e17f183b8c6d6086b8a Reviewed-on: https://chromium-review.googlesource.com/c/1297318Reviewed-by:
-
Sigurd Schneider authored
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I44e62d53bc7b341a685eeca5691a86e915fcce44 Bug: v8:8344 Reviewed-on: https://chromium-review.googlesource.com/c/1292064Reviewed-by:
-
Toon Verwaest authored
This CL introduces a ScopedPtrList that's a view over an underlying ZonePtrList buffer. Whenever a ScopedPtrList is the top-of-stack list, you can add values through it, which will add them to the end of the buffer. Once the list is done, you can copy out the values to a real ZonePtrList. That way you do not need to guess what the required size of the list is, and you get better cache locality. Change-Id: I2d229d73bb25bbb450ae5b6767ab100abad2b3a3 Reviewed-on: https://chromium-review.googlesource.com/c/1296458 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56939}
-
Clemens Hammacher authored
Because of ordering issues we didn't set the wire bytes on the {NativeModule} during {OnFinishedStream}. We then failed during instantiation when trying to read the import names from the wire bytes. This CL fixes this locally without much code churn. I plan to clean up the interaction between {AsyncCompileJob} and {AsyncStreamingProcessor} in a follow-up CL. R=ahaas@chromium.org Bug: chromium:898310 Change-Id: I06337a04ba380f87b803f325323208298d363f41 Reviewed-on: https://chromium-review.googlesource.com/c/1296467Reviewed-by:Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56938}
-
Daniel Clifford authored
Change-Id: Id5e25509cba272083caee62a1ae7420f77f3fa50 Reviewed-on: https://chromium-review.googlesource.com/c/1297949Reviewed-by:
Mathias Bynens <mathias@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56937}
-
Clemens Hammacher authored
In order to not confuse this with wasm memory. R=mstarzinger@chromium.org Bug: v8:8238 Change-Id: Ife183162a902ab1d141f6af95a9fa487a52379a1 Reviewed-on: https://chromium-review.googlesource.com/c/1296483 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Mathias Bynens authored
Spec: https://tc39.github.io/ecma262/#sec-array.of Note that the `IsConstructor` abstract operation [1] is implemented as a `typeswitch`. [1] https://tc39.github.io/ecma262/#sec-isconstructor Bug: v8:8321 Change-Id: I17af918c1d928faf8a630b35432876baa96da217 Reviewed-on: https://chromium-review.googlesource.com/c/1296464Reviewed-by:
-
Michael Achenbach authored
NOTRY=true TBR=sergiyb@chromium.org Bug: v8:8291 Change-Id: I47445d10bd19beeacc90321e9177f0959b3b2f13 Reviewed-on: https://chromium-review.googlesource.com/c/1297316 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
Mathias Bynens authored
Change-Id: I2dbcd318b5ca1c40d0e76cb0316b275bf1b75589 Reviewed-on: https://chromium-review.googlesource.com/c/1296465Reviewed-by:
-
Michael Lippautz authored
Change-Id: Ibfb53be508930046c90fb01bc05615eef3ec79c7 Reviewed-on: https://chromium-review.googlesource.com/c/1297314Reviewed-by:
-
Tobias Tebbi authored
This was fixed when introducing the IR. Bug: v8:8216 Change-Id: Iebb212a2c21499b1738832457b660038e3a48975 Reviewed-on: https://chromium-review.googlesource.com/c/1297313Reviewed-by:
-
Dan Elphick authored
This is a reland of https://chromium-review.googlesource.com/c/v8/v8/+/1276468, without the change "Also forces all non-trampoline RelocInfo ByteArrays for builtins to be generated into RO_SPACE." Creates a single RelocInfo to be used by all builtin trampolines and stores it as a root. All trampolines then substitute this for their trampoline at generation time with DCHECKs to make sure it is identical. On x64, this results in the OLD_SPACE part of the startup snapshot decreasing in size from 165656 to 130808 (-34848) bytes and RO_SPACE (in the read-only snapshot) increasing from 31248 to 31272 (+24) bytes. Bug: v8:8295 Change-Id: I0dee7dfaccd9b8025d7707b0bb90194173f1ee89 Reviewed-on: https://chromium-review.googlesource.com/c/1296459 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
-
