Removed reference counting from IncrementalBuilder; now relies on GC. #6863
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ed reference counting in incremental builder. Builders can only be invalidated by a type provider, not anything else.
KevinRansom
approved these changes
May 27, 2019
TIHan
commented
May 29, 2019
src/fsharp/CompileOps.fs
Outdated
| static member BuildFrameworkTcImports (ctok, tcConfigP: TcConfigProvider, frameworkDLLs, nonFrameworkDLLs) = | ||
| cancellable { | ||
|
|
||
| let tcConfig = tcConfigP.Get ctok | ||
| let tcResolutions = TcAssemblyResolutions.BuildFromPriorResolutions(ctok, tcConfig, frameworkDLLs, []) | ||
| let tcAltResolutions = TcAssemblyResolutions.BuildFromPriorResolutions(ctok, tcConfig, nonFrameworkDLLs, []) | ||
|
|
||
| // Note: TcImports are disposable - the caller owns this object and must dispose | ||
| let frameworkTcImports = new TcImports(tcConfigP, tcResolutions, None, None) | ||
| let frameworkTcImports = new TcImports(tcConfigP, tcResolutions, None, None, tcConfig.typeProviderThread) |
There was a problem hiding this comment.
Feels a little weird to pass tcConfig.typeProviderThread like this when I can just get it off of tcConfigP? The reason was that when using tcConfigP in order to get a tcConfig, you needed a CompilationThreadToken, which wouldn't be available to me on Dispose.
dsyme
approved these changes
May 30, 2019
This was referenced Jan 17, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
IB (
IncrementalBuilder) was responsible for keepingTcImportsand itself alive using referencing counting.Now this removes reference counting from IB.
Allows
TcImportsto dispose of type providers and binary readers when the GC is about to collect it by leveraging the finalizer,override x.Finalize () = ...The main reason for doing this is that it removes complexity:
TcImportsthat was disposed would throw an assert and that's bad news. In uncommon circumstances, this could happen and it's unclear how it does.Now, this is completely swept away. Lifetime is GC. If you want
TcImportsalive, you simply hold onto it. This will pave the path for a stateless / snapshot model for FCS as we will stop thinking about explicitly disposing of resources.A few cons:
There are a few hacks to accommodate working with old type providers that had an enforced contract dictated by TypeProviderSDK's reflection code. See try use ReferencedAssemblies fsprojects/FSharp.TypeProviders.SDK#305. The reflection code has been removed and type providers that use the newer TypeProviderSDK will not be bound by such a contract.
One downside is that disposal is not deterministic. Type provider resources will not eagerly be disposed of. This isn't necessarily a problem; most of everything is on the GC and in Gen2 at this point anyway. It will mean that any native resources a type provider might have, will now take a bit longer for it to get cleaned up; but it's not going to be a problem as
Disposewill eventually be called for a type provider whenTcImportsis about to be collected. Trust the GC.Remaining work: