You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The main problem is related to deallocation of arrays and iVars. In early versions of the uplink implementation, the generated C code contained for loops with local array and iVar variables passed to a spawned task as argument. The internals of the iVar and the data buffer of the array are passed by reference in such a case, because you do not want to copy the mutex in the iVar and for copy elimination reasons in case of arrays. On the other hand, according to current memory deallocation rules, the local iVars and arrays are destroyed as soon as their scope ends, in this case at the end of each iteration of the loop. This is a problem, as the spawned task may use the objects after they are destroyed.
The temporal quick fixes (implying memory leaks) are the following:
Array and iVar deallocation is turned into empty functions in the supporting C libraries.
In addition to this, when passing an array to a spawned task, the struct array proxy object (stored on the stack) is reallocated on the heap as it will automatically go away from the stack as soon as the iteration of the loop ends. This is done in the spawn macros of the taskpool implementation.
A possible solution is the following:
Change the array library as it is in the compiler_refactoring_1 branch. This will allow to pass input arrays by value (just like in case of most data types including iVars). This way the quick fix 2. above is not needed any more.
Add a counter to the internals of arrays and iVars. The counter should be set to 1 at initialization, increased when passing the object to a different task and decreased by the destroy functions.
Destroy functions should only deallocate the object if the counter reached zero.
Make sure that task core functions call the destroy function not only on local objects, but also on iVars and arrays got as parameters.
Make sure that the destroy function is called on local arrays of for loops. This currently does not happen due to a bug.
The counter based solution might also help to put and get arrays to/from iVars without copying.
The text was updated successfully, but these errors were encountered:
Reported by Gergely Dévai:
The main problem is related to deallocation of arrays and iVars. In early versions of the uplink implementation, the generated C code contained for loops with local array and iVar variables passed to a spawned task as argument. The internals of the iVar and the data buffer of the array are passed by reference in such a case, because you do not want to copy the mutex in the iVar and for copy elimination reasons in case of arrays. On the other hand, according to current memory deallocation rules, the local iVars and arrays are destroyed as soon as their scope ends, in this case at the end of each iteration of the loop. This is a problem, as the spawned task may use the objects after they are destroyed.
The temporal quick fixes (implying memory leaks) are the following:
A possible solution is the following:
The counter based solution might also help to put and get arrays to/from iVars without copying.
The text was updated successfully, but these errors were encountered: