incorrect memory copy when using property size validator

1 次查看(过去 30 天)
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

采纳的回答

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

更多回答(1 个)

Kyle
Kyle 2020-1-17
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 个评论
Joss Knight
Joss Knight 2020-1-18
编辑:Joss Knight 2020-1-18
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.

请先登录,再进行评论。

类别

Help CenterFile Exchange 中查找有关 Loops and Conditional Statements 的更多信息

产品


版本

R2018b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by