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