Once JDK-8191998 is fixed, there may be a speculative type available for the receiver. But Compile::call_generator() ignores it since there's no receiver profile available.
CallGenerator* Compile::call_generator(ciMethod* callee, int vtable_index, bool call_does_dispatch,
JVMState* jvms, bool allow_inline,
float prof_factor, ciKlass* speculative_receiver_type,
bool allow_intrinsics, bool delayed_forbidden) {
...
int receiver_count = -1;
if (call_does_dispatch && UseTypeProfile && profile.has_receiver(0)) {
// Receivers in the profile structure are ordered by call counts
// so that the most called (major) receiver is profile.receiver(0).
receiver_count = profile.receiver_count(0);
}
...
// Try using the type profile.
if (call_does_dispatch && site_count > 0 && receiver_count > 0) {
receiver_count is always -1 for MH::linkTo*, so speculative_receiver_type isn't used to predict receiver type.
CallGenerator* Compile::call_generator(ciMethod* callee, int vtable_index, bool call_does_dispatch,
JVMState* jvms, bool allow_inline,
float prof_factor, ciKlass* speculative_receiver_type,
bool allow_intrinsics, bool delayed_forbidden) {
...
int receiver_count = -1;
if (call_does_dispatch && UseTypeProfile && profile.has_receiver(0)) {
// Receivers in the profile structure are ordered by call counts
// so that the most called (major) receiver is profile.receiver(0).
receiver_count = profile.receiver_count(0);
}
...
// Try using the type profile.
if (call_does_dispatch && site_count > 0 && receiver_count > 0) {
receiver_count is always -1 for MH::linkTo*, so speculative_receiver_type isn't used to predict receiver type.
- relates to
-
JDK-8191998 C2: inlining through MH linkers drops speculative part of argument types
- Resolved