8385876: [8u] hotspot/src/share/vm/code/compiledIC.cpp:406:30: error: 'this' pointer is null

[zzambers]

Zero on gcc 14.2.0 shows these warnings, which are treated as errors by default:

/ws/jdk8u-dev/hotspot/src/share/vm/code/compiledIC.cpp: In member function 'void CompiledIC::set_to_monomorphic(CompiledICInfo&)':
/ws/jdk8u-dev/hotspot/src/share/vm/code/compiledIC.cpp:406:30: warning: 'this' pointer is null [-Wnonnull]
  406 |       csc->set_to_interpreted(method, info.entry());
      |       ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
In file included from /ws/jdk8u-dev/hotspot/src/share/vm/code/compiledIC.cpp:28:
/ws/jdk8u-dev/hotspot/src/share/vm/code/compiledIC.hpp:317:8: note: in a call to non-static member function 'void CompiledStaticCall::set_to_interpreted(methodHandle, address)'
  317 |   void set_to_interpreted(methodHandle callee, address entry);
      |        ^~~~~~~~~~~~~~~~~~

Variable csc in CompiledIC.cpp originates from instruction_address method (which technically returns NULL on Zero JVM).

/ws/jdk8u-dev/hotspot/src/share/vm/runtime/sharedRuntime.cpp: In static member function 'static methodHandle SharedRuntime::resolve_sub_helper(JavaThread*, bool, bool, Thread*)':
/ws/jdk8u-dev/hotspot/src/share/vm/runtime/sharedRuntime.cpp:1322:26: warning: 'this' pointer is null [-Wnonnull]
 1322 |         if (ssc->is_clean()) ssc->set(static_call_info);
      |             ~~~~~~~~~~~~~^~
In file included from /ws/jdk8u-dev/hotspot/src/share/vm/runtime/sharedRuntime.cpp:28:
/ws/jdk8u-dev/hotspot/src/share/vm/code/compiledIC.hpp:335:8: note: in a call to non-static member function 'bool CompiledStaticCall::is_clean() const'
  335 |   bool is_clean() const;
      |        ^~~~~~~~
/ws/jdk8u-dev/hotspot/src/share/vm/runtime/sharedRuntime.cpp:1322:38: warning: 'this' pointer is null [-Wnonnull]
 1322 |         if (ssc->is_clean()) ssc->set(static_call_info);
      |                              ~~~~~~~~^~~~~~~~~~~~~~~~~~
/ws/jdk8u-dev/hotspot/src/share/vm/code/compiledIC.hpp:345:8: note: in a call to non-static member function 'void CompiledStaticCall::set(const StaticCallInfo&)'
  345 |   void set(const StaticCallInfo& info);
      |        ^~~

Same kind of problem. Variable ssc in sharedRuntime.cpp originates from nativeCall_before method (technically NULL on Zero JVM).

Details:
This only affects JDK8 in Zero variant. Based on presence of ShouldNotCallThis(); in functions returning NULL pointer, I assume problematic code is, in fact, "dead code" and should not cause problems at runtime.

Building broken, dead code, is not optimal, but given that this is old jdk, I just made warning for affected files non-fatal.

---

• I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• JDK-8385876 needs maintainer approval
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8385876: [8u] hotspot/src/share/vm/code/compiledIC.cpp:406:30: error: 'this' pointer is null (Bug - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u-dev.git pull/836/head:pull/836
$ git checkout pull/836

Update a local copy of the PR:
$ git checkout pull/836
$ git pull https://git.openjdk.org/jdk8u-dev.git pull/836/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 836

View PR using the GUI difftool:
$ git pr show -t 836

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk8u-dev/pull/836.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back zzambers! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[mlbridge]

Webrevs

• 00: Full (e9c43269)

[tstuefe]

This only affects JDK8 in Zero variant.

Why? How is this solved in JDK 11 and later?

[zzambers]

This only affects JDK8 in Zero variant.

Why? How is this solved in JDK 11 and later?

Sorry, forgot to mention that. There were changes to affected code as part of:
8171008: Integrate AOT compiler into JDK

which apparently made problem not affect jdk11+.

I have tried to build jdk11, zero builds ok with same compiler.

[tstuefe]

Switching off warnings for whole compilation units seems a bit heavy-handed.

I would do a local warning disable with pragma. There are examples already (eg search for PRAGMA_FORMAT_NONLITERAL_IGNORED and define your own one)

[gnu-andrew]

Can you share a bit more about the environment where you reproduced this? I hit the same issue last week when building the latest 8u release on s390x Zero on CentOS 9, whereas January's release (8u482) built fine in the same environment. I also can't reproduce it locally on x86_64 Zero with GCC 14.3.1 in either release or fastdebug. This makes me suspect it is some other environment change that has triggered this warning.

Is there a reason to not add != NULL checks? Or maybe wrap the two method invocations in NOT_ZERO so as not to affect non-Zero builds? This seems better than silencing what seems like a valid warning.

I think the 11u change may not so much as solved it as created an additional level of indirection and abstraction that means the compiler can't reliably determine it any more.