Move Finalize from TcImports to another object #8251
Conversation
…ing of TcImports resources
| let mutable ccuInfos: ImportedAssembly list = [] | ||
| let mutable ccuTable: NameMap<ImportedAssembly> = NameMap.empty | ||
| let mutable disposeActions = [] | ||
| let disposeActions = ResizeArray() |
There was a problem hiding this comment.
This remind me of something I was looking at:
fsharp/src/fsharp/ConstraintSolver.fs
Lines 370 to 376 in 0a0889e
this is used a lot in ResolveOverloading and is probably short lived so not the same kind of usage pattern.
I was wondering about the impact of all allocations happening in ResolveOverloading as many things are based on exception objects, I guess just as a convenience to make the error message, but this is only useful when failing to resolve an overload which is a corner case rather than the default.
This happens while checking each of the candidates, and there are several passes (using trace objects), since Exception is a very large object, generally larger itself than the few references we end up needing once the resolution failed to assemble our own exceptions, I intuit that lots of allocations could be saved there, but I also intuit that the refactoring of the data structures wouldn't be a low hanging fruit.
In any case, exciting to see the work you are doing dealing with allocations in the compiler 👍.
There was a problem hiding this comment.
I would wonder too. I've seen this kind of pattern as well in other places. It depends on what the use case is. You can think of this pattern like simply swapping state rather than changing it underneath (which is what ResizeArray) does.
For this PR in particular, using the list state swapping pattern is fine but I need a reference to the actual state without capturing TcImports inside the object doing the disposal. I would have to make this a ref cell which I didn't want, and chose ResizeArray instead.
* Move Finalize from TcImports to another object responsible for disposing of TcImports resources * Use ResizeArray
This moves the disposal of some of the resources that
TcImportsuses to another object. The reason why is because we do not wantTcImportsitself to overrideFinalizeas that causesTcImportsto survive longer on collections. Instead, the object responsible for disposing will be surviving longer. Therefore, allowsTcImportsto be collected sooner.