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

Joseph Provino joseph.provino at oracle.com
Thu Feb 25 19:11:40 UTC 2016



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).
>>
>>
>




More information about the hotspot-gc-dev mailing list