RFR (S) JDK-8139651 JDK-8139651, ConcurrentG1Refine uses ints for many of its members that should be unsigned types

[Joseph Provino]

On 2/19/2016 12:44 PM, Kim Barrett wrote:
>> On Feb 19, 2016, at 12:04 PM, Joseph Provino <joseph.provino at oracle.com> wrote:
>>
>> New webrev is here: http://cr.openjdk.java.net/~jprovino/8139651/webrev.02
> It looks like this incorrect change is still in place:
> src/share/vm/gc/g1/ptrQueue.hpp
> 220   size_t _process_completed_threshold;
> 242   size_t _max_completed_queue;
>
Hi Kim, I thought you said you have a fix for it in progress.
Should I just change them back to int's?

src/share/vm/gc/g1/ptrQueue.hpp
  220   size_t _process_completed_threshold;
  242   size_t _max_completed_queue;

These variables cannot presently be changed to an unsigned type.  A
negative value is treated specially for both of them, as a flag that
turns off associated behavior.  A negative _max_completed_queue means
there is no maximum.  A negative _process_completed_threshold means
never trigger concurrent processing of completed buffers.  I think the
-1 special values (converted to size_t) end up working and providing
the desired behavior by accident, which would explain why these didn't
lead to any test failures.

This is a bit of a mess, and I've got a fix for it in progress.

Unfortunately, undoing the type changes here might make a bit of a
mess elsewhere, requiring additional ugly casts.

For examples of the use of -1 for these, see the constructor for
SATBMarkQueue (_max_completed_queue) and the initialize call for the
non-Java-thread dirty card queue set in G1CollectedHeap::initialize
(both are -1).