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

[bugzilla-daemon at webkit.org]

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

--- Comment #50 from Caio Lima <ticaiolima at gmail.com> ---
(In reply to comment #49)
> (In reply to comment #47)
> > 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.

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.

> (In reply to comment #46)
> > 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.

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.

-- 
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/20160611/e53bdf34/attachment-0001.html>