RFR: JDK-8301225: Replace NULL with nullptr in share/gc/shenandoah/

[Y. Srinivas Ramakrishna]

On Fri, 27 Jan 2023 10:23:27 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/gc/shenandoah/. Unfortunately the script that does the change isn't perfect, and so we
>> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes.
>> 
>> Here are some typical things to look out for:
>> 
>> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright).
>> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL.
>> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment.
>> 
>> An example of this:
>> 
>> ```c++
>> // This function returns null
>> void* ret_null();
>> // This function returns true if *x == nullptr
>> bool is_nullptr(void** x);
>> 
>> 
>> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`.
>> 
>> Thanks!
>
> src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp line 61:
> 
>> 59:     _worker_data[i] = nullptr;
>> 60:     SHENANDOAH_PAR_PHASE_DO(,, SHENANDOAH_WORKER_DATA_nullptr)
>> 61: #undef SHENANDOAH_WORKER_DATA_nullptr
> 
> Fix these macros

My suggestion would be to leave the macro name unchanged, just change the definition. Or at least use uppercasing in the macro name. (Perhaps the latter's what your comment intended.)

More generally, is there a `jcheck` rule that will prevent re-introduction of NULL usage into the mix?

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

PR: https://git.openjdk.org/jdk/pull/12251