Was java heap memory limited in MATLAB 2025b?

Has anyone else noticed that the java heap memory has been severely limited in MATLAB 2025b? In 2024b it was ~32000MB, now it is ~8000MB. Why the change? This is detrimental for my code and not worth working around. Hopefully this changes back or this is the last straw and I may finally move to Python...

[Walter Roberson]

On my system (MacOS Intel) the breakpoint is R2023b which had a Java Heap preference (under General) that supported ~32000MB, but R2024a instead has a "Java Runtime Environment" preference that is limited to 8192.

[Nick]

Interesting. I'm on Windows 11. On both 2024b and 2025b, I have the pictured menu, with the more limited option in 2025b.

[John D'Errico]

On my Mac OS M4 series, it also shows a limit at 8192, with for me, a default at 1728. So I looked up the JVM ergonomics rules for the heap size.

Default heap sizing on bare-metal systems (pre-Java 10)

• Initial heap size (-Xms): Defaults to 1/64 of the physical memory, with a reasonable minimum of at least 8 MB.
• Maximum heap size (-Xmx): Defaults to 1/4 of the physical memory. For example, on a 4 GB machine, the maximum heap would be 1 GB.

In my case, with 48 GB of physical RAM, 1/4 of that would be 12 GB, but they may also have some other rules that reduced it to 8GB max.

So, when you saw 32000MB as a max, was that on a different machine with more RAM?

[Walter Roberson]

R2023b, MacOS Intel 15.6.1

R2025b, MacOS Intel 15.6.1

Exact same machine, just different versions of MATLAB.

[Benjamin Kraus]

What are you doing in MATLAB that requires such a large Java heap size?

It is worth noting that in MATLAB R2025a, neither the MATLAB Desktop, MATLAB Editor, nor MATLAB Graphics use Java anymore, so the Java heap size is no longer relevant for the performance in those areas. In the past, a frequent reason to increase Java heap size was if you were rendering large amounts of data in a figure, but that no longer uses Java. Java has been removed as a dependency for most of MATLAB, so unless you are explicitly calling into Java from MATLAB, the heap size should be much less relevant than it used to be.

[Nick]

@John D'Errico I have installed both 2024b and 2025b on the same machine (128GB memory), which is why I was confused about the change.

However I got a response from Mathworks...they did for some reason limit the java heap memory in 2025b, but my contact doesn't know why and is currently looking into it.

@Benjamin Kraus Yup, I'm explicitly calling into Java from MATLAB. It's a critical step in my data analysis pipeline.

[dpb]

@Benjamin Kraus ", so unless you are explicitly calling into Java from MATLAB, the heap size should be much less relevant than it used to be."

There is no indication at <Java with MATLAB> that calling Java from MATLAB is deprecated by Mathworks and so there is no justification for limiting the user from setting the Java heap as desired/needed to support their use.

MATLAB is a general programming language/development environment; it isn't Mathworks' position to try to control a user's use as they see fit for their needs/purposes. The seemingly increasing penchant for the "big brother" approach is totally missing the point of having the tool; it's up to the user to decide what best suits their situation rather than Mathworks.

I'm sure the thought internally is trying to improve base MATLAB performance by keeping as much memory as possible for MATLAB itself and to make simpler ease of use, and that's an honorable objective, but when it comes at the expense of limiting the ability of advanced users to stretch capabilities, then it goes too far.

If the user makes poor choices, it's on them, not Mathworks (albeit another probable reason for deciding to limit is probably to try to reduce support requests for out of memory errors, granted).

$0.02, im(nsh)o, ymmv, etc., etc., etc., ...

[Benjamin Kraus]

@dpb: Calling into Java from MATLAB is definitely not deprecated. It is still fully support and I am not aware of any plans to change that. That wasn't what I was trying to suggest by my question. I don't know the rational behind changing the upper limit for Java heap size (that is not my team at MathWorks), but it sounds like @Nick is already talking to the right people to answer that question, so I'll let them provide the answer to @Nick.

[dpb]

@Benjamin Kraus - I grok, I just wanted to express my very strong opinion that introducing barriers to the user in how they choose to use MATLAB is misguided direction on Mathworks' part. The external languages interface link was only to emphasize that it doesn't make a lot of sense to continue to support Java and then purposefully try to hamstring it unless there were any such intentions. I did go look at the current documentation just to confirm for myself that no such implications had been introduced.

Hopefully we'll get a report back on the reasoning behind introducing the limitation when @Nick gets an official response.

Answer 1

[Nick]

After contacting MathWorks it seems that the maximum Java Heap Memory was in fact reduced in MATLAB 2025b. However, they said this was a 'bug', and that their 'development team will consider fixing this in one of the future releases'.

We'll await the fix!

[dpb]

+1

Answer 2

[Benjamin Kraus]

@Nick: Now that you've got an answer from technical support that it was a bug, let's talk potential solutions/workarounds.

Have you tried using a java.opts file to change the maximum memory allocated to the Java heap?

I just did a quick experiment, and from what I can tell it seems to have worked.

I created a new java.opts file in my MATLAB startup directory (following these instructions: "Specifying Java Startup Options", but ignoring the part that says "To adjust the Java heap size on desktop versions of MATLAB, use Java Heap Memory Settings.").

Contents of java.opts:

-Xmx32689m

I then ran this command in MATLAB:

java.lang.management.ManagementFactory.getRuntimeMXBean.getInputArguments

It showed two copies of "-Xmx", the one from MATLAB's preferences, and the one from java.opts. But the one from java.opts was second, and seems to take precidence over the earlier setting.

I then used the jstat command to verify that the new settings took effect, and they seem to have worked.