Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations

[Rémi Forax]

Hi Christian, hi all,
I understand that you need such kind of logic
but I think it's not compatible with the approach taken by Mark Roos
i.e flush all callsites if more than a predefined number of callsites
have installed an inlining cache.

A possible solution is to add a way in the API to know if a callsite
will trigger a deoptimization if the target changes.

Rémi

On 09/16/2011 02:02 PM, Christian Thalinger wrote:
> [This change will be pushed after 7087357.  So ignore the code removal in src/share/vm/classfile/javaClasses.cpp.]
>
> http://cr.openjdk.java.net/~twisti/7087838/
>
> 7087838: JSR 292: add throttling logic for optimistic call site optimizations
> Reviewed-by:
>
> The optimistic optimization for MutableCallSite and VolatileCallSite
> invalidate compiled methods on every setTarget.  This possibly results
> in a recompile.  For ever-changing call sites this is a performance
> hit.
>
> The fix is to add some throttling logic that prevents the optimistic
> optimization after a specified amount of invalidations per CallSite
> object.
>
> This change also moves the flush_dependents_on methods from Universe
> to CodeCache.
>
> src/share/vm/c1/c1_GraphBuilder.cpp
> src/share/vm/ci/ciCallSite.cpp
> src/share/vm/ci/ciCallSite.hpp
> src/share/vm/classfile/javaClasses.cpp
> src/share/vm/classfile/javaClasses.hpp
> src/share/vm/classfile/systemDictionary.cpp
> src/share/vm/classfile/vmSymbols.hpp
> src/share/vm/code/codeCache.cpp
> src/share/vm/code/codeCache.hpp
> src/share/vm/code/dependencies.cpp
> src/share/vm/code/dependencies.hpp
> src/share/vm/memory/universe.cpp
> src/share/vm/memory/universe.hpp
> src/share/vm/oops/methodOop.cpp
> src/share/vm/opto/callGenerator.cpp
> src/share/vm/opto/memnode.cpp
> src/share/vm/prims/jvmtiRedefineClasses.cpp
> src/share/vm/prims/methodHandles.cpp
> src/share/vm/runtime/globals.hpp
>