Limite overhead GC superato

Qual è il tempo di campionamento utilizzato da JVM per lanciare "java.lang.OutOfMemoryError: limite di overhead GC superato"? So che puoi controllare il 98% e il 2% con i parametri GCTimeLimit e GCHeapFreeLimit ma qual è il tempo di campionamento?

Da Java SE 6 HotSpot [tm] Ottimizzazione raccolta dati inutili della macchina virtuale

il seguente

Tempo GC eccessivo e OutOfMemoryError

Il collector simultaneo lancerà un OutOfMemoryError se viene speso troppo tempo nella garbage collection: se più del 98% del tempo totale viene speso nella garbage collection e meno del 2% dell'heap viene recuperato, verrà lanciato un OutOfMemoryError. Questa funzionalità è progettata per impedire l'esecuzione delle applicazioni per un periodo di tempo prolungato, facendo progressi minimi o nulli perché l'heap è troppo piccolo. Se necessario, questa funzione può essere disabilitata aggiungendo l'opzione -XX: -UseGCOverheadLimit alla riga di comando.

La politica è la stessa del raccoglitore parallelo, tranne per il fatto che il tempo impiegato per eseguire raccolte simultanee non viene conteggiato per il limite di tempo del 98%. In altre parole, solo le raccolte eseguite mentre l'applicazione è interrotta contano per un tempo GC eccessivo. Tali raccolte sono in genere dovute a un errore in modalità simultanea oa una richiesta di raccolta esplicita (ad esempio, una chiamata a System.gc ()).

in congiunzione con un passaggio più in basso

Uno degli utilizzi più comuni della garbage collection esplicita si verifica con la garbage collection distribuita (DGC) di RMI. Le applicazioni che utilizzano RMI fanno riferimento a oggetti in altre macchine virtuali. Non è possibile raccogliere dati inutili in queste applicazioni distribuite senza raccogliere occasionalmente l'heap locale, quindi RMI forza periodicamente le raccolte complete. La frequenza di queste raccolte può essere controllata con le proprietà. Per esempio,

java -Dsun.rmi.dgc.client.gcInterval=3600000

-Dsun.rmi.dgc.server.gcInterval=3600000 specifica la raccolta esplicita una volta all'ora invece della frequenza predefinita di una volta al minuto. Tuttavia, ciò potrebbe anche far sì che alcuni oggetti impieghino molto più tempo per essere recuperati. Queste proprietà possono essere impostate fino a Long.MAX_VALUE per rendere effettivamente infinito il tempo tra le raccolte esplicite, se non si desidera un limite superiore alla tempestività dell'attività DGC.

Sembra implicare che il periodo di valutazione per determinare il 98% sia lungo un minuto, ma potrebbe essere configurabile sulla JVM di Sun con la definizione corretta.

Ovviamente sono possibili altre interpretazioni.