To support default parameters in functions with lazily created bytecode, the ndefaults field has to move to JSFunction. This is because fooFunction.length can be called before fooFunction is invoked the first time and thus de-lazified. From a quick look at all the sites that set ndefaults, it looks like they all have access to the containing JSFunction and could set the field on that just as well.

Try run for b38b02bc6579 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=b38b02bc6579 Results (out of 1 total builds): failure: 1 Builds (or logs if builds failed) available at: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tschneidereit@gmail.com-b38b02bc6579

This adds an ndefaults field to JSFunction and keeps it in sync with the one on JSScript. Removing ndefaults from the script isn't feasible since, as opposed to what I said in comment 0, we don't always have a JSFunction available when setting ndefaults, after all.

Could you remind me why foo.length couldn't first clone the script?

That'd certainly be an option, too. You think that the case of foo.length being queried without foo being called will be too rare to bother about the needless clone?

Yeah, I wouldn't worry about trying to delay the clone; it stands to reason that if they are querying the length they are about to (or just did) call the function.

You're right, of course: Going to any lengths at all to prevent cloning here is just plain silly. This makes the new patch rather boring. To spice it up a little, I fixed an unrelated call to getOrCreateScript where the result wasn't checked. Hope that's ok.

Comment on attachment 707524 [details] [diff] [review] De-lazify a JSFunction's script before querying its ndefaults value. r=? Review of attachment 707524 [details] [diff] [review]: ----------------------------------------------------------------- Great!