We recently ran into the odd issue with Natural programs on Windows.
It appears that when a dynamic object array is passed as a parameter, and then resized to zero to be re-used later, the memory is not properly released.
For example:
In Class ‘TEST-OBJ’ I have ‘TESTOBJ’ defined as
DEFINE DATA LOCAL
1 #TESTOBJ
2 STRING (A256)
2 DATE (N8)
END-DEFINEIf I create a dynamic array of this object
1 #OBJ-ARR (1:*) HANDLE OF OBJECTAnd call a series of objects from our db, adding them one at a time to the dynamic object array, I will expand the array by one each time prior to adding the object
#hi := *occ(#OBJ-ARR(*))
add 1 to #hi
expand array #OBJ-ARR to (1: #hi)
#OBJ-ARR(#hi) := #TEST-OBJWhen I have completed using this array completely, I reduce the array to zero before making new calls for new objects.
reduce array #OBJ-ARRAY to 0We recently upgraded from Natural 6.3 to 8.4, and found that this caused an unfortunate error in our programs (-1). The solution appears to be through setting each object index to null prior to collapsing the dynamic array, or by forcing the program to slow down through interjecting a wait period between the re-use of the dynamic array. This implies to me that there is a buffer release action which applies following ‘reduce array to 0’, however it may not be operating consistently if the object array is reduced and re-expanded very quickly.
Does Natural for Windows have any sort of implicit or explicit garbage collection, similar to Java? For example, if I took the above code and segregated it in a specific ‘call method’ execution but where it returns the object array, would setting ‘reduce array to 0’ implicitly free up the memory space when it is returned? Is there a specific explicit method I can call which simplifies the memory release of allocated (large) dynamic object arrays (rather than looping through the array to set each object to null - bleh)?