Message Boards Message Boards

1
|
14397 Views
|
11 Replies
|
3 Total Likes
View groups...
Share
Share this post:

What options does Mathematica have for memory management?

Posted 10 years ago

Hey there, community,

I am having some issues with Mathematica's kernel seemingly leaking memory over time.

What I have tried so far is to start my notebook with the following commands:

Remove["Global`*"];
ClearSystemCache[];
$HistoryLength = 0;
MemoryInUse[]

However, when I run my notebook several times, MemoryInUse reports an increase of ~12 MB in memory consumption each time.

So, is there some generic solution that I'm missing here? If not, then I'll have to look into creating an example notebook, but I'll start with asking for a general solution.

If it helps, I'm working with NDSolve using the new FEM toolbox, so it's of course possible (though hopefully unlikely) that there's some memory issue with the FEM implementation.

-Jonatan

EDIT: I forgot to mention this, but simply killing the kernel isn't an option. In fact, I'd like to avoid even having to call Remove["Global`*"], since in this case the memory consumed by those variables is negligible -- Mathematica is using memory somewhere else, I just can't figure out where.

POSTED BY: Jonatan Lehtonen
11 Replies

You might want to send an example to support@wolfram.com. The description you give is not inconsistent with an actual memory leak).(I use a double negative by intent; I do not want to give the impression that this is necessarily indicative of a bug, just that it is a possibility).

POSTED BY: Daniel Lichtblau

I finally had the time to do some additional checking, and found that even this seemingly harmless minimal example eats ~43 KB of memory every time you run it, with seemingly no way of clearing up that memory.

Remove["Global`*"];
ClearSystemCache[];
$HistoryLength = 0;
Share[];
MemoryInUse[]
Needs["NDSolve`FEM`"];
region = Rectangle[{0, 0}, {1, 1}];
op = Laplacian[u[x, y], {x, y}];
dirichlet = {DirichletCondition[u[x, y] == 0, x == 1], 
   DirichletCondition[u[x, y] == 1, x == 0]};
uif = NDSolveValue[{op == 0, dirichlet}, u, {x, y} \[Element] region];

Could someone with Mathematica 10 (required for NDSolve`FEM) try this out and see if the same happens for them? Just paste it into a notebook, run it a few times until the memory usage "stabilizes" (first three runs or so the memory usage is all over the place), and then see if the memory consumption consistently goes up.

In fact, just calling the first six lines (i.e. up to and including the Needs-statement) seems to suck up 1 KB of memory every time it's run.

P.S. Just to clarify, I know 43 KB seems like a small amount, but keep in mind that this is a minimal example. In my actual work, I'm seeing memory leakage of up to 2 GB in as little as an hour.

P.P.S. Before you ask: yes, I'll make a bug report about this soon unless someone finds a miracle cure for it. I just want to check if the issue is replicateable before I send the report.

POSTED BY: Jonatan Lehtonen

Thanks, that's probably my next step unless someone points out something I've missed.

POSTED BY: Jonatan Lehtonen

You can add Share[] to your list to see if it has any effect....

POSTED BY: David Reiss

I tried this, but the effect was very minor, a mere 2% decrease in memory usage.

POSTED BY: Jonatan Lehtonen

Reported/confirmed as a bug.

POSTED BY: Daniel Lichtblau

Thank you for confirming this, I've contacted support now.

POSTED BY: Jonatan Lehtonen

I am encountering similar problems. I am creating (reverse engineering) a "load matrix" that premultiplies a mesh function to get a load vector. I have attached a Notebook. Here I am not even calling NDSolve. I have attached some code I am submitting to Wolfram.

Attachments:
POSTED BY: Jeffrey Saltzman
Posted 10 years ago

Pardon me for interjecting this but isn't that how garbage collection is supposed to work? Memory will keep filling until the trigger point for garbage collection is reached and then the operating system will clear up memory and defragment memory. I am a little bit lazy here but I have a book on managed code I think that is the way it is designed. I think the GC has to step through memory and look for unreferenced memory locations before it can free up memory. The garbage collector does not continually remove items from memory because it is too cpu intensive. --- I could be wrong---

POSTED BY: RICHARD WEIMER

Mathematica uses reference counting rather than garbage collection in order to determine what memory can be recycled.

POSTED BY: Daniel Lichtblau

Reference counting, when the reference count goes to zero, returns the memory segment(s) to a heap. The heap, itself, does garbage collection much like one defragments a disk. Usually memory is pointed to by handles that point to another set of pointers into memory. When a handle is locked memory may be moved to defragment the heap. At any rate, garbage collection is probably not an issue. But if the programmers are not disciplined about having reference counts for every object and ensuring the lifecycle of the object is not open-ended this can cause the leaks to appear.

POSTED BY: Jeffrey Saltzman
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract