I bet @gparker must've tried something along those lines in the past...
-
-
Two problems: One, many call sites really want a two-entry cache (mutable and non-mutable class, for example). Two, it costs too much dirty memory to do this everywhere so you need some way to choose at compile time where to apply it.
2 replies 0 retweets 3 likes -
Yeah, you can chain them to make polymorphic ICs (all JS engines do this). Can you use PGO to determine which call sites are hot?
1 reply 0 retweets 1 like -
It’s hard to believe that devirtualization is never worth it. objc_msgSend is pretty much always a BTB miss and that’s gotta hurt…
2 replies 0 retweets 1 like -
That’s not really true on newer architectures. Branch prediction with history in practice predicts msgSend fairly well
2 replies 0 retweets 2 likes -
Well enough that tricks that increase local code size or memory usage aren’t worth the systemwide costs, at least
1 reply 0 retweets 0 likes -
That would imply that JS inline caches aren't worth it. I'm skeptical, given that it's completely impossible to write a competitive JS engine without them.
3 replies 0 retweets 1 like -
In addition to all of Greg’s points, remember that a call cache in JS gets to skip more work; ObjC assumes you’re calling a method with the right signature.
1 reply 0 retweets 1 like -
Replying to @pathofshrines @pcwalton and
And the caching can do more than just devirtualization, e.g. you can devirtualize to a variant which propagates argument type information.
2 replies 0 retweets 0 likes -
Replying to @pathofshrines @pcwalton and
Or even inline it in a later stage of the JIT if the cache metadata suggests it’s stable.
1 reply 0 retweets 0 likes
Yes. Which is doable in Objective-C as well, with PGO :)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.