Bug 68741 - Add static version of JSCell::getCallData
Summary: Add static version of JSCell::getCallData
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Mark Hahnenberg
Depends on:
Blocks: 67690
  Show dependency treegraph
Reported: 2011-09-23 15:50 PDT by Mark Hahnenberg
Modified: 2011-09-27 15:45 PDT (History)
0 users

See Also:

Patch (75.36 KB, patch)
2011-09-25 12:32 PDT, Mark Hahnenberg
no flags Details | Formatted Diff | Diff
Patch (76.22 KB, patch)
2011-09-26 14:52 PDT, Mark Hahnenberg
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Hahnenberg 2011-09-23 15:50:59 PDT
In the ongoing effort to un-virtualize JSCell, we need to replace getCallData with a non-virtual version.  This will eventually be done by adding a function pointer to the ClassInfo struct.

This patch will be similar to bug 68404.
Comment 1 Mark Hahnenberg 2011-09-25 12:32:11 PDT
Created attachment 108609 [details]
Comment 2 Early Warning System Bot 2011-09-26 00:37:28 PDT
Comment on attachment 108609 [details]

Attachment 108609 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/9842812
Comment 3 Darin Adler 2011-09-26 14:12:59 PDT
Comment on attachment 108609 [details]

View in context: https://bugs.webkit.org/attachment.cgi?id=108609&action=review

One thing that’s bad about the new functions is that they all have unchecked type casts in them. It makes me wish there was some way to check the types in all those cases are correct.

Looks like this did not build on Qt.

r=me if you address the Qt build failure

> Source/JavaScriptCore/ChangeLog:13
> +        able to more easily store and refer to them in our custom vtable since normal 

I’d say in our “method table” not our “custom viable”.

> Source/JavaScriptCore/ChangeLog:15
> +        impossible to store them generically in ClassInfo.

I think I’d say something more like this: Function pointers are smaller and more efficient to call than pointers to member functions, and using static member functions allows us to use function pointers.
Comment 4 Mark Hahnenberg 2011-09-26 14:52:24 PDT
Created attachment 108727 [details]
Comment 5 Darin Adler 2011-09-26 20:25:08 PDT
Comment on attachment 108727 [details]

View in context: https://bugs.webkit.org/attachment.cgi?id=108727&action=review

> Source/JavaScriptGlue/ChangeLog:14
> +        can be represented as function pointers rather than pointers to member methods, and
> +        function pointers are smaller and faster to call than pointers to member methods.

The term is "member functions", not "member methods".
Comment 6 Mark Hahnenberg 2011-09-27 15:45:57 PDT
Committed r96164: <http://trac.webkit.org/changeset/96164>