the implications of this are not clear to me. @jasonmalinowski do you know this part any better?

so we use memory mapped files for this right? is there a concern about what this does for using up address space?

The call to GetValue is just forcing this line to run:

sure. but there are two things that aren't clear to me:

1. how expensive all those .GetValue calls will be...
2. how expensive this is:

            _initialSource = null;
            _version = textAndVersion.Version;
            _filePath = textAndVersion.FilePath;
            _loadDiagnostic = textAndVersion.LoadDiagnostic;
            _text = new RecoverableText(this, textAndVersion.Text);
            _text.GetValue(CancellationToken.None); // force access to trigger save
            return textAndVersion;

i don't have a good sense of what the tradeoff might be ehre.

how expensive all those .GetValue calls will be...

In this case, the call to _initialSource.GetValue is negligible because _initialSource is a ConstantValueSource<TextAndVersion>. The overall cost of the new code is essentially the cost of:

We already perform this operation as part of the TouchDocumentAction processing, so there are two fundamental differences with this approach:

1. Saving to temporary storage occurs earlier, though it still occurs exactly one time in total.
2. For the case where processing queue depth triggers a Gen 2 GC, it may cause the weak reference to go away which then needs to be loaded from temporary storage during subsequent event processing. This case is unlikely to be slower than the previous approach because this is the scenario that most often led to crashes prior to this pull request.

For the case where processing queue depth triggers a Gen 2 GC

Just to check, are we seeing cases where we have CompilationTrackers with multiple TouchDocumentActions queued to the same document?

One of the heaps I have suggests yes.