Move traced_value.* from cc/debug/ to base/debug/

Move traced_value.* from cc/debug/ to base/debug/

TracedValue depends only on types from 'base' namespace and may be reused in other components. I need it in content/common/gpu/gpu_command_buffer_stub.cc

BUG=361045

[yurys, 2014-04-30 12:44:22]

@ajwong: please review changes in base/

[yurys, 2014-04-30 12:46:04]

@ajwong: please review changes in base/

[yurys, 2014-05-02 04:20:47]

ping

[awong, 2014-05-02 05:44:24]

I'm slightly hesitant to pull this into base -- especially without more
documentation on how/when/why to use this class.

Would this make sense to put into a component, or should it really be as low as
base?

[yurys, 2014-05-05 07:05:00]

On 2014/05/02 05:44:24, awong wrote:
> I'm slightly hesitant to pull this into base -- especially without more
> documentation on how/when/why to use this class.
> 
> Would this make sense to put into a component, or should it really be as low
as
> base?

I added some comments to the class on when it may be useful. Which component
would you suggest to move it into? Both values.h and trace_event.h live under
base/ and since using base::Value to create a structural argument looks as
pretty common scenario it seemed logical to me to have traced_value.h under
base/. Alternatively we could add SetTraceValue overload which would handle
base::Value* arguments, would that make sense?

[awong, 2014-05-07 21:49:22]

LGTM 

Sorry for the delay. Talked this over with another base owner. I think this
looks sensible enough to bundle with the rest of the debugging stuff.

On 2014/05/05 07:05:00, yurys wrote:
> On 2014/05/02 05:44:24, awong wrote:
> > I'm slightly hesitant to pull this into base -- especially without more
> > documentation on how/when/why to use this class.
> > 
> > Would this make sense to put into a component, or should it really be as low
> as
> > base?
> 
> I added some comments to the class on when it may be useful. Which component
> would you suggest to move it into? Both values.h and trace_event.h live under
> base/ and since using base::Value to create a structural argument looks as
> pretty common scenario it seemed logical to me to have traced_value.h under
> base/. Alternatively we could add SetTraceValue overload which would handle
> base::Value* arguments, would that make sense?

[yurys, 2014-05-08 14:44:37]

@nduca: please do OWNERS review

[nduca, 2014-05-08 17:03:05]

can you please call the filename trace_event_somthingorother? this lets you put
it in the trace_event review ecosystem which lets you iterate with my lg's.

Also, how much does this lock us into the current notion that tracedvalue wraps
a value*? In the medium term , i'd like to make TracedValue more of this form:


v = new TracedDictValue()
v.beginDictNamed("foo")
v.setInteger("bar", 3)
v.setString("baz", "str")
v.endDictNamed("foo")

would push into a pickle internally and then convert to json in this form later:
{foo: {bar: 3, baz: "Str"}}

The reason for this direction is that the primary cost of using tracedvalues is
the number of heap allocs that you have to do now. I'd like to get away from
that pretty soon before we start blessing this as a general interface.

With all that in mind, wdyt we should do?

[yurys, 2014-05-15 15:07:37]

On 2014/05/08 17:03:05, nduca wrote:
> can you please call the filename trace_event_somthingorother? this lets you
put
> it in the trace_event review ecosystem which lets you iterate with my lg's.
> 
> Also, how much does this lock us into the current notion that tracedvalue
wraps
> a value*? In the medium term , i'd like to make TracedValue more of this form:
> 
> 
> v = new TracedDictValue()
> v.beginDictNamed("foo")
> v.setInteger("bar", 3)
> v.setString("baz", "str")
> v.endDictNamed("foo")
> 
> would push into a pickle internally and then convert to json in this form
later:
> {foo: {bar: 3, baz: "Str"}}
> 
> The reason for this direction is that the primary cost of using tracedvalues
is
> the number of heap allocs that you have to do now. I'd like to get away from
> that pretty soon before we start blessing this as a general interface.
> 
> With all that in mind, wdyt we should do?

How about introducing trace_event_argument which would be a builder with
an interface like you described above with TraceEventArgument::Finish returning
an instance of ConvertableToTraceFormat. First implementation would create
value*
object and wrap it into TracedValue (current implementation) but all of that
could
be hidden in the implementation of trace_event_argument. That way the
implementation
can be changed later to use pickles internally while the clients' code will stay
the same.

I'm not sure though how to deal with current AsValue methods - they could
be modified to accept the builder as an argument but we will need a way to
validate that begin/end calls are balanced.