Bug ID: JDK-8151698 "assert(_process_completed_threshold >= 0) failed: _process_completed is negative" with big G1ConcRefinementGreenZone values on 64 bit JVM

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 9
9Fixed

After fixing JDK-8139651 JVM hits assert for big G1ConcRefinementGreenZone values.
Running TestGCOld(hotspot/test/stress/gc) with '-XX:G1ConcRefinementGreenZone=2147483648' option hits assert:
java -XX:G1ConcRefinementGreenZone=2147483648 TestGCOld 10 10 10 10 10
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/scratch/opt/jprt/T/P1/011512.daholme/s/hotspot/src/share/vm/gc/g1/ptrQueue.cpp:338), pid=11842, tid=11851
#  assert(_process_completed_threshold >= 0) failed: _process_completed is negative
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-03-10-011512.daholme.jdk9-hs-rt)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-03-10-011512.daholme.jdk9-hs-rt, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c" (or dumping to /home/dmitry/work/bugs/8059557.CLOV/bug_submit/gcold/core.11842)
#

hs_err_pid11842.log is attached.

Also can be reproduced by simple javac command:
javac -J-XX:G1ConcRefinementGreenZone=2147483648 HelloWorld.java

JVM hits assert for various big values: 1500000000, 2147483648, 4294967296, 9223372036854775807

32 bit JVM not hit assert with big G1ConcRefinementGreenZone values(e.g. 1500000000).

Fixed as a side-effect of JDK-8133051, which changed the handling of G1ConcRefinementGreenZone (and other related options) to limit their effective ranges, clipping the actually supplied value if needed.

10-05-2016

I think this might be fixed as a side effect of the changes for JDK-8133051 that I have out for review.

06-04-2016

Relates :	JDK-8133051 - Concurrent refinement threads may be activated and deactivated at random
Relates :	JDK-8139651 - ConcurrentG1Refine uses ints for many of its members that should be unsigned types