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 18:38:04 UTC 2016
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:
> 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