Added Editor stream and sendObjectToEditor RPC into Service Protocol

Added Editor stream and sendObjectToEditor RPC into Service Protocol

Related=https://github.com/dart-lang/sdk/issues/30023

R=rmacnak@google.com

Committed: https://github.com/dart-lang/sdk/commit/0d86f5f3c560fbc0680e33ccf8de3e224529a85a

[cbernaschina, 2017-06-26 22:40:55]

Description was changed from

==========
Added Editor stream and sendObjectToEditor RPC into Service Protocol

Related=https://github.com/dart-lang/sdk/issues/30023
==========

to

==========
Added Editor stream and sendObjectToEditor RPC into Service Protocol

Related=https://github.com/dart-lang/sdk/issues/30023
==========

[cbernaschina, 2017-06-26 22:40:57]

cbernaschina@google.com changed reviewers:
+ asiva@google.com, rmacnak@google.com

[rmacnak, 2017-06-27 16:47:56]

https://codereview.chromium.org/2962593002/diff/1/runtime/observatory/lib/src...
File runtime/observatory/lib/src/elements/memory_dashboard.dart (right):

https://codereview.chromium.org/2962593002/diff/1/runtime/observatory/lib/src...
runtime/observatory/lib/src/elements/memory_dashboard.dart:40: class
MemoryDashboardElement extends HtmlElement implements Renderable {
This currently looks like just a copy of the allocation profile. Is this
work-in-progress that belongs in a separate CL?

https://codereview.chromium.org/2962593002/diff/1/runtime/vm/service.cc
File runtime/vm/service.cc (right):

https://codereview.chromium.org/2962593002/diff/1/runtime/vm/service.cc#newco...
runtime/vm/service.cc:4215: LookupHeapObject(thread,
js->LookupParam("objectId"), &lookup_result));
It looks like the only thing we do with the object is turn it back into an
objectId for the event. Should we just pass the objectId through?

[cbernaschina, 2017-06-27 17:03:25]

https://codereview.chromium.org/2962593002/diff/1/runtime/observatory/lib/src...
File runtime/observatory/lib/src/elements/memory_dashboard.dart (right):

https://codereview.chromium.org/2962593002/diff/1/runtime/observatory/lib/src...
runtime/observatory/lib/src/elements/memory_dashboard.dart:40: class
MemoryDashboardElement extends HtmlElement implements Renderable {
On 2017/06/27 16:47:56, rmacnak wrote:
> This currently looks like just a copy of the allocation profile. Is this
> work-in-progress that belongs in a separate CL?

It is the initial version of the User Oriented tool that is going to be
integrated inside the Editors.
The first version is going to be the same as the allocation profile, but we are
going to change it given the feedback from the team working on the IntelliJ
integration.
We will keep the allocation profile as it is as a VM Developers oriented tool.

https://codereview.chromium.org/2962593002/diff/1/runtime/vm/service.cc
File runtime/vm/service.cc (right):

https://codereview.chromium.org/2962593002/diff/1/runtime/vm/service.cc#newco...
runtime/vm/service.cc:4215: LookupHeapObject(thread,
js->LookupParam("objectId"), &lookup_result));
On 2017/06/27 16:47:56, rmacnak wrote:
> It looks like the only thing we do with the object is turn it back into an
> objectId for the event. Should we just pass the objectId through?

In the event it is sent as an ObjectRef.
Looking it up through the ObjectIdRing should guarantee a longer life for the
volatile ids.

[rmacnak, 2017-06-28 16:32:43]

lgtm

https://codereview.chromium.org/2962593002/diff/1/runtime/vm/service.cc
File runtime/vm/service.cc (right):

https://codereview.chromium.org/2962593002/diff/1/runtime/vm/service.cc#newco...
runtime/vm/service.cc:4215: LookupHeapObject(thread,
js->LookupParam("objectId"), &lookup_result));
On 2017/06/27 17:03:25, cbernaschina wrote:
> On 2017/06/27 16:47:56, rmacnak wrote:
> > It looks like the only thing we do with the object is turn it back into an
> > objectId for the event. Should we just pass the objectId through?
> 
> In the event it is sent as an ObjectRef.
> Looking it up through the ObjectIdRing should guarantee a longer life for the
> volatile ids.

Add a comment here explaining we're effectively refreshing the id here.

[cbernaschina, 2017-06-29 17:08:26]

Description was changed from

==========
Added Editor stream and sendObjectToEditor RPC into Service Protocol

Related=https://github.com/dart-lang/sdk/issues/30023
==========

to

==========
Added Editor stream and sendObjectToEditor RPC into Service Protocol

Related=https://github.com/dart-lang/sdk/issues/30023

R=rmacnak@google.com

Committed:
https://github.com/dart-lang/sdk/commit/0d86f5f3c560fbc0680e33ccf8de3e224529a85a
==========

[cbernaschina, 2017-06-29 17:08:28]

Committed patchset #2 (id:20001) manually as
0d86f5f3c560fbc0680e33ccf8de3e224529a85a (presubmit successful).

[cbernaschina, 2017-06-29 17:29:38]

https://codereview.chromium.org/2962593002/diff/1/runtime/vm/service.cc
File runtime/vm/service.cc (right):

https://codereview.chromium.org/2962593002/diff/1/runtime/vm/service.cc#newco...
runtime/vm/service.cc:4215: LookupHeapObject(thread,
js->LookupParam("objectId"), &lookup_result));
On 2017/06/28 16:32:42, rmacnak wrote:
> On 2017/06/27 17:03:25, cbernaschina wrote:
> > On 2017/06/27 16:47:56, rmacnak wrote:
> > > It looks like the only thing we do with the object is turn it back into an
> > > objectId for the event. Should we just pass the objectId through?
> > 
> > In the event it is sent as an ObjectRef.
> > Looking it up through the ObjectIdRing should guarantee a longer life for
the
> > volatile ids.
> 
> Add a comment here explaining we're effectively refreshing the id here.

Done.