Speicher frei machen (List)

[eliot]

Hallo,

zum Lösen eines recht komplexen Problems muss ich einen
Tree aufbauen, der alle mögliche Lösungswege enthält.
Danach kann ich den optimalen Weg erfragen.
Nachdem ich das Ergebnis habe, würde ich gerne Speicher frei machen
und alle anderen Lösungswege löschen.
Jeder Knoten im Baum enthält dabei x weitere Folgeknoten in einer Liste.

Reicht ein simples list=null; aus, oder sollte man list.clear() aufrufen?
Nach meinem Verständnis sollte es keinen Unterschiede geben
(ok, beim zweiten würde das list Object ebenfalls verworfen).

Eine eventueller kurzer sleep mit Aufruf des Garbage Collectors am Ende
ist eine weitere Option.

 

[HoaX]

Eine eventueller kurzer sleep mit Aufruf des Garbage Collectors am Ende
ist eine weitere Option.

Die nicht zwangsläufig etwas ändern muss.

 

[Marco13]

Bei list=null wird die komplette Liste (irgendwann) gelöscht. Bei list.clear() wird sie zwar leer, aber die Liste existiert weiterhin. Eigentlich klingt das eher, als sollten die Elemente der Lösung dann in einer seperaten Liste gespeichert, und der komplette Baum dann vergessen werden, aber das musst du wissen.

Nur eineinhalb sachen: System.gc() und/oder ein sleep() um dem GC Zeit zu geben sollte eigentlich NIE notwendig sein.

 

[musiKk]

Sind sie auch nicht. Es wird nie einen Speicherfehler aufgrund zu wenig Speicher geben, wenn der GC noch etwas aufräumen könnte.

 

[FArt]

Die Lösung ist: gar nichts machen! Die VM und der GC wissen, wann sie was zu tun haben.

 

[Marco13]

Sind sie auch nicht. Es wird nie einen Speicherfehler aufgrund zu wenig Speicher geben, wenn der GC noch etwas aufräumen könnte.

Naja, von Grenzfällen mal abgesehen [JavaSpecialists 173] - Java Memory Puzzle

 

[musiKk]

Naja, von Grenzfällen mal abgesehen [JavaSpecialists 173] - Java Memory Puzzle

Nicht schlecht. Müsste man mal mit mehreren Compilern probieren. Vielleicht trifft die JVMS ja auch eine Aussage. Da ich dort aber weder in TOC noch Index etwas zu blocks oder scope gefunden habe, lass ichs erstmal... ist schließlich Freitag.
Vielleicht komm ich nochmal dran, ich beschäftige mich grad etwas mit der JVMS.

 

[Marco13]

Die Frage wurde in der nächsten Folge beantwortet ... so richtig... "handfest (für mich) nachvollziehbar" war die Antwort zwar nicht aber... vielleicht für andere....

 

[musiKk]

Jo, habs schon gesehn.

Es wird halt ein Array angelegt und eine Referenz liegt auf dem Stack. Die wird mit der zweiten Anweisung überschrieben, aber so weit kommt es gar nicht, weil die erste Referenz noch da ist und das entsprechende Array nicht GCd werden kann. Deswegen meinte ich auch, dass andere Compiler vielleicht anderen Code erzeugen. Vielleicht ist das Verhalten auch irgendwie auf eine Spezifikation zurückzuführen.

 

[musiKk]

Noch eine Ergänzung: Sun beschreibt das auch selbst.