1263778 - Discard the current "lazy" [[Prototype]] nomenclature, use "dynamic" instead

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jeff Walden [:Waldo]]

The current setup for prototypes that are not stored as direct values is to call them "lazy".  This is a holdover from the days of wrappers, where we'd only determine the prototype on request, "lazily".  But this isn't really right, because the wrappee's prototype could change without the wrapper knowing about it.  So every prototype access has to dynamically check the wrappee.

And then there are proxies those prototypes are fully-dynamic, computed only when accessed.  Like scripted proxies.

So really, we should just call them "dynamic", and the alternative "static".  Here's a patch that propagates this naming decision throughout SpiderMonkey.  It also makes the static/dynamic duality clearer at call sites that directly access a static prototype.  (I had to do this to verify all direct-prototype-accessing users were okay with adding [[{G,S}etPrototypeOf]] traps to scripted proxies for bug 888969.)

Comment 1

[Jeff Walden [:Waldo]]

Attachment: Patch

I manually verified all the places I touched, were correctly guarded as to static-assumptions.  Feel free to reverify if you want, or to request more comments justifying staticness if I didn't add them.  Some of the places making assumptions are really, really gnarly.  :-(

Comment 2

[Eric Faust [:efaust]]

Comment on attachment 8740200 [details] [diff] [review]
Patch

Review of attachment 8740200 [details] [diff] [review]:
-----------------------------------------------------------------

APPROVED.

::: js/src/jsiter.cpp
@@ +705,5 @@
>              ni->guard_array[ind++].init(ReceiverGuard(pobj));
> +
> +            // The one caller of this method that passes |numGuards > 0|, does
> +            // so only if the entire chain consists of cacheable objects (that
> +            // necessarily have static prototypes).

This is the kind of comment that starts off crisp and crunchy and delicious, and ends up being able to fold itself in half without so much as a crack. Is there some way that this will not inevitably be super stale?

::: js/src/jsobj.h
@@ +378,5 @@
>      bool hasTenuredProto() const;
>  
>      bool uninlinedIsProxy() const;
>  
> +#if 10

Looks like this is here by accident. Was a #if 0, that got turned back on, and then forgotten about. Please remove the #if.

Comment 3

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3c4b7e1de629

Comment 4

[Jeff Walden [:Waldo]]

(In reply to Eric Faust [:efaust] from comment #2)
> > +            // The one caller of this method that passes |numGuards > 0|, does
> > +            // so only if the entire chain consists of cacheable objects (that
> > +            // necessarily have static prototypes).
> 
> This is the kind of comment that starts off crisp and crunchy and delicious,
> and ends up being able to fold itself in half without so much as a crack. Is
> there some way that this will not inevitably be super stale?

Good question!  Short of rewriting this all to do the looping in one method, I don't think there is.  And such a rewrite is probably out of scope for this bug, although it'd be great if it happened at some point.  Maybe someone touching this code more often/frequently can do it.

Comment 5

[Carsten Book [:Tomcat]]

Hi Jeff, sorry had to back this out for assertion failures like https://treeherder.mozilla.org/logviewer.html#?job_id=26779232&repo=mozilla-inbound

Comment 6

[Pulsebot]

Backout:
https://hg.mozilla.org/integration/mozilla-inbound/rev/29f94bde2afa

Comment 7

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6ff565c59df8

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/6ff565c59df8