Um, what exactly is going on in Java image processing that takes
lots of
memory (I've got 8GB or so of RAM unused when this happens) but
doesn't
happen in the heap?
Direct buffers and memory-mapped files (i.e. java.nio.*). Libraries
that use direct buffers or memory-mapped files. Also, bugs that fail
to reclaim the space for such things.
I think the crucial clue is that mmap() is failing (read 'man mmap'),
and that it appears to be failing because it doesn't have adequate
address space. Its error message essentiallys says it needs a
contiguous 32 MB range of address-space in which to mmap something,
but it's not getting it because the address-space doesn't have an
empty slot that large. So if you make the -Xmx value smaller, it may
free up address-space for other uses. The GC messages seem to show
you're not approaching the 1500 MB level anyway, so it shouldn't hurt
anything.
Another option would probably be to just run under the 64-bit JVM,
assuming all your native libs have 64-bit code. 64-bit processes
have a 64-bit address space. Having 8 GB of free RAM means nothing
to a 32-bit process constrained by address-space limits.
These are not big images -- they're 8-bit grayscale 300DPI 8.5x11 page
images. Now if I was doing 8000x8000 24-bit color, I could see some
issues...
Well, something is asking for a 32 MB slot of address space. Maybe
it's some other file or an ARGB BufferedImage.
You might want to run your image-processing program with JMX enabled,
then connect to it with the 'jconsole' command and observe its memory
consumption.
At the command-line, run your app as:
java -Dcom.sun.management.jmxremote ...remaining args...
then in another Terminal window run:
jconsole
and choose your app from the presented chooser dialog.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
