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 > _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
