RFR (S) JDK-8139651 JDK-8139651, ConcurrentG1Refine uses ints for many of its members that should be unsigned types
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:
>> It looks like this incorrect change is still in place:
>> 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?
> 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