[webkit-reviews] review requested: [Bug 10930] WebKit could benefit from a JavaScript live object profiler : [Attachment 29915] Adds live object profiling capabilities

[bugzilla-daemon at webkit.org]

Horia Olaru <olaru at adobe.com> has asked  for review:
Bug 10930: WebKit could benefit from a JavaScript live object profiler
https://bugs.webkit.org/show_bug.cgi?id=10930

Attachment 29915: Adds live object profiling capabilities
https://bugs.webkit.org/attachment.cgi?id=29915&action=review

------- Additional Comments from Horia Olaru <olaru at adobe.com>
The patch provides a way to access the size of a specific JavaScript object,
where it was created and a way to expose this information in
WebInspector/JavaScript.

The patch follows the general guidelines in this related discussion on
webkit-dev
(https://lists.webkit.org/pipermail/webkit-dev/2009-February/006554.html).

The size of an object

This issue is comprised of two parts: the way to access the size of a JS object
per se, and the way to access the size of DOM objects in JS.

The idea was to add a method to JS objects that returns the size of the object
it belongs to. To do this, a virtual method named ‘instanceSize’ was added to
the implementation of JS objects. Since not all implementations inherit
JSObject, but all inherit JSCell (e.g. JSString), instanceSize was added on
JSCell. It returns size 0 and is inherited by all descendants of JSCell. This
way, it can be implemented and updated only for specific types. Such
implementations are included for a few basic types (Array, String, Number).

To access DOM object sizes, CodeGeneratorJS.pm was modified. This script
generates JS wrappers for DOM objects. The script checks for the
‘HasInstanceSize’ attribute in the .idl file to see if it is to add an
‘instanceSize’ implementation to the JS wrapper. This maintains the size
function naming convention across pure JS objects and DOM objects, while
allowing the size function to reside within the implementation file of the DOM
object. This DOM object size function was named ‘elementSize’ and it is added
on HTMLImageElement, to prove functionality. 

Object creation information

The main purpose is to keep track of the location where an object is created in
JavaScript. This includes the url/file name and line number, as well as a stack
trace of the function in which the object is created. In order to access this
information, I found it necessary to record it at object creation time, when
url, line number, and creator function are known. To do this a structure
(LiveObjects) was added to hold the information in the existing profiler
infrastructure. Profiler now exposes the objectCreated and objectCollected
methods. The objectCreated method is called from the JSCell operator new, when
profiling is enabled. Similarly, objectCollected is called from the JSCell
destructor. The (LiveObjects) structure holds a map of JSCell* and
ProfilerNode*, registering objects allocated between the start and end of a
profiling session. The existing ProfilerNode structure was used in order to
access stack traces, as the current ProfilerNode at object creation time is the
currently executing JS function.

Object information access from JavaScript/WebInspector.

To access the collected live object information, the objectData() function was
added to the JS Profile object. This function returns an array of objects (of
type ObjectInformation). The JS interface for the ObjectInfromation type is
located in inspector/JavaScriptObjectInformation and exposes these properties:
id, type name, size and createdFrom. The createdFrom object is a reference to a
JS ProfileNode, which actually holds function information. Stack traces can be
obtained from the createFrom object by recursively going up the .parent
property.

The below console code will allow you to visualize the live object information.
Note that profiling must be enabled from the WebInspector in order for the code
to work.

console.profile(“MyProfile”);
console.profileEnd();
// find the ‘i’ for your profile here;
console.profiles[i].objectData();