Perché Java ha un ingombro così ampio?

Java - o almeno JVM Hotspot di Sun - ha avuto a lungo una reputazione per avere un ingombro di memoria molto grande. Che cosa è esattamente della JVM che dà questa reputazione? Sarei interessato a una suddivisione dettagliata: quanta memoria va al runtime (il JIT? Il GC/gestione della memoria? Il classloader?) Qualsiasi cosa relativa alle API "ausiliarie" come JNI/JVMTI? le librerie standard? (quali parti ottengono quanto?) altri componenti principali?Perché Java ha un ingombro così ampio?

Mi rendo conto che questo può non essere semplice per rispondere senza un'applicazione concreta più la configurazione VM, quindi solo per restringere le cose almeno in qualche modo: sono principalmente interessato alle configurazioni default/tipiche della VM e in una console di base " Hello world "app oltre a qualsiasi app desktop o server del mondo reale. (Sospetto che una parte sostanziale dell'impronta della JVM sia largamente indipendente dall'app stessa, ed è in questa parte che mi piacerebbe ingrandire, idealmente.)

Ho un altro paio di altri domande correlate:

Altre tecnologie simili, come .NET/mono, non presentano quasi lo stesso ingombro. Perché è così?
Ho letto da qualche parte sul intarwebs che una grande parte del footprint è dovuta semplicemente alla dimensione delle librerie standard. Se questo è il caso, allora perché molte delle librerie standard vengono caricate in anticipo?
Ci sono degli sforzi (JSR, qualsiasi cosa) per domare l'impronta della memoria? La cosa più vicina che ho incontrato è un progetto a reduce the on-disk footprint of the JVM.
Sono sicuro che l'impronta è variata negli ultimi dieci anni circa con ogni nuova versione di Java. Ci sono numeri/grafici specifici che descrivono esattamente quanto è cambiata l'impronta della JVM?

fonte

2009-07-10 Yang

Si dovrebbero postare collegamenti ovunque si siano ottenute le informazioni da cui la macchina virtuale HotSpot "... ha da tempo la reputazione di avere un ingombro di memoria molto grande". –

Questa "reputazione" non è altro che un'eredità di Java 1.1 e 1.2 quando Java era giovane. – aberrant80

Non penso che sia del tutto equo - Java non è cresciuto di molto da allora, abbiamo solo un * lotto * in più di RAM con cui giocare. Chiaramente la dimensione del runtime sta danneggiando alcune persone, forse il progetto Jigsaw potrebbe non esistere. –

Abbiamo alcune app lato server che non fanno altro che il bridge del traffico multicast (ovvero non hanno uno stato permanente). Corrono tutti con circa 2,3 - 2,5 Mb di Heap su un JRE Java6 (linux) a 32 bit.

Si tratta di un'impronta importante? Potrei facilmente avere un migliaio di di questi su un tipico server-class machine (da una prospettiva memoria), anche se sarebbe un po 'inutile da una prospettiva threading!

Detto questo, c'è il Jigsaw project per modulare la VM (le librerie credo) che sta arrivando in Java7; questo aiuterà coloro che desiderano impronte più piccole.

Mi rendo conto che questo in realtà non risponde alla tua domanda ma è comunque rilevante! Che tipo di applicazioni stai progettando dove stai riscontrando che l'impronta della memoria è un problema?

fonte

2009-07-10 06:34:22

Bene, ho ora un'applicazione Java (NetBeans) in esecuzione e java.exe utilizza 230 MB di memoria al momento. Non lo chiamerei un piccolo ingombro. –

Questo non ha nulla a che vedere con * l'impronta di Java * e tutto ciò che ha a che fare con l'applicazione NetBeans! IntelliJ IDEA usa spesso oltre 700 Mb di heap, perché ho più progetti aperti e ha indicizzato * tutto * in memoria per la velocità –

Imho 230 MB per tale IDE è piccolo. La memoria è a buon mercato ora comunque. – GvS

Almeno una cosa è la lunga storia di Java: è iniziata nel 1995 ed è ora la versione 6. Mantenere la retrocompatibilità mentre si aggiungono funzionalità gonfia inevitabilmente il suo ingombro. immagine This dice più o meno ...

fonte

2009-07-10 06:48:22

Penso che potresti trovare un po 'fuorviante. –

Cosa intendi? –

Diciamo che il runtime è aumentato di dimensioni di un fattore di 7 in 12 anni. La RAM media di un PC è aumentata nello stesso tempo da circa ~ 100 Mb a ~ 2 GB; un fattore di 20. Ciò significa che in termini reali il JDK si è ridotto di un fattore pari a 3. –

Alcune iniziative:

Dal 1.5 class data sharing può essere utilizzato;
Java 6 aggiornamento 14 introdotto in compressed oops che riduce l'ingombro di JVM a 64 bit con meno di 4 GB di Heap.

fonte

2009-07-10 07:02:54

Perché Java ha un ingombro così ampio?

risposta

Problemi correlati