[Webkit-unassigned] [Bug 107207] [V8] Support selectively wrapping DOM accesses from certain V8 contexts.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=107207





--- Comment #22 from Kentaro Hara <haraken at chromium.org>  2013-03-13 17:55:24 PST ---
Thank you very much for the detailed explanation!

I might want to understand your situation a bit more (I'm not intending to object to your proposal). My primary concern is that getters/setters/methods in V8 bindings are already complicated and thus we don't want to make them more complicated without strong reasons. In terms of logging, we already have FeatureObservers and TRACE_EVENT macros. Note that both TRACE_EVENT macros and FeatureObserers are implemented just by auto-inserting code into the head of getters/setters/methods.

> So, I implemented the generic closure mechanism in the current patch.  It adds an indirection only where needed, and should incur performance penalty less or equal to either of the above options, without any significant changes in the V8 bindings code structure.
> 
> Closures are generally useful, so having such a mechanism may help implement other features.  That's why I pointed you at this patch: for chrome://tracing, it may be possible to eliminate any if statements like those in option (A), by using closures.

I'm not sure how much the mechanism is general. As you mentioned, you're not yet sure how and how much your logging mechanism is going to be used in the future. In addition, I suspect that the mechanism won't be helpful for about:tracing so much. Given that each DOM operation can finish within 20 nano seconds, all we can do in a TRACE_EVENT macro is anyway just to update one global state variable. Thus we don't need something like closures to insert TRACE_EVENT macros, we can just insert TRACE_EVENT macros at the head of getters/setters/methods. On the other hand, FeatureObservers might be benefited by the mechanism(, although FeatureObservers intend to log DOM operations in _all_ worlds). 

Marja is currently implementing two templates for all interfaces: one for the main world and the other for isolated worlds. How about waiting for the work and then implementing a mechanism that selectively auto-inserts logging code into the head of getters/setters/methods of the templates of the world you are interested in? ('Selectively' means that you can control getters/setters/methods and worlds to which the logging code is inserted by using IDL attributes.)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.