RFR: 8343800: Cleanup definition of NULL_WORD

[David Holmes]

On Mon, 2 Dec 2024 11:47:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/utilities/globalDefinitions.hpp line 563:
>> 
>>> 561: const jfloat max_jfloat = jfloat_cast(max_jintFloat);
>>> 562: 
>>> 563: // A named constant for the integral representation of a Java null.
>> 
>> Some commentary on when/where/why to use this would be good. I see it being used in a lot of places related to oops (exceptions, VMResult) but other uses are not obviously (to me) Java object related.
>
> I _think_ this change could have been made a long time ago.  But there was messy stuff related to 32bit, and
> also maybe Solaris?  It was also hard to tell, because of the conflation with NULL and the various complexities
> there.
> 
> I think some of the current uses could be classed as abuse, but again, it's hard to know without a little more
> clarity in its definition.  I made a couple of attempts at cleaning up usage a while ago, but ended up abandoning
> them because of that lack of clarity.  What came out of that was the realization that something like this might
> be possible, and would be a useful precursor to usage changes.  That comment is my stake in the ground for
> helping to distinguish good uses vs abuse.  I'm planning to revisit uses with that in mind.
> 
> The vast majority of uses are in x86/x64 assembly code, where I think it is usually about encoding a Java null
> in an instruction.  I've looked at changing how that's done, but the messiness of the definition, crossed with
> the 32/64bit issues there, again led me to balk.  Nuking 32bit x86 might reduce the complexity to something
> more manageable.

Okay. Maybe NULL_OOP might be a better way to spell this in the future?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22468#discussion_r1865726762