Deoptimize on putfield

Vladimir Ivanov vladimir.x.ivanov at
Thu Dec 11 12:46:11 UTC 2014


I agree with your reasoning.
There's no particular reason to keep this code. is package-private and there's a contract in 
java.lang.invoke package to change it using 
MethodHandleNatives.setCallSiteTargetNormal & 

IMO, it worth a cleanup. Feel free to submit a patch.

Best regards,
Vladimir Ivanov

On 12/11/14, 2:59 AM, Krystal Mok wrote:
> Hi everyone,
> I'd like to ask a question on the handling of setting in
> compiled code.
> Specifically, is the following piece of code in C2's
> Parse::do_field_access() [1] necessary?
>    // Deoptimize on putfield writes to call site target field.
>    if (!is_get && field->is_call_site_target()) {
>      uncommon_trap(Deoptimization::Reason_unhandled,
>                    Deoptimization::Action_reinterpret,
>                    NULL, "put to call site target field");
>      return;
>    }
> If it is necessary, then why isn't it mirrored in C1's
> GraphBuilder::access_field() [2] ?
> My take is that the C2 deoptimization is unnecessary here, since a
> dependency is added when the compilers speculatively take a
> as constant.
> There's no internal Java code that would do a putfield on a
> anyway, and all external requests to change the target
> would have gone through CallSite.setTarget(), which is appropriately
> routed to the runtime already.
> I'm okay with the "it won't hurt to leave the code there" idea. Just
> want to make sure I understood things correctly.
> Thanks,
> Kris
> [1]:

More information about the hotspot-compiler-dev mailing list