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

[Tom Rodriguez]

Looks good.

tom

On Apr 20, 2011, at 9:48 AM, Christian Thalinger wrote:

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