Deoptimize on putfield CallSite.target?

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


Krystal,

I agree with your reasoning.
There's no particular reason to keep this code.

CallSite.target is package-private and there's a contract in 
java.lang.invoke package to change it using 
MethodHandleNatives.setCallSiteTargetNormal & 
MethodHandleNatives.setCallSiteTargetVolatile.

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 CallSite.target 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
> CallSite.target as constant.
>
> There's no internal Java code that would do a putfield on a
> CallSite.target 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]:
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/38cb4fbd47e3/src/share/vm/opto/parse3.cpp#l104


More information about the hotspot-compiler-dev mailing list