MATLAB Answers

incorrect memory copy when using property size validator

4 views (last 30 days)
Kyle
Kyle on 9 Jan 2020
Edited: Joss Knight on 18 Jan 2020
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

  0 Comments

Sign in to comment.

Accepted Answer

Joss Knight
Joss Knight on 16 Jan 2020
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.

  0 Comments

Sign in to comment.

More Answers (1)

Kyle
Kyle on 17 Jan 2020
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.

  1 Comment

Joss Knight
Joss Knight on 18 Jan 2020
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.

Sign in to comment.

Sign in to answer this question.

Products


Release

R2018b