RFR(S): 8180039: Use more portable print format/arguments for rlim_t

[Thomas Stüfe]

Hi Mikael,

On Thu, May 11, 2017 at 5:51 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com
> wrote:

>
> David/Mikael/Thomas,
>
> Thanks for the reviews!
>
> On May 10, 2017, at 3:51 AM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>
> Hi Mikael,
>
> this looks fine.
>
> While you are on it, would it be possible to add printouts for DATA
> and FSIZE?
>
>
>
Thanks! DATA especially is interesting on AIX, and I assume Solaris as well.


> I filed a separate follow up enhancement for this:
> https://bugs.openjdk.java.net/browse/JDK-8180184 "Add DATA and FSIZE to
> os::Posix::print_rlimit_info” and will look at that separately.
>
> Another small nit, I would prefer /1024 instead of >>10.
>
>
> I agree, and will (likely) make that change as part of the follow up work.
>
>
Thanks!


> If we want to over-engineer it we can also use the globalDefinitions.hpp
> helper functions (proper_unit_for_byte_size & byte_size_in_proper_unit) to
> print out the values using different suffixes depending on the size of the
> value. :)
>

No need :)

..Thomas


> Cheers,Mikael
>
>
> Kind Regards, Thomas
>
> On Wed, May 10, 2017 at 1:38 AM, Mikael Vidstedt <
> mikael.vidstedt at oracle.com> wrote:
>
>>
>> Please review this small change which updates the code in the
>> print_rlimit_info method in os_posix.cpp which prints out rlim_t/rlim_cur
>> values (returned from getrlimit) to use more portable format specifiers and
>> arguments/argument types.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180039 <
>> https://bugs.openjdk.java.net/browse/JDK-8180039>
>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8180039/webrev.00
>> /hotspot/webrev/ <http://cr.openjdk.java.net/~m
>> ikael/webrevs/8180039/webrev.00/hotspot/webrev/>
>>
>> The spec says that rlim_t is an "unsigned integer type”, so casting it to
>> a uint64_t will either zero extend it (if the rlim_t type is 32-bit), or
>> end up with the exact same width/value (if rlim_t is 64-bit). Printing it
>> out as a 64-bit unsigned type (using UINT64_FORMAT) will handle both the
>> 64-bit case and the zero extended 32-bit case.
>>
>> Cheers,
>> Mikael
>>
>>
>
>