Couple points and then a solution. First, there are approximiately zero reasons to run gc() manually. Second, there are few reasons to read 600 megabytes in to memory in one fell swoop. Use a memory mapped file.
P.S. Make sure you set your memory switches and usually it's a good idea to clamp both ends so that re-sizing at runtime is not required: -Xms256m -Xmx256m. A quarter gig of RAM should be enough to run the Goggle mainframe at peak hours. Well, maybe exaggerating but it's a heckuvalotta memory.
Sorry to hijack, but the impression I get from the posts here is that this code will try to read all 600MB of data into memory at once.
My understanding was that it would read the buffer size (1K) of data at once, write it out, and then read another 1K, and so on. Have I misunderstood something?
Joined: Jan 07, 2005
Ernest to answer your question, its a simplification. Don't mind if i ask you but what makes you say it would not run out of memory?
Anderson this what you mean
Unfortunately i can't use the above code because the thing is the application is in a jar file on windows platform and users that use this application to run it usually double click on the jar file to run it. Is there a way to do what you suggested programatically maybe by the use of properties?
Stuart, you have understood the question correctly
Originally posted by West Richard: Ernest to answer your question, its a simplification. Don't mind if i ask you but what makes you say it would not run out of memory?
Because the code you showed us uses a small, fixed amount of memory. There is nothing here with memory usage that will grow over time. This loop could copy the biggest file your OS could support, and it could do it with -Xmx8m -Xms8m on the command line, because it hardly uses any memory at all.
As a result, the only suggestions you're getting are to up your VM image size, and that's not helping you, right? If you showed us more code, maybe we'd spot where the memory was going, and we could help you fix the real problem.
Joined: Jan 07, 2005
I tried searching somewhere else in the program and you were right Ernest the leak was not coming from the loop but it seemed to come from this part
I know for a fact that the document in the JTextPane spans couple of of thousand pages but it seems that the exception is coming from that area.
Could it be that because the stream is writing the document at one go. If it is then is there a better way to do it?