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

[Christian Thalinger]

On Apr 20, 2011, at 7:10 PM, Tom Rodriguez wrote:
> Looks good.

Thanks, Tom and Vladimir.  -- Christian

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