See bug 626021 comment 17 and 18.

Is this still required, or has it been implemented as part of the great accessors overhaul of the summer?

Oh, reading slightly more, I see that it is still required. And blocking bug 782913, too. Or, that is largely a dupe of bug 626021, but contains some benchmarks that might be interesting to look at. Eric, for the shell benchmark from bug 782913, I still get numbers that are ~120x worse for the getter defined on the object itself. Modifying that to having the getter on the prototype removes that completely, as expected. However, in bug 782913 comment 15, you seem to say that the now-fixed bug 765454 should have fixed that case, too. Either it didn't, or this regressed since.

Hmmm. That's not at all what I would expect. I would have thought that Brian's work on this issue would have cleaned up the matter entirely. I suspect there's a simple fix here. I'll look into it.

OK, I take it back. After some long hiatus, I have looked at this again. It /is/ what I expect, but it's a little silly, now. Since we can look up exactly what the shape should be now that we've landed that stuff, we /could/ use a shape guard and not TI freezes to handle own property accessors in the case where there's only one type coming in, and we've seen the thing previously. Probably we would need to prototype this and test the cost of extra bailouts relative to the gains, but I suspect they should be OK.

This was done in other bugs like bug 1128535. The Ion ICs (bug 1129382) should handle the scripted own-property case; inlining those directly is bug 1128646.