not able to use 64bit memory allocated

[chroma]

I’m getting an 'Out of memory,Jaikoz must be restated, to increase memory allocated to jaikoz modify its memory settings in the start up file and then restart". Kind of sucks after letting this thing churn for days.

I’ve executed with -d64 -Xms1250m -Xmx7900m -XX:MaxPermSize=1300m.

System profiler shows exactly 4.00 GB real allocated. (2560 threads active)

$ ps -auwwwjlvx 16570
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND PPID PGID SESS JOBC UID CPU PRI NI WCHAN SL RE PAGEIN LIM TSIZ
dan 16570 0.0 15.4 15479400 4188660 s002 S+ 8:10PM 305:04.30 /usr/bin/java -X 16569 16569 23fd1000 1 501 0 62 0 - 0 0 0 - 0

Can we please get a version with real 64 bit support? I can’t even load 5% of my collection at this point. I have a desktop here with 32GB of RAM, seems like i should be able to load and process 21,000 tracks.

Incidentally, we didnt run out of memory until the last (discogs) step. I wasn’t watching to see how close we were before that, but you might look at how you are using memory for that step. I’ll watch next time before starting the last step.

thanks.

[paultaylor]

You are only isng 4GB of 8GB allocated , so seems there is an issue with OSX. However 4GB should be more than enough for 21,000 so looks like a memory leak somewhere. Logs may be useful because the most likely cause of a memory leak in this case would look to be a screwed up image, images don’t really use the Java Heap memory but the system memory and I have put fixes in the past to protect against dodgy images that eat up the whole memory when rendered, perhaps Im missing one.

[chroma]

ok. cant find any references on the 'net to inability to allocate above 32bit space when running in a 64bit jvm on snow leopard. are you sure you aren’t making a 32bit assumption somewhere?

i’ve sent along a tgz of my log directory. this last run spanned many files. perhaps you’ll find something interesting there. it certainly was a very chatty run with lots of apparent unhappiness.

thanks

[paultaylor]

yes, there was an issue with running out of threads which is highlighted here because you are updating alot of files, and possibly creating alot of threads in a short space of time, you are using 3.3.3 and issue like this was fixed in 3.3.4, but I wil delve into it further

[paultaylor]

Hi, problem fixed in dev. When you run autocorrect Jaikoz should not attempt to update the TagBrowser until the autocorrect has finished, but because of a bug it is trying to do this for the Local Correct (Artist Correct, Album Correct …) and Cluster Albums tasks.

The consequence of this is aiutocorrect is taking longer than it should when you have these tasks configured, and if you are doing a very large autocorrect you might get an OutOfMemory error because thread allocation is used up.

So the short term workaround is to remove the above tasks from autocorrecter and run them seperately,