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.
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.
