incorrect memory copy when using property size validator

When using a size validator in a property block of a class an assigned variable's memory is copied instead of just pointing to it. This is 1) not expected due to standard matlab behavior, and 2) does not happen if using a manual set.prop(this, in) method to do the validation check.

There is then a secondary bug that when assigning a gpu variable and memory runs out (due to this memory bug) instead of giving an out of memory error, I instead get a size validation check did not pass error.

I see the same error on 2019b on a different computer. Example code below:

classdef TestClass < handle
    properties
        prop (1, :) % also happens with hard coded sizes and n-dimensional arrays
    end
end

g = gpuDevice; g.AvailableMemory
ans =
   5.2493e+09
>>  a = ones(1, 3e8, 'single', 'gpuArray');
g = gpuDevice; g.AvailableMemory
ans =
   4.0493e+09 % 1.2GB hit as expected
>> obj = TestClass;
>> obj.prop = a;
>> g = gpuDevice; g.AvailableMemory
ans =
   2.8493e+09 % another 1.2GB hit, not expected

Answer 1

[Joss Knight]

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.

Answer 2

[Kyle]

Sure, I never said the memory was lost. OK thank you. I repeated the test on 2019b and I get your same results. I believe the other computer must have been 2019a. Either way it's fixed in the newest version.

[Joss Knight]

I guess all I was trying to point out was that shared data copies are just an optimisation that shouldn't be 'expected behaviour' because MATLAB provides no documentation about when it will or won't happen. If anything it should be more of a surprise when copying a into obj.Prop doesn't use up memory than when it does. You certainly shouldn't come to rely on the behaviour.

It does not seem like designed behaviour if property validators return a failed validation if they OOM though ... I'll follow up on that one.