Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scope of IVars #10

Open
emilaxelsson opened this issue Oct 30, 2012 · 0 comments
Open

Scope of IVars #10

emilaxelsson opened this issue Oct 30, 2012 · 0 comments
Labels

Comments

@emilaxelsson
Copy link
Member

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:

  1. Array and iVar deallocation is turned into empty functions in the supporting C libraries.
  2. 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:

  1. 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.
  2. 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.
  3. Destroy functions should only deallocate the object if the counter reached zero.
  4. Make sure that task core functions call the destroy function not only on local objects, but also on iVars and arrays got as parameters.
  5. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant