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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jun 8 09:49:16 PDT 2016


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

--- Comment #40 from Keith Miller <keith_miller at apple.com> ---
(In reply to comment #39)
> (In reply to comment #38)
> > Comment on attachment 280560 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=280560&action=review
> > 
> > Looks good. I think it's almost ready to go. Saam and I have a few comments
> > before the patch is ready to land however.
> > 
> > > Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:659
> > > +        if ((slot.isValue() || slot.isAccessor()) && slot.slotBase() == baseValue) {
> > 
> > Why clear the cache if we have a self accessor? There is no cost to leaving
> > the old value cache in place.
> 
> I see your point. Actually, the main reason I implemented it was because I
> though it was the case where handling a cache miss and clearing the old
> cache. However, if I am not wrong, It is the case just to self accessors,
> right?
> 
> In our implementation, we just cache the prototype once (when
> pc[7].u.operand reaches 0) and after that, all cache misses are handled by
> the _llint_get_by_id_proto_acessor opcode slowPath case. The advantage to
> clear the cache is to avoid all these misses, however, the original
> _llint_get_by_id_proto_acessor also check for misses and there is no real
> improvement clearing the cache, right?
> 

That's right. Unless we have something else to put in the cache or the cache becomes invalid there is no benefit to clearing it.

> I am going to change it.
> 
> BTW, I have already an first implementation of CustomAcessors. What I need
> to finish is inline the CustomAcessor call to Assembly code. I think it is a
> good idea send them in the same patch, since the files touched are the same.
> As you pointed me instructions to try inline the Getter, I already have an
> idea what I need to do to complete this implementation.

Cool, sounds like a plan. Let me know if you have any other questions.

-- 
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/20160608/32c5392e/attachment-0001.html>


More information about the webkit-unassigned mailing list