jvm; Xmx einstellen

[Ferra]

Hallo zusammen,

also standardmässig hat die JVM 64MB. Das hat bisher auch immer gereicht. Wenn mein Prog nun aber statt einer 1MB großen Exceltabelle, eine 8MB große Tabelle verarbeiten soll, bekomme ich eine OutOfMemory-Exception um die Ohren gehauen.
Also habe ich die JVM mit -Xmx160m starten müssen. Dann hats geklappt. Keine Ahnung, woher der Speicherhunger herkommt. Das werd ich nochmal checken. Wie auch immer. Gibt es eine Möglichkeit, den max. Speicher für die JVM während der Laufzeit (also quasi bedarfsweise) zu erhöhen?

 

[The_S]

http://www.java-forum.org/de/viewtopic.php?t=16199&highlight=

zuerst suchen!!!

 

[Ferra]

Hm,

das scheint mir zu einfach.

Soweit ich weiß, fängt der GC erst an aufzuräumen, wenn aller zu Verfügung stehender Speicher allokiert ist. Das bedeutet jedoch, wenn ich anfangs zu großzügig Speicher spendiere, hat der GC reichlich zu tun. Und die gesamte JVM steht dann quasi still.

Und ist es nicht so, daß der durch Xmx allokierte Speicher sofort für den Rest des Rechners nicht mehr zur Verfügung steht, auch wenn die JVM nur, sagen wir mal nur 20% davon braucht?

 

[dotlens]

Soweit ich weiß, fängt der GC erst an aufzuräumen, wenn aller zu Verfügung stehender Speicher allokiert ist.

Dann weisst du wohl nicht weit :bae:

Spass bei Seite:
Speichererhöhung:
Option "-Xmx256m" (max-wert setzen)
Option "-Xms64m" (start-wert setzen)
was denkst du wozu der start.wert gut ist?
Richtig, soviel Speicherplatz wird von ANFANG an benötigt.
und der May wer, wozu könnte der owhl gut sein?
Ich überlass es dir dies zu erraten.

Der GC kann man nicht selbst aufrufen, man kann ihn höchstens bitten aufzuräumen, aber es ist ihm überlassen ob er dies tut. Aber er wartet ganz bestimmt nicht bis der ganze speicherplatz voll ist...

 

[Grizzly]

[...]
Soweit ich weiß, fängt der GC erst an aufzuräumen, wenn aller zu Verfügung stehender Speicher allokiert ist. Das bedeutet jedoch, wenn ich anfangs zu großzügig Speicher spendiere, hat der GC reichlich zu tun. Und die gesamte JVM steht dann quasi still.
[...]

[...]
Aber er wartet ganz bestimmt nicht bis der ganze speicherplatz voll ist...

Der Garbage Collector wird öfters während der Laufzeit aktiv. Spätestens allerdings, wenn der Speicher voll ist. Wenn der Speicher relativ großzügig gewählt wird, läuft aber das Programm meist besser, als wenn er kleiner dimensioniert wird. Das liegt daran, dass der GC dadurch nicht so oft laufen muss. Und das ist um einiges performanter. Wenn der GC größere Speicherbereiche säubern muss, ist das zwar auch nicht so der Renner, aber immer noch um einges schneller. Und gestanden ist - bei mir zumindest - die JVM deswegen noch nie. Das dürfte daran liegen, dass der GC - meines Wissens nach - parallel zum Programm läuft.