[Webkit-unassigned] [Bug 158083] LLInt should support other types of prototype GetById caching.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jun 2 15:57:19 PDT 2016


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

--- Comment #3 from Keith Miller <keith_miller at apple.com> ---
(In reply to comment #1)
> Hey Keith, I am interested in work in this bug if it is possible
> 
> Cold you clarify some points to me?
> 
> 1. What are prototype misses?
> 
> 2. When you think in cache accessors, you mean getters and setters?
> 
> 3. Also, for customs
> 
> It could be a big help if you post some JavaScript code as example.
> 
> I am trying to debug the case for accessors and I noticed that the getter is
> emitted as get_by_id op and I suspect it is already being cached (I didn't
> check it).

Hi Caio,

It would be great if you fixed this feature and I would be happy to help. Feel free to message me on irc, my nick is keith_miller, if you have any other questions.

1) prototype miss was the wrong terminology. I should have said that we should cache unset properties. Meaning, `let x = foo.bar` where `"bar" in foo === false`. I actually already handled this case in http://trac.webkit.org/changeset/201456.

2) Yep, that's right. In JavaScriptCore we use the word Accessor to mean a property with a getter and/or a setter. 

For example, if you did the following: 

foo = {};
Object.defineOwnProperty(Object.prototype, "bar", { get: () => { return 1; } });
print(foo.bar);

The bytecodes will look something like:

[   9] resolve_scope     loc10, loc3, print(@id0), <GlobalProperty>, 1, 0x113de7900
[  16] get_from_scope    loc6, loc10, print(@id0), 2048<ThrowIfNotFound|GlobalProperty|NotInitialization>, 122    predicting None
[  24] resolve_scope     loc11, loc3, foo(@id1), <GlobalProperty>, 1, 0x113de7900
[  31] get_from_scope    loc12, loc11, foo(@id1), 2048<ThrowIfNotFound|GlobalProperty|NotInitialization>, 191    predicting None
[  39] get_by_id         loc9, loc12, bar(@id2)    predicting None
[  48] call              loc5, loc6, 2, 16 status(Could Take Slow Path)    Original; predicting None

That get_by_id will attempt to lookup the property on foo by calling foo's getOwnPropertySlot function, which will set the passed PropertySlot& to Object.prototype's "bar" GetterSetter object. In this case, the PropertySlot will say that the value is an GetterSetter and we won't cache it.

3) Customs are mostly used as a performance optimization for DOM Accessors. Basically, instead of allocating a JSFunction object for all accessor properties in the DOM we use a function pointer instead. You can see the typedef, GetValueFunc, in PropertySlot.h. Customs are also used in a small number of other places for special properties that are values but change might change, although that is quite rare.

I would recommend for a first pass that you implement a new opcode, I guess called op_get_by_id_proto_accessor, that just calls to a slow path. In the slow path it can load the GetterSetter object and call the getter returning the result. If you are feeling very ambitious, you could inline the code for the call in the interpreter assembly. Let me know if you plan on trying to inline the call since you will need to know the JavaScriptCore calling convention to implement it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160602/236f0c06/attachment-0001.html>


More information about the webkit-unassigned mailing list