RFR: 8340620: Fix -Wzero-as-null-pointer-constant warnings for CompressedOops

[Kim Barrett]

On Thu, 26 Sep 2024 09:21:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this change that fixes -Wzero-as-null-pointer-constant warnings
>> in CompressedOops code.  These all relate to CompressedOops::base().
>> 
>> I also added a couple of asserts to verify our assumptions about null pointer
>> constants being representationally zero. That isn't a Standard-conforming
>> assumption, but holds for all platforms we currently support. I considered,
>> and even explored, a couple of different options.
>> 
>> (1) Continue to have CompressedOops::base() be a pointer, but avoid that
>> assumption, being more careful about how zero-valued pointers are treated. But
>> that adds significant complexity that we can't test, since we don't support
>> any platforms needing that extra work.
>> 
>> (2) Change CompressedOops::base() to an integral adjustment.  This is probably
>> the correct approach, but is much more intrusive and wide ranging in the
>> changes required.  Maybe something for the future.
>> 
>> Testing: mach5 tier1-5
>> GHA testing, verifying builds on some platforms not supported by Oracle.
>> 
>> There are some simple changes to s390 and ppc code that I haven't tested,
>> beyond verifying compilation.
>
> FWIW, I think these asserts adds extra noise to these functions and I don't think we will be much more happy about having to read them over and over again when we read this functions / debug code through these functions. I would have preferred if this was one of those things that we require from our platforms and place a check in globalDefinitions, or some other prominent place that checks HotSpot's assumptions of the compilers / platforms.

@stefank wrote:
> > FWIW, I think these asserts adds extra noise to these functions [...]
> 
@kimbarrett replied
> Implementing option 2 (making base() an integral offset) would remove that assumption here, and allow removal of the assertions currently proposed here. And I generally prefer placing asserts with the expecting code. OTOH, I think it's nearly certain there are other places where we make the same assumption. (And I'd forgotten we have some assumption checks in globalDefinitions.cpp.) I don't have a strong opinion in this area.

@stefank and I discussed this offline.  I've removed the asserts, as they are just kind of executable comments that
aren't going to help catch any bugs.  As a separate task we're going to consider adding a file that checks various
assumptions like this, as a way of documenting assumptions we make.

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

PR Comment: https://git.openjdk.org/jdk/pull/21172#issuecomment-2378804197