[Java] System.gc() dwingen

[Verwijderd]

Mogu.....

Stel:

ik heb een table met 2000 rows en 1500 columns

ik representeer de rows met vectoren

Dit resulteert in:

te weinig geheugen

Als ik nou in mijn lus de garbage collector aanroep (dit gebeurt dan 2000 keer) dan blijft mijn geheugengebruik keurig....alleen word mijn programma baggertraag....niet zo heel erg verwonderlijk

Dus ik wil op bepaalde momenten de garbage collector laten runnen, stel bij row: 250,500,750,1000 enz enz

Maar als ik dit doe krijgt gc geen of niet genoeg tijd en mijn programma loopt doodleuk weer uit geheugen

gc in een aparte thread laten lopen heeft ook niet veel zin, dan krijgt tie nog steeds geen tijd lijkt het wel

Iemand suggesties om de garbage collector uit te laten voeren, voordat het programma weer verder gaat?

code:

while(l<numberofelements){
   temp = new Vector();   // <= De boosdoener
                        
   for(int h = 0;h<columns;h++,l++){
     //Add element to a row
     temp.addElement(Array.get(Data,l));
   }
   //Add Row with data to Table
   VariablesTableModel.addRow(temp);
}

[wasigh]

Je kunt de GC niet dwingen te runnen, alleen vragen.
Meer geheugen bijprikken is waarschijnlijk het beste

Je kunt ook handmatig objecten op null zetten, wat ook geheugen vrijgeeft en het de GC makkelijk maakt.

[Verwijderd]

Meer geheugen bijprikken is waarschijnlijk het beste

Je code optimaliseren is waarschijnlijk het beste!

[Verwijderd]

Geheugen bijprikken is geen optie....maar als ik mijn objecten op null zet maakt dit helemaal niet uit....er komt geen geheugen vrij.....

...misschien pas aan het einde van de 2000 rows???? Als tie al zonder geheugen zit?

Als ik mijn programma laat slapen, gaat de garbage collector dan wel door?

[mbravenboer]

Je moet de oplossing niet zoeken richting garbage collection. Je moet beginnen met het implementeren van een eigen table-model die efficient met deze smak gegevens om kan gaan.

Een eigen implementatie kan daarbij al een hoop schelen, wellicht moet je zelfs gaan voor een oplossing waarbij niet alle data altijd in het model aanwezig is.

Daarnaast moet je altijd je verzamelingen instellen op het te verwachten aantal elementen. Als je dat niet doet, moet de interne array steeds worden uitgebreid, wat dramatische gevolgen heeft voor de performance en de hoeveelheid garbage die je oplevert.

Vergeet die gc, en ga zuinig doen met objecten en bekijk waardoor de problemen worden veroorzaakt .

Als laatste redmiddel kan je de heap vergroten bij een out-of-memory error door dit mee te geven als parameter aan de JVM, maar dat is een redmiddel als je weet dat je niet efficienter met objecten kunt omspringen...

[Verwijderd]

Garbage Collection is inderdaad niet de oplossing. Trouwens, gc maakt alleen maar geheugen beschikbaar dat niet meer in gebruik is. Jouw programma maakt gewoon heel veel objecten aan en gebruikt dus ook veel geheugen. Het "handmatig" aanroepen van gc zal daar geen verandering in aanbrengen.

Misschien heb je aan dit artikel nog wat: The Truth About Garbage Collection

[ACM]

Kan je niet, ipv steeds een nieuwe vector maken, beter je vector steeds hergebruiken?

Of zelfs, ipv een vector een array (data[] zoeen dus ) maken en die steeds hergebruiken (dus niet leeggooien zolang ie niet van grootte veranderd, maar gewoon weer opnieuw vullen/overschrijven)

[Alarmnummer]

De nieuwe vm die hergebruikt toch vrij efficient objecten?

[Verwijderd]

Op dinsdag 05 maart 2002 11:01 schreef mbravenboer het volgende:
Vergeet die gc, en ga zuinig doen met objecten en bekijk waardoor de problemen worden veroorzaakt .

Dat ben ik inderdaad met je eens. daar was ik enigzins al mee bezig....alleen gaat er even iets meer tijd in zitten dan ik dacht....maar we zullen eens kijken naar een eigen implementatie

Als laatste redmiddel kan je de heap vergroten bij een out-of-memory error door dit mee te geven als parameter aan de JVM, maar dat is een redmiddel als je weet dat je niet efficienter met objecten kunt omspringen...

Lijkt me niet echt de oplossing...meer een work arround.......dus dan maar de eigen implementatie

Om niet alles in te laden vind ik zelf niet de beste methode....daar zou de grafische interface niet vlotter van worden...

[Verwijderd]

Op dinsdag 05 maart 2002 11:49 schreef ACM het volgende:
Kan je niet, ipv steeds een nieuwe vector maken, beter je vector steeds hergebruiken?

Dat heb ik dus geprobeerd...maar dat wil niet, volgens mij refereert de tablemodel nog steeds naar de vector...dus moet ik iedere keer een nieuwe vector aanmaken....

ik neem aan dat dat bij een array hetzelfde geval zal zijn

[ACM]

Op dinsdag 05 maart 2002 11:56 schreef mr.beidehand het volgende:
ik neem aan dat dat bij een array hetzelfde geval zal zijn

Wat ik bedoel is dat je dus steeds hetzelfde array meegeeft, maar dan met andere waarden.

Aangezien je met objecten werkt werk je met "call by reference" dus daar zal verder weinig geheugenverspilling ontstaan.

Maak dus 1x buiten de whileloop een array van de goede grootte aan en overschrijf alle waarden dmv je forloop elke while iteratie.

[wasigh]

Op dinsdag 05 maart 2002 11:59 schreef ACM het volgende:

[..]

Wat ik bedoel is dat je dus steeds hetzelfde array meegeeft, maar dan met andere waarden.

Aangezien je met objecten werkt werk je met "call by reference" dus daar zal verder weinig geheugenverspilling ontstaan.

Maak dus 1x buiten de whileloop een array van de goede grootte aan en overschrijf alle waarden dmv je forloop elke while iteratie.

[mierenneukermode]
java kent geen call by reference
het simuleert het alleen maar
[/mierenneukermode]

[ACM]

Op dinsdag 05 maart 2002 12:03 schreef wasigh het volgende:
java kent geen call by reference
het simuleert het alleen maar

Is het call by value dan?

Ik mag hopen dat er niet een compleet Object gekopieerd wordt voor een bepaalde functie...

[mbravenboer]

ACM: Wat ik bedoel is dat je dus steeds hetzelfde array meegeeft, maar dan met andere waarden.

Dat gaat helaas niet werken als je een Vector gebruikt: bij het DefaultTableModel wordt de Vector die je meegeeft intern bewaard. Als je die dus aanpast, werken de aanpassingen ook door in het DefaultTableModel. Recyclen van de Vector is dus niet mogelijk. Als je een Array meegeeft wordt hiervan alsnog een Vector gemaakt. Die kan je dus wel hergebruiken, maar omdat er alsnog een Vector wordt opgebouwd is dat ook absoluut niet efficient.

De kern van het verhaal is simpelweg dat je echt een eigen TableModel moet implementeren. Die hele smakken Vectoren werkt gewoon veel te traag voor dit probleem. Je moet een TableModel implementeren (kan extenden van een AbstractTableModel) met een eigen opslag structuur (vaste array oid) zodat je heel efficient je model kunt vullen . Een eigen TableModel implementeren is overigens vrij eenvoudig als je van AbstractTableModel extend .

[mbravenboer]

ACM: Ik mag hopen dat er niet een compleet Object gekopieerd wordt voor een bepaalde functie...

Wasigh zeurt (hij heeft zo'n Sun certificatie gedaan ). De pointer naar een object wordt by-value meegegeven en dat noemen ze dan by-value ipv by-reference... tja... kan .

[ACM]

Op dinsdag 05 maart 2002 12:07 schreef mbravenboer het volgende:
Wasigh zeurt (hij heeft zo'n Sun certificatie gedaan ). De pointer naar een object wordt by-value meegegeven en dat noemen ze dan by-value ipv by-reference... tja... kan .

Ach, ze hebben de bytes ook verkeerd om in gebruik... Dus sja Gekke Sunners

[wasigh]

Op dinsdag 05 maart 2002 12:12 schreef ACM het volgende:

[..]

Ach, ze hebben de bytes ook verkeerd om in gebruik... Dus sja Gekke Sunners

Kwamen die Sunners niet vanuit die universiteit waar ze unix ontwikkeld hadden

[roelio]

Op dinsdag 05 maart 2002 12:07 schreef mbravenboer het volgende:
...
en dat noemen ze dan by-value ipv by-reference... tja... kan .

kan mag niet