CyFlex Pre/Post 6.1 Memory Reuse

In versions of ASSET and CyFlex prior 6.1.x, when variables were deleted, they were actually completely removed from memory.

BEFORE 6.1.x

As a simple example, if you had a gen_labels file that contained only 3 variables and they were in this order (A, B, C), they would be allocated in memory is this order:

• A
• B
• C

If you then modified the file to remove B, then ran gen_labels again, the new memory arrangement would be:

• A
• C
• “empty”

The empty memory becomes available for some other application, and might then contain.

• A
• C
• This_label (belonging to a different application, or different gen_labels owner)

Obviously, if some other application, say X, was using variable ‘C’, it is now in a different place. The “reconfiguration” of X would cause it to be suspended as soon as the gen_labels application started processing and when gen_labels completes (now A, C, empty), X would reconfigure, and find the new address of ‘C’. Everything is OK as long as application X gets “suspended,” and doesn’t try to access the memory where ‘C’ used to be.

AFTER 6.1.x

A similar situation as above:

• A
• B
• C

Modified gen_labels with ‘B’ removed. Instead of clearing out the memory used by B, we simply make it “inactive.” The location of ‘C’ doesn’t change.

• A
• (inactive copy of B)
• C

So, now application X that is using variable C can continue to use that address for C, since it doesn’t get relocated in memory. If application X also was using B, it can continue using the stagnant contents until gen_labels sends the “GO” (reconfig complete). Application X will then reconfigure and report an error, that it can’t find variable ‘B”, since it no longer is a valid variable.

Let’s say that the gen_labels file is then modified again by re-inserting the ‘B’ variable, but in a different sequence (A, C, B). Now, the gen_labels app will find the ‘inactive copy of B”, recognize that the owner name is a match and will make it active again.

• A
• B
• C

None of the addresses have changed, even though the sequence in the gen_labels file has changed.

A potential disadvantage of this new approach is that you could end up with a lot of dead ‘inactive’ variables. The ability to re-use the memory when variables were deleted was the objective of the original design back in the “goodle” days when memory was more precious. (If you think that is a typo, google “goodle days”.) The “show_mem” utility will tell you how many variables are “reserved” (the ‘resvrd’ column). The reserved REAL and INTEGER variables will be displayed if you use the +v option. (show_mem +v)