OutOfMemoryError

[_charly_]

habe folgendes Problem:

Exception occurred during event dispatching:
java.lang.OutOfMemoryError
	<<no stack trace available>>

ich verwende Eclipse 3.2 und java 1.3.1_16 (das programm soll auf dieser version laufen!)

mit den Befehlen Xmx und Xms komm ich irgenwie auch nicht weiter:

wenn ich in der Console folgendes Eingebe:

java -Xmx384m

dann kommt die übersicht über die möglichen funktionen.

wenn ich danach java -Xmx384m eingebe dann kommt folgender fehler:

Error occurred during initialization of VM
Incompatible initial and maximum heap sizes specified

dieser fehler kommt auch wenn ich Xms kleiner als Xmx wähle...

irgendwie hab ich das gefühl dass ich die Parameter nicht richtig setzte.

Bin für jeden konstruktiven Denkanstoß dankbar!

 

[foobar]

Warum willst du die Parameter überhaupt verändern, eigentlich braucht man das nicht. Wenn in deinem Code eine OutOfMemory kommt, haste ein Problem, da hilft dir auch Xmx nicht weiter.

 

[_charly_]

Warum willst du die Parameter überhaupt verändern, eigentlich braucht man das nicht. Wenn in deinem Code eine OutOfMemory kommt, haste ein Problem, da hilft dir auch Xmx nicht weiter.

kann ich nicht ganz nachvollziehen: laut http://java.sun.com/j2se/1.4.2/docs/api/java/lang/OutOfMemoryError.html


Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.

nun hab ich in meine Hauptschleife

System.gc();

eingebaut und im Taskmanager bleibt mein Programm ziemlich stabil was den Speicher betrifft (fängt bei 15MB an und nach ca. 2Mio. durchläufen ca. 20MB) - zuvor ist mein prog ziemlich schnell auf ca. 78 MB gekommen und dann mit besagter Fehlermeldung gescheitert.

trotzdem würd ich gern wissen wieso ich das mit Xmx bzw. Xms nicht hinbekomm bzw. was ich da andersmachen könnte.

Wenn ich in der eclipse.ini die parameter Xmx und Xms raufsetzte dann wird wohl der arbeitsspeicher reserviert, aber mein programm hört trotzdem bei ca. 78MB auf Speicher zu allocieren soweit ersichtlich...

jemand ne idee?

 

[byte]

Du kannst in Eclipse unter Run... gewisse VM Parameter mitgeben, da musst Du das reinschreiben.

 

[RaoulDuke]

Was tut das Programm denn Überhaupt? Hälst du wirklich so viele Daten im Speicher, dass du der VM mehr Speicher geben musst? Das das Programm erstmal bis zur Maximalgrösse anschwillt ist ganz normal, da der GC erst aktiv wird wenn die JVM 'voll' ist und kein Speicher mehr alloziiert werden kann, ohne vorher nichtreferenziertes zu entfernen. Trotzdem, wenn du eine Schleife hast die nach ein paar Millionen Durchläufen ein OutOfMemory erzeugt, dann legst du entweder absichtlich oder ausversehen mehr Daten im Speicher ab als in die VM passen. Und wenn es ausversehen passiert dann hilft dir ein Vergrössern des Speichers der JVM nur für die nächsten paar Millionen Durchläufe, danach hast du das gleiche Problem wieder.

Vielleicht postest du mal ein bischen von dem Code der das Problem produziert.

 

[_charly_]

Du kannst in Eclipse unter Run... gewisse VM Parameter mitgeben, da musst Du das reinschreiben.

habs gefunden - danke! funktioniert jetzt endlich

Lösung: Wie von byto geschrieben Run... - Java Application - und auf der rechten Seite dann Arguments auswählen: VM arguments und da hab ich folgendes eingegeben:
-Xmx384m, -Xms384m (384 klarer weise jeweils so wie mans braucht)

mfg charly

 

[_charly_]

Vielleicht postest du mal ein bischen von dem Code der das Problem produziert.

nicht mehr nötig - trotzdem danke! - habe sehr viele Daten - kein versehen - allerdings muss ich das ganze sowieso noch umbauen - ist im moment sehr ineffizient... aber das ist ein anderes Thema

 

[byte]

Hälst du wirklich so viele Daten im Speicher, dass du der VM mehr Speicher geben musst?

Normalerweise kommt man mit der Default Heapsize ziemlich weit, aber manchmal ist nicht viel nötig, um die 64 MB zu sprengen. Manchmal reicht ein Einzeiler aus:

int[] histogram = new int[256][256][256];

 

[RaoulDuke]

Das es geht ist nicht die Frage. Meine Frage war nur ob es wirklich beabsichtigt war so viele Daten zu speichern. Wenn er schon anfägt mit dem Garbage Collector rumzuspielen sieht es doch sehr so aus als wären die Daten in seinem Speicher keine die er noch behalten will.

 

[apparat]

zufälligerweise habe ich auch solch ein problem. ich hatte in einer session bean eine schleife welche einige millionen objekte erzeugt und bei jedem schleifendurchlauf in die datenbank einträgt. irgendwann kam dann OutOfMemory. Lasse ich System.gc() in der Schleife ausführen dann klappt es. Nun ist die Frage wie ich das ohne die GC aufzurufen hinkriege. Ich arbeite in der Schleife direkt mit persist(new Klasse(abc,xyz));

wäre es besser eine Variable außerhalb der Schleife anzulegen und der Variablen dann mit dem new Operator einen Wert zuzuweisen??

Eigentlich ja, hmm fällt mir grad so ein. Dürfte doch die Lösung sein...

 

[RaoulDuke]

wäre es besser eine Variable außerhalb der Schleife anzulegen und der Variablen dann mit dem new Operator einen Wert zuzuweisen??

Nein, nicht wirklich. Die Variable ist ja nur eine Referenz. Mit jedem new() überschreibst du die Referenz auf das alte Objekt mit einer Referenz auf ein neues Objekt. Das alte Objekt ist dann unreferenziert im Speicher und muss durch den GC abgeräumt werden. Es ändert also nichts am Problem ob du die Referenzvariable in der Schleife oder ausserhalb deklarierst.

Hast du vielleicht ein bischen Code als Beispiel?

Interessant wäre die Schleife sowie die persist() Methode mit der du den Wert in die Datenbank schreibst. Führst du selbst SQL Statements auf die Datenbank aus, oder benutzt du ein Framework wie Hibernate dazu?

 

[apparat]

ähm habe den code nicht hier auf arbeit. kann ihn aber nachschreiben. ist recht simpel.
ich benutze nur cmp entity beans für das speichern. als kein hibernate. nur das framework was bei JAVA EE mit drinn ist.

die schleife sieht in etwa so aus:

for(int i=0; i<5000000; i++) {
em.persist( new LAP(i,i,"Lager10"));
}

eiegntlich ganz banal

 

[RaoulDuke]

Der Code von persist() wäre halt noch wichtig, sonst kann man dazu ja nichts sagen. Ich könnte ja mal versuchen das Problem zu rekonstruieren. Mit einem Profiler sollte man evt. prüfen können ob und wo sich Datenmüll ansammelt. Hab ich auch noch nie gemacht, würd mich aber mal interessieren.

 

[apparat]

also em ist ja der EntityManager der bei dem JAVA EE Framwork steckt. Und dazu natürlich die Methode. Nun müsste man schauen ob man an die Sourcen kommt. Dann könnte man evtl. etwas dazu sagen.

An welchen Profiler hast du da gedacht?. Evtl. könnte man das per NetBeans lösen. Dort ist ja ein compiler dabei. Das könnte dann klappen. Oder gibt es andere Profiler die auch außerhalb einer IDE gut laufen und brauchbare ergebnisse liefern?

 

[apparat]

mir kam grad die idee woran das liegt. der EntityManager wird das alles in eine Transaktion packen. Evtl. könnte es daran liegen. Nun müsste man sich mit Transaktionen auskennen. Wird das von der Datenbank gestuert und bleiben die Daten so lange im Cache...

alles Dinge an denen es liegen könnte

 

[RaoulDuke]

Mit dem EntityManager habe ich mich leider noch nie beschäftigt. Kannst du ihn nicht dazu bringen nach jeden 1000 Datensätzen ein Commit durchzuführen? Ich halte es jedenfalls für eine gute Möglichkeit wo das Problem liegen könnte.

 

[apparat]

ich denke mal auch das es daran liegt. da kann man ja sehr einfach rauskriegen. jedoch würde ich erwarten das der container dann einige teile auf die festplatte auslagern würde. zumindest damit nicht gleich nen OutOfMemory Error kommt.