- 23 Aug, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
- simplify prototype traversal. - use V8InspectorClient::isInspectableHeapObject since some embedders on JavaScript heap contains not inspectable objects, e.g. wrapper boilerplates in blink. - Runtime.queryObjects takes prototype object as argument for more flexibility. R=alph@chromium.org Bug: v8:6732 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I06f0d5c987150c80c3e9b05e7f6ad195985fc539 Reviewed-on: https://chromium-review.googlesource.com/627577 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#47559}
-
- 21 Aug, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
Runtime.queryObjects method: 1. force gc, 2. iterate through heap and get all objects with passed constructorName or with passed constructor name in prototype chain, 3. return these objects as JSArray. Main use case is regression tests for memory leaks. R=pfeldman@chromium.org,alph@chromium.org,ulan@chromium.org Bug: v8:6732 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I52f0803366f14bb24376653615d870a4f21f83e7 Reviewed-on: https://chromium-review.googlesource.com/619594Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Alexei Filippov <alph@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Pavel Feldman <pfeldman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47478}
-
- 02 Aug, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
My goal was to move breakpoint API to native with minimal changes around, so on inspector side we use v8::debug::BreakpointId instead of String16, on v8::internal::Debug we use i::BreakPoint object instead of break point object created inside of debug.js. There are a lot of opportunities how we can improve breakpoints (at least we can avoid some of linear lookups to speedup implementation) but I think that as first step we need to remove mirrors/debug.js APIs. Drive by: debugger-script.js and usage of debugger context in inspector code base. R=yangguo@chromium.org,jgruber@chromium.org,clemensh@chromium.org Bug: v8:5510,chromium:652939 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I0b17972c39053dd4989bbe26db2bb0b88ca378f7 Reviewed-on: https://chromium-review.googlesource.com/593156Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47091}
-
- 31 Jul, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
This call from inspector side is redundant, V8 will clear all breakpoints on removing debug delegate in v8::internal::Debug::Unload method. In any case for correct support of multiclient we need to clear breakpoints in V8DebuggerAgentImpl::disable method. R=dgozman@chromium.org Bug: v8:5510,chromium:652939 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I66f9b97797860bad28884a099928d54ac3560428 Reviewed-on: https://chromium-review.googlesource.com/592281 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#47022}
-
- 28 Jul, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
To avoid using debugging context and debugger-script.js on inspector side we can move SetScriptSource call to v8::internal::Debug. Theoretically we can move live edit implementation to native completely but since it will be reimplemented it looks redundant. R=yangguo@chromium.org,jgruber@chromium.org Bug: chromium:652939 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Id09492c2d2a93efbde429c9cc1bc181d5fdda19b Reviewed-on: https://chromium-review.googlesource.com/590736 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46985}
-
- 27 Jul, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
This CL moves us much closer to the point where we can remove debugger-script.js and usage of debugger context from inspector. There are three main parts left: - managing breakpoints, - inspecting stack and scopes (this CL), - LiveEdit. In this CL I moved all stack/scope inspection to native. As side effect running debugger and inspector tests are 10-20% faster (it's significant since not all of tests requesting break). R=yangguo@chromium.org,jgruber@chromium.org Bug: chromium:652939 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I409396a687e18e9c0554c0c9c35b6e1064627be8 Reviewed-on: https://chromium-review.googlesource.com/580645Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46947}
-
- 07 Jun, 2017 1 commit
-
-
dgozman authored
... as opposite to a global per-isolate one. Also streamlined multiple checks into a single acceptsPause() method. BUG=chromium:590878 Review-Url: https://codereview.chromium.org/2925903002 Cr-Commit-Position: refs/heads/master@{#45749}
-
- 06 Jun, 2017 1 commit
-
-
dgozman authored
... when trying to resume or step. BUG=none Review-Url: https://codereview.chromium.org/2923243002 Cr-Commit-Position: refs/heads/master@{#45747}
-
- 05 Jun, 2017 1 commit
-
-
dgozman authored
Instead of going through debugger agent, this patch implements console.assert pause similar to debugger statement and OOM break. New test uncovered a bug, where pause on exceptions state mix up between different context groups. Added a TODO to fix it. BUG=chromium:590878 Review-Url: https://codereview.chromium.org/2916363002 Cr-Commit-Position: refs/heads/master@{#45711}
-
- 01 Jun, 2017 1 commit
-
-
dgozman authored
This patch adds ability to connect multiple sessions to a single context group. This is an experimental feature, which is already supported in test harness. So far covered runtime domain with tests (and found a bug thanks to the test). More tests to follow in next patches, probably with code adjustments as well. BUG=chromium:590878 Review-Url: https://codereview.chromium.org/2906153002 Cr-Commit-Position: refs/heads/master@{#45667}
-
- 16 May, 2017 2 commits
-
-
kozyatinskiy authored
By default we just break when we first time reach passed location, with current - we'll break at passed location only when it happens within the same stack frame. BUG=v8:6397 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2879923003 Cr-Commit-Position: refs/heads/master@{#45354}
-
kozyatinskiy authored
So continue to location can be called only for one context group id at the same time. BUG=v8:6397 Review-Url: https://codereview.chromium.org/2882213004 Cr-Commit-Position: refs/heads/master@{#45349}
-
- 25 Apr, 2017 2 commits
-
-
kozyatinskiy authored
We should be ready for gone agent. BUG=chromium:714819 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2842903002 Cr-Commit-Position: refs/heads/master@{#44874}
-
kozyatinskiy authored
- introduced pausedContextGroupId, - added targetContextGroupId param for V8Debugger::continueProgram method. BUG=chromium:714955 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2842733002 Cr-Commit-Position: refs/heads/master@{#44871}
-
- 20 Apr, 2017 4 commits
-
-
kozyatinskiy authored
BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2826183002 Cr-Commit-Position: refs/heads/master@{#44755}
-
kozyatinskiy authored
Since we already have cache on V8 side we can introduce caching on inspector side. It will decrease memory consumption and reduce time which we spend for collecting stacks. See [1] for details. [1] https://docs.google.com/a/google.com/document/d/13H1Pn6dekcwqlaYP26CfyyYGuL-U9LtUPWmt3TIpOag/edit?usp=sharing BUG=v8:6189 R=dgozman@chromium.org,yangguo@chromium.org Review-Url: https://codereview.chromium.org/2825903002 Cr-Commit-Position: refs/heads/master@{#44753}
-
kozyatinskiy authored
With recent CLs we always store maximum N async stack traces and when we reach limit we drop half of them. Current promise collected event requires creating weak handle: - it takes time, - it consumes memory. Since async task id distribution for promises is uniform (each new promise has last_async_task_id + 1 as an id) our hash map is good enough to handle any amount of async task ids, following time of executing 1 000 000 000 of lookups: - for empty hash map: 1.45 seconds, - for hash map with one entry: 14.95 seconds - 1024 entries: 15.03 seconds - 1024 * 1024 entries: 14.82 seconds - 1024 * 1024 * 1024: 17.9 seconds BUG=v8:6189 R=dgozman@chromium.org,yangguo@chromium.org Review-Url: https://codereview.chromium.org/2819423005 Cr-Commit-Position: refs/heads/master@{#44750}
-
kozyatinskiy authored
- and reduce limit to 128 * 1024. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2824293002 Cr-Commit-Position: refs/heads/master@{#44735}
-
- 18 Apr, 2017 3 commits
-
-
kozyatinskiy authored
- separated V8StackTraceImpl and AsyncStackTrace, - V8Debugger owns all AsyncStackTrace and cleanup half of them when limit is reached (first created - first cleaned), - V8StackTraceImpl, AsyncStackTrace and async-task-related tables in V8Debugger have weak reference to other async stack traces. - async tasks are cleared with related async stacks. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2816043006 Cr-Original-Commit-Position: refs/heads/master@{#44670} Committed: https://chromium.googlesource.com/v8/v8/+/1bca73bc832c645138bd3e0306fcaa8bb44dad04 Review-Url: https://codereview.chromium.org/2816043006 Cr-Commit-Position: refs/heads/master@{#44694}
-
machenbach authored
Revert of [inspector] avoid cloning of async call chains (patchset #7 id:120001 of https://codereview.chromium.org/2816043006/ ) Reason for revert: Speculative revert. Seems to block the roll: https://codereview.chromium.org/2822983004/ Might require changing a browser test first? Original issue's description: > [inspector] avoid cloning of async call chains > > - separated V8StackTraceImpl and AsyncStackTrace, > - V8Debugger owns all AsyncStackTrace and cleanup half of them when limit is reached (first created - first cleaned), > - V8StackTraceImpl, AsyncStackTrace and async-task-related tables in V8Debugger have weak reference to other async stack traces. > - async tasks are cleared with related async stacks. > > BUG=v8:6189 > R=dgozman@chromium.org > > Review-Url: https://codereview.chromium.org/2816043006 > Cr-Commit-Position: refs/heads/master@{#44670} > Committed: https://chromium.googlesource.com/v8/v8/+/1bca73bc832c645138bd3e0306fcaa8bb44dad04 TBR=dgozman@chromium.org,kozyatinskiy@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6189 Review-Url: https://codereview.chromium.org/2825713002 Cr-Commit-Position: refs/heads/master@{#44678}
-
kozyatinskiy authored
- separated V8StackTraceImpl and AsyncStackTrace, - V8Debugger owns all AsyncStackTrace and cleanup half of them when limit is reached (first created - first cleaned), - V8StackTraceImpl, AsyncStackTrace and async-task-related tables in V8Debugger have weak reference to other async stack traces. - async tasks are cleared with related async stacks. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2816043006 Cr-Commit-Position: refs/heads/master@{#44670}
-
- 17 Apr, 2017 1 commit
-
-
kozyatinskiy authored
Inspector doesn't use debugger context and this entering only slow down our async instrumentation. BUG=v8:6189 R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2816373004 Cr-Commit-Position: refs/heads/master@{#44665}
-
- 12 Apr, 2017 1 commit
-
-
kozyatinskiy authored
We currently store it in parent stack trace but stacks with the same parent can have different creations stacks. BUG=v8:6189 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2807273002 Cr-Commit-Position: refs/heads/master@{#44624}
-
- 30 Mar, 2017 1 commit
-
-
kozyatinskiy authored
BUG=chromium:432469 R=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2746743002 Cr-Commit-Position: refs/heads/master@{#44270}
-
- 22 Mar, 2017 1 commit
-
-
kozyatinskiy authored
Indisputable profit: - correct break location in next task (see tests), - stepOver with async await never lands in random code (see related test and issue), - inspector doesn't store current stepping state in debugger agent and completely trust V8 - step to new inspector-V8 design (I will finish design doc soon). - willExecuteScript and didExecuteScript instrumentation could be removed from code base - reduce probability of future errors. - finally - less code, - stepping implementation in V8 makes another step to follow our stepping strategy (stepOut should do stepInto and break when exit current frame) (another one one page design doc based on @aandrey comment is coming), - knowledge about existing of context groups is still inspector-only. Disputable part is related to super rare scenario when in single isolate we have more then one context group id with enabled debugger agent: - if one agent request break in own context (stepping, pause, e.t.c.) then we ignore all breaks in another agent. From one hand it looks like good: user clicks stepInto and they don't expect that execution could be paused by another instance of DevTools in unobservable from current DevTools way (second DevTools will get paused notification and run nested message loop). From another hand we shouldn't ignore breakpoints or debugger statement never. In general, I think that proposed behavior is rathe feature then issue. - and disadvantage, on attempt to break in non-target context group id we just call StepOut until reach target context group id, step out call could deoptimize code in non related to current debugger agent context. But break could happens only in case of debugger stmt or breakpoint - sound like minor issue. Ignoring break on exception sounds like real issue but by module of rareness of this case I think we can ignore this. Implementation details: - when debugger agent request break for any reason it passes target context group id to V8Debugger - last agent requesting break is preferred. - when V8Debugger gets BreakProgramRequested notification from V8, it checks current context group id against target context group id, if they match then just process break as usual otherwise makes StepOut action, - debug.cc at the end of microtask if last_scheduled_action is StepOut, schedules StepIn and will break on first instruction in next task. BUG=chromium:654022 R=dgozman@chromium.org,yangguo@chromium.org Review-Url: https://codereview.chromium.org/2748503002 Cr-Commit-Position: refs/heads/master@{#44034}
-
- 13 Mar, 2017 1 commit
-
-
kozyatinskiy authored
We emulate break by callling breakProgramCallback function in debugger context, we can just use HandleDebugBreak. It allows us to move all stepping logic to debug.cc later and remove one usage of debugger context. + two minor issues fixed, see tests. BUG=v8:5510 R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2738503006 Cr-Commit-Position: refs/heads/master@{#43750}
-
- 06 Mar, 2017 1 commit
-
-
kozyatinskiy authored
This method could be called on pause and will do stepInto next scheduled callback if any will happen until next break. First implementation support only callbacks chained by Promise.prototype.then. BUG=chromium:432469 R=yangguo@chromium.org,dgozman@chromium.org Review-Url: https://codereview.chromium.org/2723273002 Cr-Commit-Position: refs/heads/master@{#43616}
-
- 09 Feb, 2017 1 commit
-
-
yangguo authored
R=jgruber@chromium.org BUG=v8:5530 Review-Url: https://codereview.chromium.org/2682593003 Cr-Commit-Position: refs/heads/master@{#43059}
-
- 07 Feb, 2017 2 commits
-
-
kozyatinskiy authored
- removed getGeneratorObjectLocation from debugger-script.js, - one more step to remove all debugger context usages in inspector. BUG=v8:5510 R=yangguo@chromium.org,jgruber@chromium.org,alph@chromium.org Review-Url: https://codereview.chromium.org/2678143002 Cr-Commit-Position: refs/heads/master@{#43018}
-
kozyatinskiy authored
- entries preview available even if debugger agent is disabled, - less deprecated mirrors usage in debugger-script.js - no usage of debugger context - zero probability of leaking it. - better test coverage. BUG=v8:5510 R=yangguo@chromium.org,jgruber@chromium.org,alph@chromium.org,luoe@chromium.org Review-Url: https://codereview.chromium.org/2672213002 Cr-Commit-Position: refs/heads/master@{#42978}
-
- 03 Feb, 2017 1 commit
-
-
kozyatinskiy authored
V8DebuggerAgentImpl::m_skipAllPaused is moved to V8Debugger. V8DebuggerAgentImpl::didPaused doesn't return shouldBreak flag and called only when break is required and stack trace presented. V8DebuggerAgentImpl doesn't store paused context. Logic of conversion step-next at return into step-in is moved to debug.cc. BUG=none R=dgozman@chromium.org,yangguo@chromium.org Review-Url: https://codereview.chromium.org/2668763003 Cr-Commit-Position: refs/heads/master@{#42907}
-
- 26 Jan, 2017 2 commits
-
-
kozyatinskiy authored
With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained. At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback: foo2 (test.js:14:2) -- Promise.resolve (test.js:29:14)-- -- Promise.resolve (test.js:28:14)-- promiseThen (test.js:30:2) More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org Review-Url: https://codereview.chromium.org/2648873002 Cr-Commit-Position: refs/heads/master@{#42682}
-
luoe authored
BUG=chromium:683335 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2651153004 Cr-Commit-Position: refs/heads/master@{#42672}
-
- 25 Jan, 2017 1 commit
-
-
kozyatinskiy authored
- kDebugPromiseCreated(task, parent_task) This event occurs when promise is created (PromiseHookType::Init). V8Debugger uses this event to maintain task -> parent task map. - kDebugEnqueueAsyncFunction(task) This event occurs when first internal promise for async function is created. V8Debugger collects stack trace at this point. - kDebugEnqueuePromiseResolve(task), This event occurs when Promise fulfills with resolved status. V8Debugger collects stack trace at this point. - kDebugEnqueuePromiseReject(task), This event occurs when Promise fulfills with rejected status. V8Debugger collects stack trace at this point. - kDebugPromiseCollected, This event occurs when Promise is collected and no other chained callbacks can be added. V8Debugger removes information about async task for this promise. - kDebugWillHandle, This event occurs when chained promise function (either resolve or reject handler) is called. V8Debugger installs parent promise's stack (based on task -> parent_task map) as current if available or current promise's scheduled stack otherwise. - kDebugDidHandle, This event occurs after chained promise function has finished. V8Debugger restores asynchronous call chain to previous one. With this change all instrumentation calls are related to current promise (before WillHandle and DidHandle were related to next async task). Before V8Debugger supported only the following: - asyncTaskScheduled(task1) - asyncTaskStarted(task1) - asyncTaskFinished(task1) Now V8Debugger supports the following: - asyncTaskScheduled(parent_task) .. - asyncTaskCreated(task, parent_task), - asyncTaskStarted(task), uses parent_task scheduled stack - asyncTaskScheduled(task) - asyncTaskFinished(task) Additionally: WillHandle and DidHandle were migrated to PromiseHook API. More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE BUG=v8:5738 R=dgozman@chromium.org,gsathya@chromium.org,yangguo@chromium.org Review-Url: https://codereview.chromium.org/2650803003 Cr-Commit-Position: refs/heads/master@{#42644}
-
- 24 Jan, 2017 1 commit
-
-
kozyatinskiy authored
V8 has internal mechanism to ignore steps and breaks inside internal scripts, in this CL it's reused for blackboxing implementation. Advantages: - much faster blackboxing implementation (before we at least wrap and collect current call stack for each step), - get rid of StepFrame action and potential pause in blackboxed code after N StepFrame steps, - simplification of debugger agent logic. Disadvtanges: - currently when user was paused in blackboxed code (e.g. on breakpoint) and then makes step action, debugger ignores blackboxed state of the script and allows to use step actions as usual - this behavior is regressed, we still able to support it on frontend side. Current state and proposed changes for blackboxing: https://docs.google.com/document/d/1hnzaXPAN8_QC5ENxIgxgMNDbXLraM_OXT73rAyijTF8/edit?usp=sharing BUG=v8:5842 R=yangguo@chromium.org,dgozman@chromium.org,alph@chromium.org Review-Url: https://codereview.chromium.org/2633803002 Cr-Commit-Position: refs/heads/master@{#42614}
-
- 18 Jan, 2017 3 commits
-
-
kozyatinskiy authored
Inspector is moved to per-event-type callbacks instead of general v8::debug::SetDebugEventListener. It allows to: - remove any usage of v8::Debug::EventDetails in debug-interface, - avoid redundant JS call on each event to get properties of event objects, - introduce better pure C++ API for these events later. BUG=v8:5510 R=yangguo@chromium.org,jgruber@chromium.org,dgozman@chromium.org Review-Url: https://codereview.chromium.org/2622253004 Cr-Commit-Position: refs/heads/master@{#42483}
-
kozyatinskiy authored
Currently V8 context just crashes on OOM, with this CL backend will send paused notification with OOM reason before OOM and will increase heap limits to allow further debugging on pause. BUG=chromium:675911 Review-Url: https://codereview.chromium.org/2624543004 Cr-Commit-Position: refs/heads/master@{#42480}
-
kozyatinskiy authored
Listener is called instead of event listener for v8::AfterCompile and v8::CompileError events if installed. - removed v8::debug::Script::Wrap. BUG=v8:5510 R=yangguo@chromium.org,jgruber@chromium.org,dgozman@chromium.org,clemensh@chromium.org, alph@chromium.org, Review-Url: https://codereview.chromium.org/2626283002 Cr-Commit-Position: refs/heads/master@{#42477}
-
- 13 Jan, 2017 1 commit
-
-
kozyatinskiy authored
If installed, this listener is called instead of general DebugEventListener. BUG=v8:5510 R=yangguo@chromium.org, jgruber@chromium.org, dgozman@chromium.org Review-Url: https://codereview.chromium.org/2623313005 Cr-Commit-Position: refs/heads/master@{#42340}
-
- 10 Jan, 2017 1 commit
-
-
kozyatinskiy authored
... which were done after the promise has been resolved. Goal of this CL - change promise instrumentation to support better callbacks, chained after promise resolution and prepare instrumentation for adding new asyncTaskCreated instrumentation. Instrumentation changes: - asyncTaskScheduled(recurring) when promise is fulfilled or rejected, - asyncTaskCancelled when promise is collected (since [1] we can be sure that promise will survive scheduled microtasks). Minor changes: - async task type in inspector <-> debugger API transferred by enum instead of string, - Debug manages async task ids based on promise objects. More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE [1] https://codereview.chromium.org/2581503003/ BUG=chromium:632829,v8:5738 R=dgozman@chromium.org,yangguo@chromium.org,gsathya@chromium.org Review-Url: https://codereview.chromium.org/2578923002 Cr-Commit-Position: refs/heads/master@{#42178}
-