Request for reviews (L): 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites
Vladimir Kozlov
vladimir.kozlov at oracle.com
Tue Aug 28 15:19:26 PDT 2012
Good.
Vladimir
Christian Thalinger wrote:
> On Aug 28, 2012, at 3:09 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> Please add assert(declared_signature != NULL) after get_method() calls.
>
> Done. -- Chris
>
>> Thanks,
>> Vladimir
>>
>> Christian Thalinger wrote:
>>> On Aug 27, 2012, at 4:31 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>> On Aug 27, 2012, at 9:47 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>>
>>>>> On Aug 24, 2012, at 5:22 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>>>
>>>>>> On 8/24/12 4:07 PM, Christian Thalinger wrote:
>>>>>>> http://cr.openjdk.java.net/~twisti/7192406
>>>>>>>
>>>>>>> 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites
>>>>>>> Reviewed-by:
>>>>>>>
>>>>>>> When invokedynamic and invokehandle call sites are linked the target is a
>>>>>>> method handle adapter (static method) with a type erased signature. This
>>>>>>> also means the return type of the method is now java.lang.Object while in
>>>>>>> reality it's a more concrete type.
>>>>>>>
>>>>>>> In certain situations with inlining this can cause type mismatches.
>>>>>>>
>>>>>>> This also fixes a problem in constant pool cache where taking a lock might
>>>>>>> result in problems on Solaris.
>>>>>>>
>>>>>>> Additionally I changed GraphKit::compute_stack_effects to check if it was
>>>>>>> called from LibraryCallKit instead of passing in a flag which is very
>>>>>>> error prone.
>>>>>> What if in a future we may need to call it from LibraryCallKit *before* invoke?
>>>>> That's the only solution I could come up with right now. The problem are uncommon traps. These can be called from anywhere (parse, intrinsics, etc.) and it's difficult to have the additional parameter (which tells you before or after) always right.
>>>>>
>>>>> Maybe I should move this fix to a separate bug and try to write test cases. But it will not cover future additions.
>>>> After some discussion I'm removing this fix and file a separate bug for it. I'm also removing the CP cache fix since I hit the guarantee in one of my test runs.
>>> I updated the webrev and filed:
>>> 7194647: JSR 292: GraphKit::compute_stack_effects needs to be aware of appendix and MemberName arguments
>>> -- Chris
>>>> -- Chris
>>>>
>>>>> -- Chris
>>>>>
>>>>>> The rest changes look fine.
>>>>>>
>>>>>> thanks,
>>>>>> Vladimir
>>>>>>
>>>>>>> src/share/vm/c1/c1_GraphBuilder.cpp
>>>>>>> src/share/vm/c1/c1_GraphBuilder.hpp
>>>>>>> src/share/vm/ci/bcEscapeAnalyzer.cpp
>>>>>>> src/share/vm/ci/ciEnv.cpp
>>>>>>> src/share/vm/ci/ciEnv.hpp
>>>>>>> src/share/vm/ci/ciMethod.cpp
>>>>>>> src/share/vm/ci/ciStreams.cpp
>>>>>>> src/share/vm/ci/ciStreams.hpp
>>>>>>> src/share/vm/ci/ciTypeFlow.cpp
>>>>>>> src/share/vm/interpreter/bytecodes.hpp
>>>>>>> src/share/vm/oops/cpCacheOop.cpp
>>>>>>> src/share/vm/opto/doCall.cpp
>>>>>>> src/share/vm/opto/graphKit.cpp
>>>>>>> src/share/vm/opto/graphKit.hpp
>>>>>>> src/share/vm/opto/library_call.cpp
>>>>>>> src/share/vm/opto/parse1.cpp
>>>>>>>
>
More information about the hotspot-compiler-dev
mailing list