Disco rigido Heap Java

Question

Ho lavorato a un programma Java che genera orbite frattali da parecchio tempo. Proprio come le fotografie, maggiore è l'immagine, migliore sarà quando ridimensionato. Il programma utilizza una matrice di oggetti 2D (Point), che viene scritta quando viene calcolato il valore di un punto. Vale a dire che il Punto è memorizzato nel suo valore corrispondente, I.e .:

Point p = new Point(25,30); 
histogram[25][30] = p; 

Naturalmente, questo è modificato per semplicità. Potrei semplicemente scrivere i valori dei punti in un CSV e applicarli successivamente al raster, ma l'uso di metodi simili ha prodotto risultati indesiderati. Ho provato per un po 'di tempo perché mi è piaciuto essere in grado di realizzare immagini più grandi con lo spazio liberato dal non avere questo array. Semplicemente non funzionerà. Per chiarezza vorrei aggiungere che l'oggetto Punto memorizza anche i dati dei colori.

Il prossimo problema è WriteableRaster, che avrà le stesse dimensioni dell'array. Combinati i due occupano una grande quantità di memoria. Sono arrivato ad accettarlo, dopo aver provato a cambiare il modo in cui è stato eseguito più volte, ciascuno con risultati di qualità inferiore.

Dopo aver tentato di ottimizzare per memoria e tempo, sono giunto alla conclusione che sono davvero limitato dalla RAM. Questo è quello che vorrei cambiare. Sono a conoscenza dello switch -Xmx (impostato su 10 GB). C'è un modo per utilizzare la memoria virtuale di Windows per archiviare il raster e/o l'array? Sono ben consapevole del significativo impatto delle prestazioni che questo provocherà, ma al posto di abbassare la qualità, non sembra esserci molta scelta.

Answer 1

Il sistema operativo sta già facendo spazio sul disco rigido nella RAM per voi e per ogni processo, naturalmente - nessuna magia necessario. Questo sarà più un disastro di prestazioni di quanto pensi; sarà così lento da non funzionare efficacemente.

Stai cercando file mappati in memoria? http://docs.oracle.com/javase/6/docs/api/java/nio/MappedByteBuffer.html

Se questo è davvero da fare in memoria, scommetterei che si potrebbe ridurre drasticamente l'utilizzo della memoria con un po 'di ottimizzazione. Ad esempio, l'oggetto Point è principalmente overhead e non dati. Contare i byte necessari per il riferimento, quindi per l'overhead Object, rispetto a due ints.

È possibile ridurre a zero il sovraccarico con due grandi parallelepipedi paralleli int per le coordinate xey. Ovviamente dovresti incapsulare questo per l'accesso nel tuo codice. Ma potrebbe dimezzare l'utilizzo della memoria per questa struttura dati. Milioni di oggetti in meno accelera anche le esecuzioni di GC.

Invece di mettere un WritableRaster in memoria, prendere in considerazione la possibilità di scrivere direttamente il file immagine in un semplice formato di immagine. BMP può essere molto semplice. Quindi forse usando uno strumento esterno per convertirlo in modo efficiente.

Provare a -XX:+UseCompressedOops per ridurre anche l'overhead degli oggetti. Prova anche a -XX:NewRatio=20 o superiore per fare in modo che JVM riservi quasi tutto il suo heap per oggetti longevi. Questo può effettivamente farti usare più heap.

Answer 2

Non è consigliabile configurare i parametri di memoria JVM (Xmx) per rendere il sistema operativo in grado di allocare dalla memoria di scambio. apparentemente il meccanismo di garbage collection deve avere accesso casuale alla memoria heap e, in caso contrario, il programma si bloccherà per un lungo periodo e probabilmente si bloccherà. si prega di consultare la risposta data già alla mia domanda (ultimo paragrafo):

does large value for -Xmx postpone Garbage Collection