Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Memory fixes. Resolves #10867, and resolves #14080 #14372
There were a few memory leaks in executor and some instances of where ResourceScope was causing problems. This should fix those known issues.
To elaborate on the ResourceScope issue: there are some times when classes such as Executor creates other NativeResources (usually NDArrays) after the Executor has been instantiated. The executor then has a dependency on that new NativeResource. Since these happen at different times, they could potentially be created at different ResourceScope levels. The result is an unstable state where exiting the scope would cause a crash. Fixed this by adding a method to NativeResource which allows moving a resource to the same scope as another. This allows the parent class to control the scope of their dependencies.
Please feel free to remove inapplicable items for your PR.
@nswamy This is because there is no guarantee that they are created at the same ResourceScope level. For example, the Executor gets created and returned to the user. The user then opens up a ResourceScope to do inference. In this scope, the executor might end up creating new resources for itself. Those resources are then in the scope level of the user's ResourceScope and get disposed when that closes. This leaves the Executor without the dependencies it created.
The solution is to have objects like executor put any dependencies that they create into the same ResourceScope as themselves. This way they are all coupled together. I thought about using moveToOuterScope but there's no way to know how many levels of scope could be between the two.
@andrewfayres, thanks for taking care of this, Its a really nice find :)
I find the design of executor less than desirable(where it creates states in a method dynamically) after the
My suggestion is to create a couple methods in ResourceScope.
I am open to hear any other interesting ideas that is less intrusive.
I came up with a different solution which we (@nswamy and I) discussed offline. Essentially, ResourceScope.using already has an optional parameter for an existing scope. A few changes minor changes should let us reuse that.
This approach should be more consistent and intuitive. I'll update the PR.
summary of offline discussion: