Currently, calling addMonitorStubForValue on a TypeMonitor_Fallback stub will unconditionally insert a new optimized stub handling the type of that value. This makes it unweildy to use this method to manually add stubs when we're not sure if one handling the given type already exists in the chain. Change addMonitorStubForValue to check for pre-existing optimized stubs for the type of the value it is given. After this, go through all the places where we do manual type monitors, and add a call to this method so that we pre-emptively add optimized stubs whenever we update a typeset.

This patch uses the 'uint16_t extra_' field added to IC stubs by the patch attached to bug 841535 (See comment in bug - field uses previously unused space in the stub). This patch does a few things: 1. Consolidates Type[Update|Monitor]_[Int32|Double|String|...] kinds for primitive types into just two kinds: Type[Update|Monitor]_Type. (Maybe this would be better called Type[Update|Monitor]_Primitive instead?) 2. Uses the 16-bit extra_ field on the stub to store the actual type being matched by the stub. This field is not used by the jitcode, but is useful for retreiving the JSValueType checked by the stub when inspecting it in C++. 3. Modifies all the IC chains for Monitored ops to update the monitoring chain from the fallback handler. Currently only the Call_Fallback handler does this. GetProp and GetElem don't. This avoids looping around the monitoring chain the next time the optimized stub is executed (if the same type is seen as when the optimized stub was created), and a potential small information leak (if the type seen when the optimized stub was created is not seen again, it'll still be recorded in the chain). 4. Modifies the fallback code which generates updated IC stubs to update the TypeUpdate IC chain corresponding to the stub as well.

Comment on attachment 714269 [details] [diff] [review] Clean up TypeUpdate and TypeMonitor stubs for primitive types Review of attachment 714269 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/ion/BaselineIC.h @@ +272,5 @@ > \ > _(UseCount_Fallback) \ > \ > _(TypeMonitor_Fallback) \ > + _(TypeMonitor_Type) \ Yeah, _Primitive would be better than _Type here and below.