Later we may also want to use this stub for a GETPROP accessing a dynamic slot. Main problem is that for GETGNAME the input is an unboxed object and for GETPROP we will first have to type check and unbox it. We can encode this in the key, but since these stubs are pretty straight-forward keeping them separate may be simpler.

Comment on attachment 688796 [details] [diff] [review] Patch Review of attachment 688796 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/ion/BaselineIC.cpp @@ +1002,5 @@ > > +// Attach an optimized stub for a GETGNAME/CALLGNAME op. > +static bool > +TryAttachGlobalNameStub(JSContext *cx, HandleScript script, ICGetName_Fallback *stub, > + HandleObject global, HandlePropertyName name) I'm modifying the TypeMonitor_Fallback stub's addMonitorStubForValue to check for existing stubs, so it's safe to call it with the value that this optimized IC stub is being created for, priming the type monitor chain without resorting to an extra call to it later.

Ignore that review comment. It's actually faster and better to use the IC itself to check whether to add new stubs instead of priming it when adding new stubs.