How ad-hoc should our dataPropertiesToRepair be?

We’ve been adding data properties to dataPropertiesToRepair.js on an as needed basis, since few need to be repaired, but there’s no general principle to decide which to repair.

However, https://github.com/Agoric/SES/pull/171 repairs TypeError.constructor and TypeError.name because of https://github.com/nodejs/readable-stream/blob/edd8c2d87c0f43f4f1d78407ac972fc193e45b40/errors-browser.js#L32-L33 and https://github.com/nodejs/readable-stream/blob/edd8c2d87c0f43f4f1d78407ac972fc193e45b40/errors-browser.js#L3 . It seems too ad-hoc to repair one subclass of Error and not the others. Given that we’re doing TypeError, should we go ahead and whitelist these two properties on the other FooError.prototypes?

[erights]

I have no actual perf numbers. @jfparadis, @bmeck, or @guybedford might. I’ll just speak generally. There are two performance issues: Initialization, and fast-path-calls.

Initialization

Caja repaired all function properties on all objects that seemed to be prototypes. (For historical humor, at https://github.com/google/caja/blob/master/src/com/google/caja/ses/repairES5.js#L391-L395 Caja used an odd heuristic test to determine if an object seemed to be a prototype.)

Caja had a slow initialization time for many reasons that no longer apply, so we shouldn’t take this as evidence against its repair-all-prototypes approach. I mention it because one of Caja’s main barriers to adoption on the web is that slow initialization meant long delay till a page was ready to interact with the user. This was a major barrier to adoption of Caja by web pages. Though no other host will care about this initialization time.

Our modern SES has a tiny initialization time (thanks @jfparadis!). We freeze all the primordials in something like 5 milliseconds, which is more that fine. But we need to measure the effect of repairing all prototypes before thinking of adopting that approach.

Fast Path Calls

The other overhead, which we know is already inescapable and significant, is repairing Object.prototype.toString. We must repair it because it is by far the most common property to be overridden by assignment. But because it is implicitly called when an object is coerced to a string, we know it needs to be fast. Indeed, all high performance JavaScript engines will turn this into a fast-path-call.

However, the repair means that the toString property is no longer a data property. Rather, reading the property requires calling the getter, which always returns the same toString function. But this getter-call-based access takes it out of the fast path. We already know this was bad enough to be a practical concern for some SES users.

If we repair all prototype methods, we slow all of them down in this way. It is unlikely that any one is as important as toString. But added together, they may be expensive.

All of this is easily testable, if someone wants to investigate. Please post any findings here. Thanks.

[erights]

This whitelist is now at https://github.com/Agoric/SES-shim/blob/master/packages/ses/src/enablements.js

The last expansion of the whitelist is at https://github.com/Agoric/SES-shim/commit/f0e11387fb2b84bae89d808ea7b720ca92cb6129#diff-fcd6ac2a5973959dd77e284ca6b8ca48 on May 15, to accommodate cases from “tape”. It seems to me that the initial premise is holding — that expanding the whitelist on demand as we encounter cases is an adequate coping strategy. After a moderate amount of growth, further growth slows to a crawl.

This issue is in the “Reassess” category of the SES board https://github.com/orgs/Agoric/projects/4#card-43564316 I propose that we reassess our current strategy as a successful to continue. Assuming this is uncontroversial, I am closing this bug. If you disagree, please reopen and discuss.