RFR (XS): JDK-8023145: G1: G1CollectedHeap::mark_strong_code_roots() needs to handle ParallelGCThreads=0

[Stefan Karlsson]

On 8/16/13 10:35 AM, Bengt Rutisson wrote:
>
> Hi everyone,
>
> Could I have a couple of reviews for this small change?
> http://cr.openjdk.java.net/~brutisso/8023145/webrev.00/

Seems reasonable.

StefanK
>
> From the bug report:
>
> With the fix for JDK-7145569 the method 
> G1CollectedHeap::mark_strong_code_roots() was introduced. However, 
> this method assumes that the work gang has been set up. If we are 
> running with ParallelGCThreads=0 we don't set up the work gang and 
> thus get a null pointer:
>
> This simple JTreg test illustrates the issue:
>
>
> /**
>  * @test Test8000311
>  * @key gc
>  * @bug 8000311
>  * @summary G1: ParallelGCThreads==0 broken
>  * @run main/othervm -XX:+UseG1GC -XX:ParallelGCThreads=0 
> -XX:+ResizePLAB -XX:+ExplicitGCInvokesConcurrent Test8000311
>  * @author filipp.zhinkin at oracle.com
>  */
>
> import java.util.*;
>
> public class Test8000311 {
>   public static void main(String args[]) {
>     for(int i = 0; i<100; i++) {
>       byte[] garbage = new byte[1000];
>       System.gc();
>     }
>   }
> }
>
> It crashes with a null pointer:
>
> # SIGSEGV (0xb) at pc=0xffffffff7d3fadf4, pid=22622, tid=6
>
> si_addr=0x0000000000000000
>
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
> C=native code)
> V [libjvm.so+0x7fadf4] void 
> G1CollectedHeap::mark_strong_code_roots(unsigned)+0x44;; 
> __1cPG1CollectedHeapWmark_strong_code_roots6MI_v_+0x44
> V [libjvm.so+0x7f5f80] void 
> G1CollectedHeap::g1_process_strong_roots(bool,SharedHeap::ScanningOption,OopClosure*,OopsInHeapRegionClosure*,G1KlassScanClosure*,int)+0x5e0;;__1cPG1CollectedHeapXg1_process_strong_roots6MbnKSharedHeapOScanningOption_pnKOopClosure_pnXOopsInHeapRegionClosure_pnSG1KlassScanClosure_i_v_+0x5e0
> V [libjvm.so+0x7fccdc] void G1ParTask::work(unsigned)+0x67c;; 
> __1cJG1ParTaskEwork6MI_v_+0x67c
> V [libjvm.so+0x7f7500] void 
> G1CollectedHeap::evacuate_collection_set(EvacuationInfo&)+0x418;; 
> __1cPG1CollectedHeapXevacuate_collection_set6MrnOEvacuationInfo__v_+0x418
> V [libjvm.so+0x7f1a84] bool 
> G1CollectedHeap::do_collection_pause_at_safepoint(double)+0x824;; 
> __1cPG1CollectedHeapbGdo_collection_pause_at_safepoint6Md_b_+0x824
> V [libjvm.so+0x1241a7c] void VM_G1IncCollectionPause::doit()+0x2e4;; 
> __1cXVM_G1IncCollectionPauseEdoit6M_v_+0x2e4
> V [libjvm.so+0x123de38] void VM_Operation::evaluate()+0xf8;; 
> __1cMVM_OperationIevaluate6M_v_+0xf8
> V [libjvm.so+0x1239dcc] void 
> VMThread::evaluate_operation(VM_Operation*)+0x254;; 
> __1cIVMThreadSevaluate_operation6MpnMVM_Operation__v_+0x254
> V [libjvm.so+0x123a83c] void VMThread::loop()+0x654;; 
> __1cIVMThreadEloop6M_v_+0x654
> V [libjvm.so+0x1239834] void VMThread::run()+0xe4;; 
> __1cIVMThreadDrun6M_v_+0xe4
> V [libjvm.so+0xef8af0] java_start+0x258;; java_start+0x258
>
> With the proposed fix the test passes.
>
> Thanks,
> Bengt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130816/7c0c05d9/attachment.htm>