Request for review (S): 6993078: JSR 292 too many pushes: Lesp points into register window

Tom Rodriguez tom.rodriguez at oracle.com
Wed Apr 20 09:12:51 PDT 2011


Why are you using atomic_compare_exchange_oop?  The f1 field should never be compressed.

tom

On Apr 20, 2011, at 8:45 AM, Christian Thalinger wrote:

> http://cr.openjdk.java.net/~twisti/6993078/
> 
> 6993078: JSR 292 too many pushes:  Lesp points into register window
> Reviewed-by:
> 
> The logic in InterpreterRuntime::resolve_invokedynamic already handles
> the possible race of different threads installing the CallSite object
> in the constant pool cache properly.  To short circuit the CallSite
> object creation the f1 field in the constant pool cache is checked for
> non-null values.
> 
> ConstantPoolCacheEntry::set_dynamic_call first sets f1 atomically and
> later other fields like flags.  The window between setting f1 and the
> flags in one thread makes it possible that another thread already sees
> the non-null f1 value but flags is still uninitialized.  That can
> result in very strange behaviour since flags encodes the TosState and
> the parameter size.
> 
> The fix is to set all other values first (currently that's only flags)
> and f1 as very last.
> 
> The patch also includes some cleanup and additional verify_oop's in
> TemplateTable::invokedynamic.
> 
> src/cpu/sparc/vm/templateTable_sparc.cpp
> src/cpu/x86/vm/templateTable_x86_32.cpp
> src/cpu/x86/vm/templateTable_x86_64.cpp
> src/share/vm/ci/ciEnv.cpp
> src/share/vm/oops/cpCacheOop.cpp
> src/share/vm/oops/cpCacheOop.hpp
> 



More information about the hotspot-compiler-dev mailing list