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
Fri Feb 19 20:28:54 UTC 2016


Latest is here: http://cr.openjdk.java.net/~jprovino/8139651/webrev.03

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