A polymorphic inline cache works by caching the actual method by the type of the object, in order to avoid the expensive lookup procedures (usually a hashtable lookup). How does one handle the type comparison if the type objects are mutable (i.e. the method might be monkey patched into something different at run time). The one idea I've come up with would be a "class counter" that gets incremented each time a method is adjusted, however this seems like it would be exceptionally expensive in a heavily monkey patched environ since it would kill all the PICs for that class, even if the methods for them weren't altered. I'm sure there must be a good solution to this, as this issue is directly applicable to Javascript and AFAIK all 3 of the big JS VMs have PICs (wow acronym ahoy).
In V8, I would assume that monkeypatching would change the "hidden class" ("map" is SELF terminology) of the object. That would work in you monkey patched the object itself.
If you monkey patched the class (can you do that is JS?), I would guess it invalidates all PICs, since this is probably rare. Alternatively, it might recompile the old method to dispatch straight to the new method (after a type check I guess)
As an aside, I don't think the other "big 3" use PICs, actually. I presume you mean squirrelfish and tracemonkey. The former is an interpreter, and the latter focusses on the tracing approach, and I don't recall hearing anything about PICs. In fact, I don't think tracemonkey does anything cool at all for objects, but I could be wrong.
Only Opera 10.5 has a true polymorphic inline cache for callsites. the PIC has 6 slots, and never marks callsites as megamorphic (leading to hilarious thrashing if a callsite is highly polymorphic).
Everyone else either has no cache, or a simple (monomorphic) inline cache.