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

[Tom Benson]

Hi Joe,
Looks good to me.
Tom

On 2/25/2016 2:11 PM, Joseph Provino wrote:
>
>
> Latest is here: http://cr.openjdk.java.net/~jprovino/8139651/webrev.05
>
> Thanks.
>
> joe
>
>>
>> On 2/19/2016 1:38 PM, Joseph Provino wrote:
>>>
>>>
>>> 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).
>>>
>>>
>>
>