On 2015/07/08 16:44:25, fmeawad wrote:
On 2015/07/08 09:53:04, caseq wrote:
> +1 to getting this done (and willing to help if needed, as I had a
somewhat
> similar CL before yurys@ kindly pointed me here).
>
> We would like to start relying on trace events emitted by v8 in
DevTools'
> Timeline (in particular, crbug.com/508005 depends on this), but would
like a
> finer break-down by categories, as opposed to everything being traced as
"v8"
> now. Being able to pass additional arguments would eventually be useful,
too.
> This all calls for exposing the reach interface to tracing, in
particular
for
> categories -- just passing categories via event logger would greatly
increase
> the overhead, as we won't be able to cache pointers to enable flags on
the
trace
> site as trace macros do now.
>
> Yang and Jochen, would keeping existing TimerEventScope<TimerEventFoo>
along
> with per-isolate logging to file while deprecating SetEventLogger() from
public
> Isolate API address your concern of per-isolate logging? We could also
expose
> isolate id via tracing events as Nat suggests, though I think existing
event
> logger callback do not actually require this.
I am currently working on adding isolate id (context id) to trace events.
How
about we land this CL as is, leave the current logging technique for V8
until
we
get isolate id in trace events? This would allow us to get the V8 team to
start
using the trace macros right away. Adding the isolate id only happens in
tracing
code.
The context_id stuff landed right? So, does that mean we can move this
forward
again?
https://codereview.chromium.org/988893003/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
