MATLAB: Out of memory when assigning values to existing arrays

out of memory

Hi,

while dealing with several large arrays I'm facing some strange out of memory problems, which I don't understand. The problems occurred when I was trying to find a workaround for operations on large arrays…

1) It makes a difference if you create a new array (say by zeros(1e10,1), OOM Error) or if you copy an existing array of the same size to a new variable (new = old, no OOM Error). I thought this shouldn't make any difference in terms of memory usage?

2) Changing values in arrays causes an OOM Error, e.g. replace the first value in the array x = zeros(1e10,1) by x(1) = 1;. I would have expected that this operation does not influence the memory?

Any comments appreciated

Thanks, Christian

Best Answer

This is the expected behavior. Matlab uses a copy-on-write strategy:

a = rand(1e9, 1);
b = a;     % Shared data

Now the data pointer of b points to the same memory as a. But when any element of b is modified, the data are duplicated:

b(1) = 1;  % Data duplication

This strategy is useful when data are provided to functions. Then a shared data copy saves time and memory as long as no values are modified.

Related Solutions

MATLAB: Why Matlab don’t use Swap but error “Out of memory”

Swapping increases the available contiguos memory, but only until a certain limit. If this limit is exhausted you get the "Out of memory" error.

Even for a giantic virtual memory, a 32-bit Matlab version can access 4GB of RAM only. So please mention the version of Matlab and the OS.

MATLAB: Incorrect memory copy when using property size validator

I was able to reproduce this in R2018b but not in R2019a or R2019b. It looks like property validators used to trigger a deep copy but that has been fixed. My guess is this is because of the introduction of a gpuArray overload for validateattributes.

Even in R2018b the memory is not lost, it is just not shared. A shared copy is a fragile optimisation that is broken as soon as you edit one of the copies. So in R2019b:

>> clear all
>> gpu = gpuDevice;
>> gpu.AvailableMemory
ans =
   1.5565e+09
>> a = ones(1,1e8,'single','gpuArray');
>> gpu.AvailableMemory
ans =
   1.1572e+09
>> obj = TestClass;
>> obj.Prop = a;
>> gpu.AvailableMemory
ans =
   1.1580e+09
>> a(1) = 0; % Editing one of the variables breaks the shared copy
>> gpu.AvailableMemory
ans =
   756809728

Similarly, if you clear a in R2018b you'll gain back the memory you thought you lost:

>> gpu.AvailableMemory                 
ans =
   1.0536e+10
>> a = ones(1,1e8,'single','gpuArray');
>> gpu.AvailableMemory                 
ans =
   1.0135e+10
>> obj = TestClass;           
>> obj.Prop = a;                       
>> gpu.AvailableMemory                 
ans =
   9.7346e+09
>> clear a; % Clearing the original variable gives you back the memory
>> gpu.AvailableMemory                 
ans =
   1.0135e+10

You may have thought that by creating a handle class you were opting into some other kind of sharing behaviour, but that is only about sharing the properties within instances of TestClass.

Best Answer

Related Solutions

MATLAB: Why Matlab don’t use Swap but error “Out of memory”

MATLAB: Incorrect memory copy when using property size validator

Related Question