Created attachment 405725 [details] HTML testcase We check shadowing via a lookup of the prototype property's id starting from the original object, so in general any property added after the loop starts can block the prototype property. But if the property is added to the directly referenced object (or one already enumerated along the directly referenced object's proto chain) then we won't enumerate the id at all. One fix is to snapshot all the enumerable properties' names, both direct and prototype properties, computing shadowing during the snapshotting process. We still need to check for deleted properties as we go, which means traversing the proto chain again. This seems to be what ES5 intends. /be
If __proto__ were not mutable, then when doing the initial snapshot you could cache which object each property was found on, and later check only whether the property still exists on that object. For this to be a transparent optimization, if the property is not found then you must check whether it now exists on a different object in the chain. With mutable __proto__, it's significantly more complicated. There is still a way to do this optimization, provided that you fall back to checking the full proto chain whenever *any* change to a __proto__ property has occurred since the start of the current loop (for a single-threaded interpreter, use a timestamp that increments at least when you enter a loop, and set another global to the current timestamp when you change any __proto__ property). I'm not sure whether this is worth the complexity, though.
Ah, you're planning to remove mutable __proto__: https://mail.mozilla.org/pipermail/es-discuss/2009-June/009523.html . Good idea.
Fixed by patch for bug 558754. /be
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.