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

[Christian Thalinger]

On Apr 20, 2011, at 6:12 PM, Tom Rodriguez wrote:
> Why are you using atomic_compare_exchange_oop?  The f1 field should never be compressed.

Right, I think I misunderstood something.  webrev is updated.

-- Christian

> 
> 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