- 03 Aug, 2016 1 commit
-
-
caitp authored
BUG=v8:5162 R=bmeurer@chromium.org, cbruni@chromium.org Review-Url: https://codereview.chromium.org/2205883003 Cr-Commit-Position: refs/heads/master@{#38266}
-
- 02 Aug, 2016 1 commit
-
-
machenbach authored
Revert of [builtins] implement Array.prototype.includes in TurboFan (patchset #20 id:380001 of https://codereview.chromium.org/2146293003/ ) Reason for revert: [Sheriff] Breaks: https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20builder/builds/2592 Original issue's description: > [builtins] implement Array.prototype.includes in TurboFan > > BUG=v8:5162 > R=bmeurer@chromium.org, ishell@chromium.org > > Committed: https://crrev.com/a488b5d8eb111a4883dc400bd826d079420edd68 > Cr-Commit-Position: refs/heads/master@{#38223} TBR=adamk@chromium.org,bmeurer@chromium.org,cbruni@chromium.org,danno@chromium.org,ishell@chromium.org,littledan@chromium.org,caitp@igalia.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5162 Review-Url: https://codereview.chromium.org/2202163002 Cr-Commit-Position: refs/heads/master@{#38226}
-
- 01 Aug, 2016 1 commit
-
-
caitp authored
BUG=v8:5162 R=bmeurer@chromium.org, ishell@chromium.org Review-Url: https://codereview.chromium.org/2146293003 Cr-Commit-Position: refs/heads/master@{#38223}
-
- 19 Jul, 2016 1 commit
-
-
bmeurer authored
Introduce a proper CodeStubAssembler::BranchIfToBooleanIsTrue helper method, that branches to if_true/if_false labels depending on whether the value that is passed would yield true or false when fed to ToBoolean. Use this helper to implement the bytecode handlers w/o having to materialize the temporary booleans and essentially branching twice. The CodeStubAssembler::BranchIfToBooleanIsTrue helper favors the most likely case of a Boolean constant now. Also migrate the ToBooleanStub to a ToBoolean TurboFan builtin, that also uses the helper method under the hood. Remove the now obsolete Oddball::to_boolean field. R=hpayer@chromium.org, rmcilroy@chromium.org, yangguo@chromium.org Review-Url: https://codereview.chromium.org/2151163002 Cr-Commit-Position: refs/heads/master@{#37849}
-
- 18 Jul, 2016 1 commit
-
-
jochen authored
I want to use those methods from ApiNatives so move them to a shared location. BUG= R=verwaest@chromium.org Review-Url: https://codereview.chromium.org/2156153002 Cr-Commit-Position: refs/heads/master@{#37843}
-
- 14 Jul, 2016 1 commit
-
-
bmeurer authored
This adds initial support for ToPrimitive in JavaScript w/o having to call out to C++. This uses the newly introduced GetPropertyStub. R=ishell@chromium.org Review-Url: https://codereview.chromium.org/2152693002 Cr-Commit-Position: refs/heads/master@{#37753}
-
- 12 Jul, 2016 1 commit
-
-
mtrofin authored
To correctly support instantiating a compiled module multiple times, we clone the compiled module each time we create an instance, since some of the data is specific to the instance - e.g. export code, wasm functions, indirect table. BUG=v8:5072 Review-Url: https://codereview.chromium.org/2134593002 Cr-Commit-Position: refs/heads/master@{#37692}
-
- 07 Jul, 2016 1 commit
-
-
jochen authored
Such an object can be used to later create a context from it. It has to have access checks with handlers enabled, as it cannot be accessed otherwise. BUG=chromium:618305 R=verwaest@chromium.org Review-Url: https://codereview.chromium.org/2107673003 Cr-Commit-Position: refs/heads/master@{#37594}
-
- 28 Jun, 2016 1 commit
-
-
neis authored
R=adamk@chromium.org BUG= Review-Url: https://codereview.chromium.org/2081733004 Cr-Commit-Position: refs/heads/master@{#37311}
-
- 27 Jun, 2016 2 commits
-
-
machenbach authored
Revert of Refactor CreateApiFunction (patchset #2 id:20001 of https://codereview.chromium.org/2095953002/ ) Reason for revert: [Sheriff] Changes a layout test. Please rebase upstream if intended: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/7742 Original issue's description: > Refactor CreateApiFunction > > BUG= > > Committed: https://crrev.com/705574970f3899a6eda0c61130c8c31693df4039 > Cr-Commit-Position: refs/heads/master@{#37290} TBR=jochen@chromium.org,verwaest@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= Review-Url: https://codereview.chromium.org/2099983004 Cr-Commit-Position: refs/heads/master@{#37299}
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2095953002 Cr-Commit-Position: refs/heads/master@{#37290}
-
- 24 Jun, 2016 1 commit
-
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2095673002 Cr-Commit-Position: refs/heads/master@{#37252}
-
- 15 Jun, 2016 1 commit
-
-
jgruber authored
The Vector type is deprecated, and new code should use ZoneVector instead. This new overload of NewStringFromTwoByte will be used in an upcoming regexp CL. R=bmeurer@chromium.org BUG= Review-Url: https://codereview.chromium.org/2065053002 Cr-Commit-Position: refs/heads/master@{#36985}
-
- 19 May, 2016 1 commit
-
-
yangguo authored
The cached resource data pointer is a source of non-determinism when creating the snapshot. Long-term we may not keep the native source in memory anyways, so caching the resource data pointer will not be possible. R=ulan@chromium.org BUG=v8:4886 LOG=N Review-Url: https://codereview.chromium.org/1990183002 Cr-Commit-Position: refs/heads/master@{#36361}
-
- 14 May, 2016 1 commit
-
-
franzih authored
Rewrite encodeURI as runtime function. We well probably repackage runtime_URIEncode as a C++ builtin. BUG=v8:4912 R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/1968953002 Cr-Commit-Position: refs/heads/master@{#36257}
-
- 06 Apr, 2016 1 commit
-
-
verwaest authored
The previous code cache system required stubs to be marked with a StubType, causing them to be inserted either into a fixed array or into a dictionary-mode code cache. This could cause names to be in both cases, and lookup would just find the "fast" one first. Given that we clear out the caches on each GC, the memory overhead shouldn't be too bad. Additionally, the dictionary itself should just stay linear for small arrays; that's faster anyway. This CL additionally deletes some dead IC code. BUG= Review URL: https://codereview.chromium.org/1846963002 Cr-Commit-Position: refs/heads/master@{#35291}
-
- 05 Apr, 2016 1 commit
-
-
yangguo authored
If we use ScopeIterator inside a debug-evaluate call, we may iterate over a debug-evaluate context that we created for the debug-evaluate call. This may trigger assertions. The solution is to have the ScopeIterator hide debug-evaluate contexts by unwrapping it if it comes across any. R=cbruni@chromium.org BUG=chromium:599662 LOG=N Review URL: https://codereview.chromium.org/1859033002 Cr-Commit-Position: refs/heads/master@{#35258}
-
- 31 Mar, 2016 1 commit
-
-
yangguo authored
R=bmeurer@chromium.org, cbruni@chromium.org, ulan@chromium.org BUG=chromium:124206,chromium:569811 LOG=N Review URL: https://codereview.chromium.org/1834633003 Cr-Commit-Position: refs/heads/master@{#35145}
-
- 18 Mar, 2016 1 commit
-
-
mstarzinger authored
This changes the compilation pipeline so that SharedFunctionInfo objects are always allocated before the various compilers are invoked. It is a preparation towards having that object available during compile time and hence reducing the dependency on FunctionLiteral and the need to copy a lot of the information into the CompilationInfo. Optimizing compilers already assume the SharedFunctionInfo is present and the baseline compilers have other heap accesses sprinkled throughout the compilation process. Duplicating statically available information from the SharedFunctionInfo within the CompilationInfo has no benefit. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1813803002 Cr-Commit-Position: refs/heads/master@{#34885}
-
- 01 Mar, 2016 1 commit
-
-
mstarzinger authored
R=bmeurer@chromium.org BUG=v8:3956 LOG=n Review URL: https://codereview.chromium.org/1731063007 Cr-Commit-Position: refs/heads/master@{#34398}
-
- 29 Feb, 2016 1 commit
-
-
bmeurer authored
Rename the existing (patching) ToBooleanStub to ToBooleanICStub to match our naming convention, and add a new TurboFan-powered ToBooleanStub, which just does the ToBoolean conversion without any runtime call or code patching, so we can use it for Ignition (and TurboFan). Drive-by-fix: Add an Oddball::to_boolean field similar to the ones we already have for to_string and to_number, so we don't need to actually dispatch on the concrete Oddball at all. R=epertoso@chromium.org, rmcilroy@chromium.org, yangguo@chromium.org Review URL: https://codereview.chromium.org/1744163002 Cr-Commit-Position: refs/heads/master@{#34361}
-
- 22 Feb, 2016 1 commit
-
-
yangguo authored
R=mstarzinger@chromium.org, rmcilroy@chromium.org BUG=v8:4690 LOG=N Review URL: https://codereview.chromium.org/1703453002 Cr-Commit-Position: refs/heads/master@{#34190}
-
- 18 Feb, 2016 1 commit
-
-
verwaest authored
BUG= Review URL: https://codereview.chromium.org/1704353002 Cr-Commit-Position: refs/heads/master@{#34118}
-
- 11 Feb, 2016 1 commit
-
-
verwaest authored
[runtime/heap] Introduce CopyFixedArrayUpTo to match CopyFixedArrayAndGrow, copying to a smaller array. This allows the helper to avoid write barriers while copying, speeding up Object.keys by 5-10%. BUG= Review URL: https://codereview.chromium.org/1690953002 Cr-Commit-Position: refs/heads/master@{#33916}
-
- 08 Feb, 2016 1 commit
-
-
bmeurer authored
It's fine to use JS_OBJECT_TYPE for JSIteratorResult and only have a preallocated initial map for them to avoid unnecessary polymorphism from generators / builtin iterators. The instance type doesn't provide any advantage, since we always have to treat JSIteratorResult objects as regular JSObjects later. R=yangguo@chromium.org TBR=hpayer@chromium.org Review URL: https://codereview.chromium.org/1680513002 Cr-Commit-Position: refs/heads/master@{#33800}
-
- 05 Feb, 2016 1 commit
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ ) Reason for revert: Must revert for now due to chromium api natives issues. Original issue's description: > Type Feedback Vector lives in the closure > > (RELAND: the problem before was a missing write barrier for adding the code > entry to the new closure. It's been addressed with a new macro instruction > and test. The only change to this CL is the addition of two calls to > __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. > And Benedikt reviewed it as well. > > TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org > > BUG= > > Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5 > Cr-Commit-Position: refs/heads/master@{#33741} TBR=bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1670813005 Cr-Commit-Position: refs/heads/master@{#33766}
-
- 04 Feb, 2016 1 commit
-
-
mvstanton authored
(RELAND: the problem before was a missing write barrier for adding the code entry to the new closure. It's been addressed with a new macro instruction and test. The only change to this CL is the addition of two calls to __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. And Benedikt reviewed it as well. TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1668103002 Cr-Commit-Position: refs/heads/master@{#33741}
-
- 29 Jan, 2016 1 commit
-
-
jkummerow authored
String wrappers (new String("foo")) are special objects: their string characters are accessed like elements, and they also have an elements backing store. This used to require a bunch of explicit checks like: if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) { /* Handle string characters */ } // Handle regular elements (for string wrappers and other objects) obj->GetElementsAccessor()->Whatever(...); This CL introduces new ElementsKinds for string wrapper objects (one for fast elements, one for dictionary elements), which allow folding the special-casing into new StringWrapperElementsAccessors. No observable change in behavior is intended. Review URL: https://codereview.chromium.org/1612323003 Cr-Commit-Position: refs/heads/master@{#33616}
-
- 27 Jan, 2016 2 commits
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ ) Reason for revert: Bug: failing to use write barrier when writing code entry into closure. Original issue's description: > Reland of Type Feedback Vector lives in the closure > > (Fixed a bug found by nosnap builds.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > > TBR=hpayer@chromium.org > BUG= > > Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1 > Cr-Commit-Position: refs/heads/master@{#33548} TBR=bmeurer@chromium.org,yangguo@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1643533003 Cr-Commit-Position: refs/heads/master@{#33556}
-
mvstanton authored
(Fixed a bug found by nosnap builds.) We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... TBR=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1642613002 Cr-Commit-Position: refs/heads/master@{#33548}
-
- 26 Jan, 2016 2 commits
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ ) Reason for revert: FAilure on win32 bot, need to investigate webkit failures. Original issue's description: > Type Feedback Vector lives in the closure > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > > TBR=hpayer@chromium.org > > BUG= > > Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4 > Cr-Commit-Position: refs/heads/master@{#33518} TBR=bmeurer@chromium.org,akos.palfi@imgtec.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1632993003 Cr-Commit-Position: refs/heads/master@{#33520}
-
mvstanton authored
We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... TBR=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1563213002 Cr-Commit-Position: refs/heads/master@{#33518}
-
- 18 Jan, 2016 1 commit
-
-
verwaest authored
Review URL: https://codereview.chromium.org/1600353003 Cr-Commit-Position: refs/heads/master@{#33364}
-
- 14 Jan, 2016 1 commit
-
-
jkummerow authored
As luck would have it, there doesn't seem to be a way to trigger observable misbehavior currently (only with special flags). BUG=chromium:380671 LOG=n R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/1588013002 Cr-Commit-Position: refs/heads/master@{#33305}
-
- 27 Dec, 2015 2 commits
-
-
bmeurer authored
According to the ES2015 specification, bound functions are exotic objects, and thus don't need to be implemented as JSFunctions. So we introduce a new JSBoundFunction type to represent bound functions and make them optimizable. This already improves the performance of calling or constructing bound functions by 10-100x depending on the use case because we avoid the crazy dance between JavaScript and C++ that was implemented in v8natives.js previously. There's still room for improvement in the performance of actually creating bound functions, which is also relevant in practice, but we already have a plan how to accomplish that later. The mips/mips64 ports were contributed by akos.palfi@imgtec.com. CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel BUG=chromium:535408, chromium:571299, v8:4629 LOG=n Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2 Cr-Commit-Position: refs/heads/master@{#33042} Review URL: https://codereview.chromium.org/1542963002 Cr-Commit-Position: refs/heads/master@{#33044}
-
bmeurer authored
Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound functions. (patchset #14 id:260001 of https://codereview.chromium.org/1542963002/ ) Reason for revert: Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind Original issue's description: > [runtime] Introduce dedicated JSBoundFunction to represent bound functions. > > According to the ES2015 specification, bound functions are exotic > objects, and thus don't need to be implemented as JSFunctions. So > we introduce a new JSBoundFunction type to represent bound functions > and make them optimizable. This already improves the performance of > calling or constructing bound functions by 10-100x depending on the > use case because we avoid the crazy dance between JavaScript and C++ > that was implemented in v8natives.js previously. > > There's still room for improvement in the performance of actually > creating bound functions, which is also relevant in practice, but > we already have a plan how to accomplish that later. > > The mips/mips64 ports were contributed by akos.palfi@imgtec.com. > > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel > BUG=chromium:535408, chromium:571299, v8:4629 > LOG=n > > Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2 > Cr-Commit-Position: refs/heads/master@{#33042} TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:535408, chromium:571299, v8:4629 Review URL: https://codereview.chromium.org/1552473002 Cr-Commit-Position: refs/heads/master@{#33043}
-
- 26 Dec, 2015 1 commit
-
-
bmeurer authored
According to the ES2015 specification, bound functions are exotic objects, and thus don't need to be implemented as JSFunctions. So we introduce a new JSBoundFunction type to represent bound functions and make them optimizable. This already improves the performance of calling or constructing bound functions by 10-100x depending on the use case because we avoid the crazy dance between JavaScript and C++ that was implemented in v8natives.js previously. There's still room for improvement in the performance of actually creating bound functions, which is also relevant in practice, but we already have a plan how to accomplish that later. The mips/mips64 ports were contributed by akos.palfi@imgtec.com. CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel BUG=chromium:535408, chromium:571299, v8:4629 LOG=n Review URL: https://codereview.chromium.org/1542963002 Cr-Commit-Position: refs/heads/master@{#33042}
-
- 08 Dec, 2015 1 commit
-
-
cbruni authored
BUG=v8:1543 LOG=N Review URL: https://codereview.chromium.org/1499593003 Cr-Commit-Position: refs/heads/master@{#32675}
-
- 04 Dec, 2015 1 commit
-
-
cbruni authored
BUG=v8:1543 LOG=N Review URL: https://codereview.chromium.org/1496503002 Cr-Commit-Position: refs/heads/master@{#32616}
-
- 03 Dec, 2015 1 commit
-
-
hpayer authored
Reland of Introduce instance type for transition arrays. (patchset #1 id:1 of https://codereview.chromium.org/1483003002/ ) Reason for revert: Suspect for crashing found, relanding for canary coverage. Original issue's description: > Revert of Introduce instance type for transition arrays. (patchset #6 id:100001 of https://codereview.chromium.org/1480873003/ ) > > Reason for revert: > Broken canary. Trying to find out root cause. > > Original issue's description: > > Introduce instance type for transition arrays. > > > > The motivation is to allow specialized marking visitor for transition arrays and collect all transition array in a list for post-processing in ClearNonLiveReferences. > > > > BUG=chromium:554488 > > LOG=NO > > > > Committed: https://crrev.com/026095a3c7932573e1810b8064ec3008ed696601 > > Cr-Commit-Position: refs/heads/master@{#32396} > > TBR=mlippautz@chromium.org,jkummerow@chromium.org,ulan@chromium.org > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=chromium:554488 > > Committed: https://crrev.com/38bf70b9cd2a07b99ac0c0b7eda111849e79c146 > Cr-Commit-Position: refs/heads/master@{#32404} TBR=mlippautz@chromium.org,jkummerow@chromium.org,ulan@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:554488 Review URL: https://codereview.chromium.org/1500623002 Cr-Commit-Position: refs/heads/master@{#32561}
-