Co powoduje, że moduł zbierający śmieci G1 w Javie 7 przerywa fazę współbieżnego znaku?

Question

Zauważyłem sporadyczne pełne GC w mojej aplikacji używając G1 garbage collector i staram się dowiedzieć, dlaczego tak się dzieje.

Cykl z jednego regionu - skanowanie do następnego jest opisany poniżej. Przy 61807.406 rejestrowane jest pełne GC, a następnie wpis dla współbieżnego znaku-przerwania. Chciałbym wiedzieć, dlaczego GC poczuł potrzebę zrobienia pełnego, zatrzymania świata, zbierania śmieci i tego, jak mogę tego uniknąć.

Zauważ, że wydaje się być wcześniej zadawane na liście adresowej OpenJDK, bez odpowiedzi.

Zmniejszyłem szczegóły młodych GC dla zwięzłości, ale w razie potrzeby mogę opublikować pełny fragment.

61805.878: [GC concurrent-root-region-scan-start] 
61805.882: [GC concurrent-root-region-scan-end, 0.0033586] 
61805.882: [GC concurrent-mark-start] 
61806.133: [GC pause (young), 0.02836202 secs] 
    [Eden: 498M(498M)->0B(478M) Survivors: 14M->34M Heap: 3025M(4096M)->2548M(4096M)] 
[Times: user=0.19 sys=0.00, real=0.03 secs] 
61806.426: [GC pause (young), 0.02766222 secs] 
    [Eden: 478M(478M)->0B(480M) Survivors: 34M->32M Heap: 3050M(4096M)->2576M(4096M)] 
[Times: user=0.19 sys=0.00, real=0.03 secs] 
61806.717: [GC pause (young), 0.02214895 secs] 
    [Eden: 480M(480M)->0B(502M) Survivors: 32M->10M Heap: 3056M(4096M)->2571M(4096M)] 
[Times: user=0.09 sys=0.00, real=0.02 secs] 
61807.000: [GC pause (young), 0.01899188 secs] 
    [Eden: 502M(502M)->0B(502M) Survivors: 10M->10M Heap: 3074M(4096M)->2573M(4096M)] 
[Times: user=0.09 sys=0.00, real=0.02 secs] 
61807.201: [GC pause (young), 0.02619259 secs] 
    [Eden: 162M(502M)->0B(500M) Survivors: 10M->12M Heap: 3036M(4096M)->2876M(4096M)] 
[Times: user=0.11 sys=0.00, real=0.03 secs] 
61807.283: [GC pause (young), 0.02068515 secs] 
    [Eden: 102M(500M)->0B(500M) Survivors: 12M->12M Heap: 3058M(4096M)->2957M(4096M)] 
[Times: user=0.09 sys=0.00, real=0.02 secs] 
61807.350: [GC pause (young), 0.01606520 secs] 
    [Eden: 52M(500M)->0B(498M) Survivors: 12M->14M Heap: 3020M(4096M)->2969M(4096M)] 
[Times: user=0.11 sys=0.00, real=0.02 secs] 
61807.389: [GC pause (young), 0.01573865 secs] 
    [Eden: 42M(498M)->0B(500M) Survivors: 14M->12M Heap: 3021M(4096M)->2978M(4096M)] 
[Times: user=0.09 sys=0.00, real=0.02 secs] 
61807.406: [Full GC 2978M->2498M(4096M), 4.8896638 secs] 
[Times: user=6.37 sys=0.08, real=4.89 secs] 
61812.296: [GC concurrent-mark-abort] 
61812.542: [GC pause (young), 0.01526403 secs] 
    [Eden: 512M(500M)->0B(510M) Survivors: 0B->2048K Heap: 3018M(4096M)->2506M(4096M)] 
[Times: user=0.09 sys=0.00, real=0.02 secs] 
61812.793: [GC pause (young) (initial-mark), 0.01391544 secs] 
    [Eden: 510M(510M)->0B(508M) Survivors: 2048K->4096K Heap: 3016M(4096M)->2508M(4096M)] 
[Times: user=0.09 sys=0.00, real=0.01 secs] 
61812.807: [GC concurrent-root-region-scan-start] 

To jest za pomocą Java Hotspot 1.7.0_7 zwolnienie z następującymi ciekawych ustawień:

-XX:PermSize=128m 
-XX:MaxPermSize=128m 
-XX:NewSize=512m 
-XX:MaxNewSize=512m 
-Xms4096m 
-Xmx4096m 
-XX:+UnlockDiagnosticVMOptions 
-XX:+UnsyncloadClass 
-XX:+UseTLAB 
-XX:+UseG1GC 
-XX:SurvivorRatio=10 
-Xloggc:./workspace/gc.log 
-verbose:gc 
-XX:+PrintGC 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDetails 

Answer 1

Przypuszczam wiesz o this reference. Użyteczne jest również This page.

Pełne oznaczenia GC występują, gdy przedmioty na stałe - te, które przetrwały gromadzenie w efemerycznym (młodym) pokoleniu - wypełniają przeznaczoną dla nich przestrzeń. Gdy pojawi się pełna wartość GC, wszelkie efemeryczne oznaczenia, które były w toku, muszą zostać przerwane.

Zmniejszenie tempa, w którym napełnia się wymieniana generacja, wymaga dodania większej ilości sterty/pamięci RAM lub manipulowania przy podziale dostępnej pamięci między przestrzeniami młodymi i młodymi. Parametry NewSize, , ,Eksperyment jest jedynym sposobem na znalezienie tego, co zadziała.

Powszechnie wiadomo, że przesunięcie wskaźnika w celu zwiększenia nominalnego pokolenia zmniejsza liczbę pełnych kolekcji. W wielu przypadkach jest to prawda, ale nie zawsze. Istnieje stan, w którym wiele nieruchomych obiektów staje się martwe wkrótce po ich wykonaniu. Innymi słowy, powinny one zostać zebrane w młodym regionie, ale ich życie skończyło się nieco za późno. W tym przypadku powiększenie młodego pokolenia pozwala na zbieranie tych obiektów zamiast na stałe. Objawem tego jest pełny odbiór powodujący duży spadek przydzielonej przestrzeni.

To nie wygląda na Twój przypadek: 2978M->2498M. Twoje jedyne wyjście może polegać na powiększeniu sterty, kupując więcej pamięci w razie potrzeby. Mimo to prawie wszystkie systemy, które działają od dłuższego czasu, będą miały od czasu do czasu pełną kolekcję.