Where can we expect memory duplication with LVOOP?

[billings11]

I am implementing a fairly extensive LVOOP class in a large application I am working on now.  When I use the Show Buffer Allocations function, I am hardly seeing any dots for the labview classes.  Only one or two, and it seems like they are always only on terminals.  Also I don't see dots on inputs and outputs of method vi's.  I read the white paper about labview classes and it did go into memory management, but it did not give any specific details about when duplicate memory would be allocated for classes.  The only thing I remember reading is that it would need to allocate new memory when the default class value is changed.  So I am guessing they don't act completely like C++ pointers, but sort of.  It seems like it is almost never copying data to new memory locations.  For example there are no dots at wire splits or the inputs and outputs of method vi's..

1.  Does the show buffer allocations function work properly for LVOOP?

2.  Is there a resource somewhere that would give us a more practical understanding of where new memory would be allocated in a labview code context?  The labview classes seem to allocate memory very differently than all the other data types.

[billings11]

By the way, my vi's are compiled and I have everything selected in the show buffer allocations menu.

[Stephanie B]

Hi billings,

The Show Allocations Buffer tool should indeed work for OOP. I opened up some of the examples in 8.2.1 to play around with it and it was working. You won’t get the dots on methods because, since it is the same type of input as output, methods use the same memory. The memory is allocated for each data value – not by reference. I suggest reading the paragraph How does OO fit with dataflow? (The Great By-Value vs. By-Reference Debate) in this article: LabVIEW Object-Oriented Programming: The Decisions Behind the Design. That article links to OOP FAQ, which also links to some presentations on it for further information. Let me know if you need any more information (and if so, what version of LabVIEW are you using)!

Stephanie

[billings11]

Thanks for the response.  Yes that is the article I was talking about having read already in my first post.  But it doesn't make it clear exactly where in a labview context memory will be duplicated.  It only says memory is duplicated when the default value is changed.  It does not give practical examples or say at all if classes are in-place in methods.  And I get the concept that memory is allocated by value, but that article makes it seem like the only time new memory is allocated is the first time you give a class a non-default value.  But what if the class already has a non-default value?  Does it still duplicate memory or does it keep the same memory?  So I wanted to make sure the show buffer allocations was working properly.  I am using labview 8.2.

Here is what it looks like so far:

LV Classes duplicate memory when:

1.  The are passed in or out of a non-method vi.

2.  The first time (but only the first time) the default value is changed in a method vi.  This typically shows up at the output terminal of an "Initialize" type of method where data is first bundled into the class.

3.  If a class is put into another data type, like an array, memory is managed just like any other array.  It duplicates memory in all the normal places.

Other than that I don't see any duplication of memory with LVOOP.  So LV Classes do NOT duplicate memory when:

1. They are passed in or out of method vi's.

2.  Their value is operated upon within method vi's.  Bundling data into a class does not create a new instance of the class in memory, except for the first time you modify the default value.

Is all of this correct?  Because I can't figure out exactly what is happening.  And if you have inheriting classes you see dots from every override vi and not just the one you are looking at.  So its really hard to figure out what's going on with memory.  Does memory get allocated for all possible override vi's at any call to the root inherited method?

Message Edited by billings11 on 06-18-2007 11:45 AM

[Stephanie B]

Hi billings,

In short, memory is allocated when any value that could be referenced again is changed. So in order to not change a default value, whenever the default value is changed, new memory is allocated. If you change the number (method vi), because you won’t need that original number, then it uses the same memory. Default values though you will always want for whenever you start up the program, so those do not change, hence the new memory allocation. So your list looks correct. And yes, memory gets allocated for all possible override vi's at any call to the root inherited method. This is sort of a "just in case" it will need memory it goes ahead and sets some aside. I hope this helps.

Stephanie

[billings11]

I see.  Thanks very much!

[AristosQueue (NI)]

I just saw this thread and wanted to add a quick update.

The "Show Buffer Allocations" shows where the VI has had to make an allocation for a new instance of a piece of LV data. Think of every dot you see as a bucket that can contain a piece of data. For a "double", each of those buckets contains a floating point number. For a LVClass, each of those buckets contains a pointer to the class data.

When the value of the class is the default data, the pointer in the bucket points back to the single instance of the default data of the class. When you modify the value, we allocate space in memory for the non-default value of the class. This is not the same as creating a new bucket. This is just allocating space for the current bucket instead of sharing that space with the default value.

When you see a dot with the Show Buffer Allocation tool, that's a place where we actually had to create a new bucket. At run time, when we copy from one bucket if the value on the wire is the default value then we just duplicate the pointer value from bucket to bucket. If the value on the wire is non-default, then the destination bucket actually gets fully allocated and the data is deep copied to the new space. The destination bucket may already be allocated, in which case we just copy into the existing space.

Summary:
A copy dot for LVClasses really does indicate a place where we had to allocate a completely separate instance of the class.
When you assign a value to a class (through the Bundle node), LV may redirect the existing instance to no longer share with the default value and instead be an independent instance. But the number of instances in LV is unchanged.

Note for future readers: If ever a LV version exists that supports real-time platforms, you should know that the information above applies only to desktop LabVIEW.  Obviously the memory allocation at runtime would not be acceptable for realtime performance, so it will be something different. You should check documentation for that future version of LV rather than citing this post.