Bug ID: JDK-8149343 assert(rp->num_q() == no_of_gc

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 8	JDK 9
8u401Fixed	9 b115Fixed

G1 asserts with 

G1: assert(rp->num_q() == no_of_gc_workers) failed: sanity

running the following program 

public class GCTest {
  private static byte[] garbage;
  public static void main(String [] args) {
    System.out.println("Creating garbage");
    // create 128MB of garbage. This should result in at least one GC
    for (int i = 0; i < 1024; i++) {
      garbage = new byte[128 * 1024];
    }
    System.out.println("Done");
  }
}

with

-Xmx10m -XX:+UseG1GC -XX:+UseDynamicNumberOfGCThreads -XX:+ParallelRefProcEnabled

Seems to be a re-appearance of JDK-8055250.

Reported by G. Lindenmaier in the following mail to hotspot-gc-dev:

http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-February/016481.html

The suggestion there is to add this case to gc/ergonomics/TestDynamicNumberOfGCThreads.java

URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b9efb94d011a User: lana Date: 2016-04-20 17:53:12 +0000
20-04-2016
URL: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b9efb94d011a User: jmasa Date: 2016-03-21 19:59:50 +0000
21-03-2016
The error here was that the number of active workers was not always set correctly for parallel Reference processing. The first fix was to set the number of active workers in the ReferenceProcessor in the task constructor. Once that was fixed a subsequent assertion failure occurred. # Internal Error (/export/jmasa/java/jdk9-rt-8149343/src/share/vm/gc/shared/referenceProcessor.cpp:884), pid=18444, tid=18500 # assert(id < _max_num_q) failed: Id is out-of-bounds id 23 and max id 23) This was fixed by the change - if (++_next_id == _num_q) { + assert(!_discovery_is_mt, "Round robin should only be used in serial discovery"); + if (++_next_id >= _num_q) { See the attached log which shows _num_q changing values between different phases of a collection and where the value of _next_id was greater than _num_q. If may also fix this problem if _num_q was changed to _max_num_q (my testing showed it worked) + if (++_next_id >= _max_num_q) { but I don't understand the comment 326 // round-robin mod _num_q (not: _not_ mode _max_num_q) which was added to fix a bug where the number of concurrent CMS threads exceeded the number of CMS parallel threads and didn't want to chance it. The last change was to add a parameter to the logging function so that the logging only output the active lists (which made the reading of the logs simpler) - void log_reflist_counts(DiscoveredList ref_lists[], size_t total_count) PRODUCT_RETURN; + void log_reflist_counts(DiscoveredList ref_lists[], uint active_length, size_t total_count) PRODUCT_RETURN;
09-03-2016
Log with added output showing progression of _next_id.
09-03-2016
A call to rp->set_active_mt_degree(no_of_gc_workers) before the call to process_discovered_references seems to be missing, looking at other collector's code.
08-02-2016

Relates :	JDK-8145092 - Use Unified Logging for the GC logging
Relates :	JDK-8055250 - G1: assert(rp->num_q() == no_of_gc_workers) failed: sanity