Wie wird der Speicher zwischen der JVM und dem nativen Prozess aufgeteilt?
Der Garbage Collector der JVM von Sun ist ein Mark-and-Sweep-System mit Optionen für gleichzeitige und inkrementelle GC.
Nun, genauer gesagt, es ist inszeniert, und das oben Gesagte gilt nur für dauerhafte (langlebige) Objekte. Für junge Objekte wird GC immer noch mit einem Stop-and-Copy-Collector durchgeführt, der viel besser für die Arbeit mit kurzlebigen Objekten geeignet ist (und alle typischen Java-Programme erzeugen viele kurzlebige Objekte).
Ein Kopiersammler geht über alle Elemente im Heap, kopiert sie in einen neuen Heap, wenn sie referenziert sind, und verwirft dann den alten Heap. 1 Mio. lebende Objekte benötigen also bis zu 2 Mio. realen Speicher: Wenn jedes Objekt lebendig ist, gibt es während der Garbage Collection zwei Kopien von allem.
Die JVM benötigt also weit mehr Systemspeicher, als dem in der VM ausgeführten Code zur Verfügung steht, da ein erheblicher Overhead bei der Verwaltung und der Garbage Collection entsteht.
Hat der Windows-Schalter /3GB irgendeine Auswirkung auf native Prozesse und Sun JVM?
El /3GB erlaubt es, dass der Adressraum des virtuellen Benutzerspeichers 3 GB beträgt, aber nur für ausführbare Dateien, deren Header mit IMAGE_FILE_LARGE_ADDRESS_AWARE . Soweit ich weiß, ist Sun's java.exe ist nicht. Ich habe kein Windows-System hier, kann das also nicht überprüfen.
