sharedScopeCall was mostly used to reduce the memory footprint of large scripts. Similar dyn:getProp and dyn:getMethod followed by dyn:call invokedynamic instructions were replaced with a single instance of them in a static method, and their occurrences in the original bytecode replaced with invokestatic to this method.
That way, e.g. hundreds of identical call sites in mandreel.js could be replaced with just one.

Aside from saving memory by using fewer CallSites (and possibly MethodHandles), this solution also cuts down on linking costs, as all those never created call sites won't need to be linked either.

However, the solution was disabled for optimistic compilation as at the time it wasn't clear how to make it play nicely with optimistic compilation. Now though it's clear that it should be solved by emitting one sharedScopeCall method for every needed return type and optimism (e.g. optimistic double and non-optimistic int etc.), with program point passed as a parameter into the optimistic ones, which themselves optimistically invoke their target with 0 program point; UOE should also be caught in them and 0 replaced with the passed-in program point and rethrown.

Another issue that needs to be solved is adjusting the thresholds to much lower value in presence of lazy compilation. Thresholds were high to try to avoid false sharing too, but with lazy (single-function) compilation, false sharing of call sites should statistically be much less of a problem, so theoretically the thresholds could be much lower (e.g. as low as 3? We need experiments for this).