<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#c50">Comment # 50</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#c49">comment #49</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=158083#c47">comment #47</a>)
> > But I should have suggested something simpler yesterday.
> > When you convert your get_by_id into your specialized version, you
> > can stash the UniquedStringImpl* into the instruction stream itself if
> > you have an unused instruction offset. Do you have such a free location?
>
> This is a good idea. We have an invariant that changing a Accessor on an
> object requires transitioning the structure of that object. This means that
> you can use, for example, pc[4] to hold the function pointer and pc[5] to
> point to the UniquedStringImpl* of the property.</span >
Actually, my first thinking was in that way. However, pc[4] is used to check if the inline is still valid.
_llint_op_get_by_id_proto_custom:
traceExecution()
loadisFromInstruction(2, t0)
loadConstantOrVariableCell(t0, t3, .opGetByIdProtoCustomSlow)
loadi JSCell::m_structureID[t3], t1
loadisFromInstruction(4, t2)
bineq t2, t1, .opGetByIdProtoCustomSlow
This way, I think it is not possible use pc[4] for that. Could you confirm it? If it is possible, I think it is the best way to implement it.
Another strategy i had in mind was create a C struct to store customGetter pointer and UniquedStringImpl and "pc[5].u.cstruct" point to it. However, it is not efficient, since it is going to double the size of pc[].u. A way to improve it should store a pointer to this struct, however It is not possible to track this pointer and free its memory.
Other solution I was thinking was create an property into slot.slotBase() to store the identifier, however it is going to create a waste of space to other objects.
So, the most viable solution I thought was the last one I commented above.
<span class="quote">> (In reply to <a href="show_bug.cgi?id=158083#c46">comment #46</a>)
> > I would like to know if there is a way to test the changes in all
> > architectures.
>
> It can be pretty tricky. I would recommend having the bot do it since, IIRC,
> we test all the architectures we care about.</span >
No problem. I asked because you could have a way to do it without submitting a patch. BTW my current architecture is x86_64 running Mac OS X.</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>