[Tracing] Expose trace serialization as part of tracing interface

[Tracing] Expose trace serialization as part of tracing interface

This change adds a new TraceSerializer class to the V8 tracing
interface. Previously, this was a private implementation detail in the
JSONTraceWriter class.

In addition, escape sequences may now be written to a trace file
(previously, any string with a valid escapable character would fail
a check).

BUG=v8:4561

[kelvinjin, 2016-09-02 22:30:55]

Description was changed from

==========
[Tracing] Expose trace serialization as part of tracing interface

This change adds a new TraceSerializer class to the V8 tracing
interface. Previously, this was a private implementation detail in the
JSONTraceWriter class.

In addition, escape sequences may now be written to a trace file
(previously, any string with a valid escapable character would fail
a check).

BUG=v8:4561
==========

to

==========
[Tracing] Expose trace serialization as part of tracing interface

This change adds a new TraceSerializer class to the V8 tracing
interface. Previously, this was a private implementation detail in the
JSONTraceWriter class.

In addition, escape sequences may now be written to a trace file
(previously, any string with a valid escapable character would fail
a check).

BUG=v8:4561
==========

[kelvinjin, 2016-09-02 22:30:55]

kelvinjin@google.com changed reviewers:
+ fmeawad@chromium.org, lpy@chromium.org, mattloring@google.com

[kelvinjin, 2016-09-02 22:32:08]

On 2016/09/02 22:30:55, kelvinjin wrote:
> mailto:kelvinjin@google.com changed reviewers:
> + mailto:fmeawad@chromium.org, mailto:lpy@chromium.org,
mailto:mattloring@google.com

Please take a look!

[lpy, 2016-09-02 22:51:52]

The CQ bit was checked by lpy@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-02 22:52:00]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-02 23:21:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-02 23:21:33]

Dry run: This issue passed the CQ dry run.

[lpy, 2016-09-02 23:39:41]

Why do we need to expose a TraceSerializer?

[kelvinjin, 2016-09-03 00:04:35]

On 2016/09/02 23:39:41, lpy wrote:
> Why do we need to expose a TraceSerializer?

node.js has a near-duplicate of the code in JSONTraceWriter, and it would be
good for it to use this code instead of its own copy of it, since it (naturally)
uses the same output trace format.

[mattloring, 2016-09-03 19:30:24]

On 2016/09/03 00:04:35, kelvinjin wrote:
> On 2016/09/02 23:39:41, lpy wrote:
> > Why do we need to expose a TraceSerializer?
> 
> node.js has a near-duplicate of the code in JSONTraceWriter, and it would be
> good for it to use this code instead of its own copy of it, since it
(naturally)
> uses the same output trace format.

This will simplify things on the node side as long as the V8 team is alright
with the additional API surface. Originally we decided that it was small enough
to duplicate but it would be nice to avoid parallel updates. Exposing the
serializer separately will also reduce the overhead for node users who want to
plug in alternative serialization formats and allow the default writer to handle
all of the libuv specific file operations regardless of output format.

[lpy, 2016-12-08 19:41:41]

On 2016/09/03 19:30:24, mattloring wrote:
> On 2016/09/03 00:04:35, kelvinjin wrote:
> > On 2016/09/02 23:39:41, lpy wrote:
> > > Why do we need to expose a TraceSerializer?
> > 
> > node.js has a near-duplicate of the code in JSONTraceWriter, and it would be
> > good for it to use this code instead of its own copy of it, since it
> (naturally)
> > uses the same output trace format.
> 
> This will simplify things on the node side as long as the V8 team is alright
> with the additional API surface. Originally we decided that it was small
enough
> to duplicate but it would be nice to avoid parallel updates. Exposing the
> serializer separately will also reduce the overhead for node users who want to
> plug in alternative serialization formats and allow the default writer to
handle
> all of the libuv specific file operations regardless of output format.

Is this patch still valid?

[kelvinjin, 2016-12-08 22:12:16]

On 2016/12/08 19:41:41, lpy wrote:
> On 2016/09/03 19:30:24, mattloring wrote:
> > On 2016/09/03 00:04:35, kelvinjin wrote:
> > > On 2016/09/02 23:39:41, lpy wrote:
> > > > Why do we need to expose a TraceSerializer?
> > > 
> > > node.js has a near-duplicate of the code in JSONTraceWriter, and it would
be
> > > good for it to use this code instead of its own copy of it, since it
> > (naturally)
> > > uses the same output trace format.
> > 
> > This will simplify things on the node side as long as the V8 team is alright
> > with the additional API surface. Originally we decided that it was small
> enough
> > to duplicate but it would be nice to avoid parallel updates. Exposing the
> > serializer separately will also reduce the overhead for node users who want
to
> > plug in alternative serialization formats and allow the default writer to
> handle
> > all of the libuv specific file operations regardless of output format.
> 
> Is this patch still valid?

No, it's been superseded completely by
https://codereview.chromium.org/2309943005 which is already checked in...
closing. Thanks for the reminder!