Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the past, the
DArray
defined various operators (likemap
,reduce
,mul
, etc.) to return lazy wrappers, which would then get "staged" later to actually materialize a newDArray
. This was done to allow some optimizations across operations, but few were implemented, and that was removed to make writingDArray
operations simpler.A vestige of this old mechanism was the stage cache, which allowed for a DAG of
DArray
operations to exist, which would ensure that values referenced multiple times (such as when doingA = rand(Blocks(4,4), 16, 16); A * A
) would only computeA
once, and then reuse its result. It was fine for this to stick around, since it never had a chance to deduplicate such operations, as they're now immediately executed (which results in the same semantics anyway).A problem with stage caching is that it uses a
WeakKeyDict
to reference submittedDArray
operators, which is known to be slower to free referenced objects and can cause excessive GC pressure and OOM issues. This PR thus removes the stage cache to prevent this from happening anymore. Additionally, some changes are made to ensure that JuliaLang/julia#40626 does not bite us.