<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - LLInt should support other types of prototype GetById caching."
href="https://bugs.webkit.org/show_bug.cgi?id=158083#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - LLInt should support other types of prototype GetById caching."
href="https://bugs.webkit.org/show_bug.cgi?id=158083">bug 158083</a>
from <span class="vcard"><a class="email" href="mailto:ticaiolima@gmail.com" title="Caio Lima <ticaiolima@gmail.com>"> <span class="fn">Caio Lima</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=158083#c3">comment #3</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=158083#c1">comment #1</a>)
> > 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
> <a href="http://trac.webkit.org/changeset/201456">http://trac.webkit.org/changeset/201456</a>.
>
> 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.</span >
Thanks for the clarification Keith.
I am sending a prototype of what you described, but I definitely want to learn how can I inline a function call =).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>