Problems with Matlab javabuilder and memory

Question

I'm experiencing some issues regarding my javabuilder-compiled matlab-code. My application is basically split up like this:

• GUI: Java
• Calculations: Matlab

The main problem is that when compiling my matlab-code with the javabuilder in Matlab (R17, 2007a), I have less memory available than I have when I compile the same code to an exe-file. I have confirmed this with the "feature('memstats')" function. My arrays are typically of size orders 1000000 x 25, and this is not initializable when run from java, as the largest contiguous memory space is too small (the biggest one is about 65MB, as opposed to about 1200MB when run as a ML exe-file). My rig is running Windows XP Professional x86 and has 4GB of memory.

I've tried these two matlab/c-compilators (set up with the "mbuild -setup" command in the matlab command line):

• Lcc-win32 C 2.4.1
• Microsoft Visual C++ 6.0 (also with the /LARGEADDRESSAWARE flag, which does not seem to help at all)

Any suggestions?

Answer 1

I think the solution to your problem is to increase the Java VM heap space as described here:

How do I increase the heap space for the Java VM in MATLAB 6.0 (R12) and later versions?

Answer 2

I'm sorry I can't post comments (need 50 reputation) (and this is too long for a comment anyways). I don't think that changed anything. What I did was create "java.opts" in %matlabroot%\bin\win32, and set the content to "-Xmx1024m". I then tried to recompile my application.

This is what feature('memstats') says at the start of my matlab-function:

Physical Memory (RAM):
    In Use:                             1568 MB (62059000)
    Free:                               2013 MB (7ddb2000)
    Total:                              3582 MB (dfe0b000)
Page File (Swap space):
    In Use:                             1608 MB (648ac000)
    Free:                               3872 MB (f20b1000)
    Total:                              5481 MB (15695d000)
Virtual Memory (Address Space):
    In Use:                             1611 MB (64b4c000)
    Free:                               1460 MB (5b494000)
    Total:                              3071 MB (bffe0000)
Largest Contiguous Free Blocks:
     1. [at 69b78000]                     53 MB ( 3538000)
     2. [at  ccbf000]                     51 MB ( 3341000)
     3. [at 6eee0000]                     40 MB ( 2820000)
     4. [at 5d36e000]                     28 MB ( 1cd2000)
     5. [at 67d15000]                     23 MB ( 17eb000)
     6. [at 5f211000]                     19 MB ( 13bf000)
     7. [at 6dac0000]                     19 MB ( 13a0000)
     8. [at 71ce7000]                     19 MB ( 1319000)
     9. [at 7a038000]                     18 MB ( 12f8000)
    10. [at 7d1d7000]                     18 MB ( 1239000)
                                        ======= ==========
                                         292 MB (124ff000)

Answer 3

Actually, you might want to decrease the Java heap space. The memory in your process, at least in regular Matlab, is split between Matlab and Java. If you increase the Java heap size, you will correspondingly decrease the memory available for Matlab arrays. Matlab arrays live in regular C-style memory, not Java's GCed memory.

I'm guessing what's happening is that your Java app, which is loading the javabuilder-built library in, is configured to have a larger Java heap than the Matlab IDE is. Matlab starts out with a smallish Java heap. Here's how to display it from within Matlab.

function show_javamemory()

rt = java.lang.Runtime.getRuntime();
M = 2^20;
disp(sprintf('Java heap: %d M total, %d M max, %d M free',...
    round(rt.totalMemory()/M), round(rt.maxMemory()/M), round(rt.freeMemory()/M)));

In my R2009a, I see this.

>> show_javamemory()
Java heap: 62 M total, 125 M max, 28 M free

That java.opts file in %matlabroot%/bin/win32 controls the JVM that's embedded in Matlab, when it's run as an IDE. I don't think it will affect applications that are loading in your javabuilder-built library. They will need to be adjusted by passing parameters to whatever java command line is invoking them.

Try running show_javamemory() from within your compiled app to see what its heap is configured as (and whether your java.opts change had an effect), and then adjusting its Java options to reduce the heap.