L'heap automatico Java aumenta "trasparente" o ha un costo?

Question

ho intenzione di spiegare meglio:

E 'preferibile insieme con -Xms <> parametro JVM memoria atteso o è meglio lasciarlo in automatico? Voglio dire, se so che la mia applicazione utilizzerà almeno 500 MB di RAM e massimo 1 GB (numeri casuali usati), impostare il parametro su JVM sarebbe meglio? So che se hai un mucchio più grande la conseguenza è che hai tempi di attesa più lunghi ma se l'heap è quasi finito, la JVM dovrebbe riposizionare la memoria occupata (perdere tempo prezioso)?

graph http://upperpix.com/di-F0LD.png

Answer 1

Il processo di espansione mucchio fa influire sulle prestazioni. Tuttavia, gli effetti dipendono dal tipo di prestazioni di cui si sta parlando.

Un criterio di prestazione è la percentuale di tempo del processore utilizzata per "eseguire la garbage collection"; cioè "rendimento". I GC che ottimizzano il throughput tendono a funzionare meglio con un grande heap. Quindi, in questo caso, una semplice analisi dice che farai meglio l'allocazione dell'heap alla dimensione che ti aspetti di essere richiesta ... invece di iniziare in piccolo e fare affidamento sul GC per espandere l'heap.

Un altro criterio di prestazione è il tempo di pausa. Tuttavia, il comportamento dei collettori di "bassa pausa" è troppo complicato per lo stile semplicistico di analisi di cui sopra. (E non so come funziona in pratica ...)

---

C'è un aspetto che si applica su tutta la linea. Supponendo che l'utilizzo dell'heap dell'applicazione raggiunga uno stato (approssimativamente) stazionario e presumendo che raggiunga quello stato nella fase iniziale della vita della JVM, le varie spese generali relative alle prestazioni coinvolte nel raggiungimento dello stato stazionario (ovvero i costi generali di "riscaldamento" dell'applicazione).) tenderà ad essere insignificante.