RFR: 8263430: Uninitialized Method* variables after JDK-8233913

Aleksey Shipilev shade at openjdk.java.net
Thu Mar 11 14:24:18 UTC 2021


On Thu, 11 Mar 2021 14:16:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> SonarCloud instance reports problems like:
>>  The left operand of '==' is a garbage value
>> 
>> C2V_VMENTRY_NULL(jobject, getResolvedJavaMethod, (JNIEnv* env, jobject, jobject base, jlong offset))
>>   Method* method;
>>  ...
>>   if (method == NULL) { // <--- here
>>     JVMCI_THROW_MSG_NULL(IllegalArgumentException, err_msg("Unexpected type: %s", JVMCIENV->klass_name(base_object)));
>>   }
>> 
>> I believe this is caused by refactoring in [JDK-8233913](https://bugs.openjdk.java.net/browse/JDK-8233913) that [replaced](https://hg.openjdk.java.net/jdk/jdk/rev/15936b142f86#l39.38) `methodHandle` with naked `Method*`. `methodHandle` is implicitly initialized to null, while naked variable is not. After reading the original changeset, I found two other places where the same thing happens.
>
> src/hotspot/share/interpreter/linkResolver.cpp line 1153:
> 
>> 1151:   // superinterface.method, which explicitly does not check shadowing
>> 1152:   Klass* resolved_klass = link_info.resolved_klass();
>> 1153:   Method* resolved_method = NULL;
> 
> Why would it complain about this one?  resolved_method is going to get some value in the next 4 lines.

Ah yes, it does not complain about this one. I just initialized all locals that were introduced in your original change. I can revert this hunk, if you want.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2936


More information about the hotspot-dev mailing list