Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Be resilient to asset-cache mutating while retrieving assets from the host #72599

Merged
merged 10 commits into from
Mar 21, 2024

Conversation

CyrusNajmabadi
Copy link
Member

The asset cache serves more as a weak cache of data, storing information on the server in the hopes it will be useful at future points in time. It contains a GC thread that wakes up every minute or so and flushes data it thinks isn't needed anymore. Due to that, access to the data from the cache itself is fundamentally racey and should not be trusted.

CyrusNajmabadi and others added 4 commits March 19, 2024 10:25
In a perf fix I made last week, I assumed _assetCache wouldn't change underneath me during execution of SynchronizeAssetsAsync. That assumption is not true.

Now, if the asset cache changes such that the missingChecksums array is no longer sufficient to hold all missing checksums, then grow the array capacity such that it can hold additional entries that might now be missing.
@CyrusNajmabadi CyrusNajmabadi requested a review from a team as a code owner March 19, 2024 18:03
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead labels Mar 19, 2024
@@ -29,39 +29,34 @@ internal sealed partial class AssetProvider(Checksum solutionChecksum, SolutionA
private readonly SolutionAssetCache _assetCache = assetCache;
private readonly IAssetSource _assetSource = assetSource;

private T GetRequiredAsset<T>(Checksum checksum)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this operation si fundamentally not supported. there is no way, ever, to ensure that a checksum you're asking for is actually in the asset provider (unles sit was pinned. but that's a vanishingly small number of cases).

@@ -136,24 +131,60 @@ public async ValueTask SynchronizeProjectAssetsAsync(ProjectStateChecksums proje
missingChecksumsCount = 0;
foreach (var checksum in checksums)
{
if (!_assetCache.TryGetAsset<object>(checksum, out _))
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

view with whitespace off.

@@ -47,14 +51,17 @@ public async ValueTask SynchronizeSolutionAssetsAsync(Checksum solutionChecksum,

solutionChecksumObject.AddAllTo(checksums);
checksums.Remove(solutionChecksumObject.Checksum);
await _assetProvider.SynchronizeAssetsAsync(assetHint: AssetHint.None, checksums, cancellationToken).ConfigureAwait(false);
await _assetProvider.SynchronizeAssetsAsync(assetHint: AssetHint.None, checksums, results: null, cancellationToken).ConfigureAwait(false);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so we could pass a dictionary here that we then read in below. but i didn't feel like it was worth it. the data will normally always stay in the asset provider. and the cahnge below to use GetAssetAsync will normally find it, or rarely then go and reretrieve it in the rare unlucky case. that saves a potentially large dictionary alloc here (even if pooled).


await _assetProvider.SynchronizeAssetsAsync(
assetHint: projectChecksum.ProjectId, checksums, cancellationToken).ConfigureAwait(false);
assetHint: projectChecksum.ProjectId, checksums, results: null, cancellationToken).ConfigureAwait(false);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here.

Copy link
Contributor

@ToddGrun ToddGrun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@CyrusNajmabadi CyrusNajmabadi merged commit 65c67e0 into dotnet:main Mar 21, 2024
27 checks passed
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Mar 21, 2024
@CyrusNajmabadi CyrusNajmabadi deleted the assets branch March 21, 2024 01:25
@RikkiGibson RikkiGibson modified the milestones: Next, 17.10 P3 Mar 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-IDE untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants