The no-clone optimization and the method barrier are gonna make life hard for IonMonkey, because they'd have to implement some form of getValidCalleeObject. Also, previous measurements showed that in practice we only get a small memory savings out of it, which doesn't really pay back for the complexity. Patch coming shortly.

Created attachment 623199[details][diff][review]
Patch for Fx13
[Approval Request Comment]
Regression caused by (bug #): null closure no-clone optimization
User impact if declined: instability from a fragile optimization
Testing completed (on m-c, etc.): shell tests + try + m-c for the larger patch
Risk to taking this patch (and alternatives if risky): low: could theoretically increase memory usage on some sites, but failed to observe this with the larger patch; it's conceivable that some of the nonremoved code could somehow execute but I verified not in shell tests.
String changes made by this patch: none

Created attachment 623218[details][diff][review]
Patch for ESR10
[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: was requested
User impact if declined: same as beta
Fix Landed on Version: m-c
Risk to taking this patch (and alternatives if risky): a little more risk than beta: in ESR10, the null closure optimization is intertwined with branding (an optimization that was subsequently removed), which I discovered by running shell tests. I think I fixed the problem but it's hard to be sure
String changes made by this patch: none
See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

(In reply to David Mandelin from comment #9)
> Risk to taking this patch (and alternatives if risky): a little more risk
> than beta: in ESR10, the null closure optimization is intertwined with
> branding (an optimization that was subsequently removed), which I discovered
> by running shell tests. I think I fixed the problem but it's hard to be sure
What sort of QA testing or automated testing can we do with the ESR to verify that there aren't any related regressions once landed?

(In reply to Alex Keybl [:akeybl] from comment #13)
> (In reply to David Mandelin from comment #9)
> > Risk to taking this patch (and alternatives if risky): a little more risk
> > than beta: in ESR10, the null closure optimization is intertwined with
> > branding (an optimization that was subsequently removed), which I discovered
> > by running shell tests. I think I fixed the problem but it's hard to be sure
>
> What sort of QA testing or automated testing can we do with the ESR to
> verify that there aren't any related regressions once landed?
Tinderbox coverage is usually pretty good for this sort of thing. The ESR patch passes the jit-tests, I'm now running it on try. Otherwise, there's not too much, because if there is a problem, it would probably be from a subtle behavioral change involving function-valued properties of JS objects created by object literals, and I don't see any particularly easy way to test for that.

Comment on attachment 623218[details][diff][review]
Patch for ESR10
Approved for landing contingent on a successful try run. If you can paste in your try run on completion before landing so we can see the tinderbox results that would be good to have here.

Sorry, I take it back - bug 643967 has now been moved to track for 14+ so I'm moving this bug to that release as well. Please do not land this patch on the current mozilla-esr10 repo, resetting approval flags as well.