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

Rémi Forax forax at univ-mlv.fr
Sat Sep 17 02:33:10 PDT 2011

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 flushdependentson methods from Universe to CodeCache. src/share/vm/c1/c1GraphBuilder.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

More information about the hotspot-compiler-dev mailing list