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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Mar 14 15:46:56 PDT 2013


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





--- Comment #25 from Ulfar Erlingsson <ulfar.chromium at gmail.com>  2013-03-14 15:49:19 PST ---
(In reply to comment #22)
> 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.

Totally understand and appreciate the need to avoid greater complexity.

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

A closure mechanism can be useful in many cases other than logging.  In particular, whenever there is optional modification to the behavior of a callback, and you don't want to pay any cost in the normal, unmodified case.  What is the cost of the TRACE_EVENT macros when chrome://tracing is not being used?

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

There is a lot of overlap with that, and option (B) that I outlined above.  Is there some version of the patch that I can see?

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


More information about the webkit-unassigned mailing list