RFR: 8039244: Don't use UINT32_FORMAT and INT32_FORMAT when printing uints and ints in the GC code

[Peter B. Kessler]

On 04/04/14 12:07, Stefan Karlsson wrote:
> Vladimir,
>
> On 2014-04-04 17:58, Vladimir Kozlov wrote:
>> Stefan,
>>
>> Could you explain more why you do this? Bug report does not explain why you need this.
>> The main reason we use *_FORMAT macros is because different platforms behave differently when we use normal format's specifiers.
>
> First, *INT32_FORMAT isn't technically correct for printing ints. Though I agree that it probably works for most (all?) platforms HotSpot is run on.

If INT32_FORMAT and UINT32_FORMAT are not technically correct, then fix them.  That's a separate issue.  As Vladimir says, the whole point of those macros is to localize the changes needed to run on platforms where the native %d and %u don't work the way we expect them to.

> Second, and probably more important, we usually use %u and %d to print ints, not UINT32_FORMAT and INT32_FORMAT. By changing these few occurrences in the GC code our print code gets more uniform.
>
> This is what you get if you grep after these format specifiers:
>
> $ grep -r "%d\|%u" src/ | wc
>      3209   24297  353527
>
> $ grep -r "INT32_FORMAT" src/ | wc
>        71     517    7841
>
> $ grep -r "%d\|%u" src/share/vm/memory/ src/share/vm/gc_implementation/ | wc
>       426    3274   55241
>
> $ grep -r "INT32_FORMAT" src/share/vm/memory/ src/share/vm/gc_implementation/ | wc
>        20     151    2603

You don't seem to distinguish between code that uses native "int" and "unsigned int" types (loop counters in tracing code, generation numbers, region indexes, etc.) versus types that are the result of VM configuration (sizes, offsets, field offsets, or calculations we need to fit in 32 bits, etc.).

You don't seem to distinguish between debugging code that might have been thrown together without much thought versus logging code that we want to be consistent across platforms.

The other use of the *_FORMAT macros is for printing pointers, sizes, offsets, intx and uintx, jlong, etc.  It would be nice to be able to use *_FORMAT macros consistently, which is another argument for the whole family of them.

I agree that the types are not always used consistently in the HotSpot code.  But I'd rather we added information to the system rather than removing it.

I'm not a JDK-9 reviewer, so this is not a review.

			... peter

> thanks,
> StefanK
>
>>
>> Thanks,
>> Vladimir
>>
>> On 4/4/14 12:59 AM, Stefan Karlsson wrote:
>>> Please, review this patch to the GC code to change usages of UINT32_FORMAT and INT32_FORMAT to %u and %d when uints and
>>> ints are used.
>>>
>>> While doing this change I found, and changed, a couple of places where we used UINT32_FORMAT to print variables that
>>> were less than 4 bytes.
>>>
>>> webrev: http://cr.openjdk.java.net/~stefank/8039244/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8039244
>>>
>>> thanks,
>>> StefanK
>