RFR: JDK-8074459 - Flags handling memory sizes should be of type size_t

[Jesper Wilhelmsson]

Hi Kim and Thomas,

Thanks for the reviews!

A new webrev is available here:

http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.02/

There is an incremental diff as well with the latest changes suggested by you.

Thanks,
/Jesper


Kim Barrett skrev den 11/3/15 18:48:
> On Mar 11, 2015, at 9:54 AM, Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review this change to make most flags handling memory sizes to be of type size_t. Flags dealing with code heap and code cache are not included in this change. Se the bug for details.
>>
>> The change is surprisingly small considering the amount of flags changed. Most variables around these flags was already of type size_t so there are only a few places where related code had to change in some way.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074459
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8074459/webrev.01/
>>
>> Testing: jprt, jtreg tests
>>
>> Thanks,
>> /Jesper
>
> Looks good.
>
> Just a couple of minor issues, plus a new CR to file for a
> pre-existing problem I noticed during the review.
>
> ------------------------------------------------------------------------------
> src/share/vm/gc_implementation/g1/g1RemSet.cpp
> src/share/vm/gc_implementation/g1/g1_globals.hpp
>
> Update copyright.
>
> ------------------------------------------------------------------------------
> src/share/vm/runtime/sweeper.cpp
>
> No changes, other than copyright update?
>
> ------------------------------------------------------------------------------
> src/share/vm/utilities/ostream.hpp
>
>   253              ((GCLogFileSize != 0) && ((size_t)_bytes_written >= GCLogFileSize));
> [changed cast of _bytes_written from uintx to size_t]
>
> On a 32bit platform this is, and always has been, a narrowing
> conversion, because _bytes_written is declared to be of type
> jlong.  But GCLogFileSize is of type size_t (was uintx).  If, on a
> 32bit platform, GCLogFileSize were set to something large, like
> (1 << 32) - 1 and the log grew large, rotation would probably not
> occur as expected.
>
> This is a pre-existing problem, and should be dealt with via a
> separate CR.
>
> ------------------------------------------------------------------------------
>