[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 #17 from Ulfar Erlingsson <ulfar.chromium at gmail.com>  2013-03-06 16:34:01 PST ---
(In reply to comment #13)
> > > I'm interested in performance impacts when you enable the wrapping? Did you observe performance impacts on Dromaeo/dom-*.html or Bindings/* ?
> > 
> > I'll run the performance tests and get those numbers today.  I don't expect there to be any measurable overhead, since there are only a few extra machine instructions plus one extra memory access per DOM wrapper invocation. 
> > 
> > Note: If the perf cost is as low as I expect, this mechanism can be used for various types of optional monitoring---such as gathering of trace data---without any cost being incurred by normal operation.
> 
> hmm, I begin to wonder why this change is needed...:) It looks like the change is going to add unnecessary complexity to the code base. Also it is going to add "a few extra machine instructions plus one extra memory access", which sounds heavy (although we should judge it based on performance measurement).
> 

I just uploaded a new patch, and performance data, which indicates that the cost of wrapping is about the same as an access to an undefined DOM property.

Still unresolved is the memory leak.  I'm hoping ABarth can help me fix that, assuming everything else passes muster.

Regarding performance, note that this patch is designed to incur zero overhead except on DOM element properties that are being "cover wrapped".  In our initial application, that set will be very small, and cover wrapping will only be applied at all in the V8 contexts of extensions.

Regarding why this is needed, the mechanism is designed to support logging the access to a select set of (security-critical) DOM element properties from a select set of V8 worlds/contexts--in particular, from Chrome extensions.  The set of elements to log, and what to log from what contexts, may change, and possibly be under user control (to some extent) in the future.

Apart from some simple plumbing, the mechanism is completely contained within the cover wrapping files.  Any complexity (e.g., how to wrap, what to wrap, what state to track, etc.) should be isolated to that part of the code.

> What you want to do is adding wrapper methods for getters/setters/methods (selectively). Currently, xxxAttrGetterCallback(), xxxAttrSetterCallback() and xxxMethodCallback() are the entry points from V8. How about just hooking those entry points in code generators?

We're happy to consider any code changes that support the type of Chrome extension activity logging we'd like to add.  And the simpler the better.  I previously did look at modifying the code generation Perl script (initially targeting the INC_STATS macro locations), but that patch got unwieldy and required significant changes to plumbing.  However, I can try again, if needed.

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