Skip to content

Reuse fresh parser resources before speculative host loads #379

Description

@wieslawsoltes

Parent: #266. Related epics: #264, #227.

Proven gap

On exact WebScene main a759ff3a008e362708b6b281ebb7c2742921eb53, normal text-resource loading derives its persistent/process cache key from resource kind, resolved URL, initiator origin, and cookie representation. Parser speculative prefetch instead looks up the same cache using only resource kind and resolved URL.

That key mismatch bypasses an already-fresh admitted script or stylesheet before normal loading can consume it. The current native regression consequently performs duplicate host reads across engine generations (document and script bodies were not reused from the process resource cache and the related four-engine single-flight request-count failure). This directly affects repeated Markdown/webview parser resources after the Service Worker cache-continuity work in #376/#378.

Scope

  • Derive speculative-prefetch cache lookups from the same origin/cookie-partitioned representation key as normal loading.
  • Reuse only entries that are already fresh under the existing expiry metadata. Preserve existing validator revalidation and stale-fallback behavior for non-fresh entries.
  • Keep resource kind, resolved URL, initiator origin, cookie, credentials, admission, and host callback boundaries unchanged and fail closed.
  • Add a browser/WPT-derived freshness oracle plus native exact-key, validator, duplicate-read, 100-cycle latency/memory, and teardown gates.

Exclusions

No new filesystem or network authority; no CacheStorage durability or cross-origin sharing; no change to Service Worker registration, localResourceRoots, localhost mapping, CSP, AppScene, File System Access #248, consolidation #76, or vscode-demo.

Acceptance

  • A fresh parser script/stylesheet cached under one origin/cookie representation is reused without another host read.
  • A different origin or cookie representation never consumes that entry.
  • Expired entries still carry validators to the host and consume a 304 result through the existing path.
  • Browser and native results agree on fresh reuse versus validator revalidation.
  • 100 repeated create/load/destroy cycles stay within p95 <= 100 ms for the cached resource step, <= 8 MiB retained V8 heap after warm-up, and <= 64 MiB RSS after teardown.

Activity

  1. wieslawsoltes commented on Sep 18, 2026

    @wieslawsoltes
    CollaboratorAuthor

    Owned from exact main a759ff3a008e362708b6b281ebb7c2742921eb53 on feature/service-worker-cache-revalidation-266.

    Reproduction: parser speculative prefetch calls read_resource_cache with digest(kind, resolved URL), while the normal loader writes and reads digest(kind, resolved URL + initiator origin + cookie). A fresh admitted parser resource is therefore missed and re-read from the host. This matches the existing Linux sequential reuse and macOS four-engine single-flight request-count failures recorded under #266.

    This child owns only key parity for fresh speculative reuse plus validator/304, isolation, performance, memory, and teardown proof. Origin, cookie, resource kind, freshness, admission, credentials, host callbacks, and stale fallback remain authoritative. It adds no durable CacheStorage, cross-origin reuse, filesystem/network permission, or consumer-specific path.

    Collision audit: the only open PR is consolidation #76, limited to compatibility documentation. #248 owns File System Access resolution. This slice owns the native resource cache/prefetch include, its focused native gate/filter, and a dedicated WPT-style freshness contract/profile; it excludes AppScene, CSS implementation, #76, #248, and vscode-demo.

  2. wieslawsoltes commented on Sep 18, 2026

    @wieslawsoltes
    CollaboratorAuthor

    Implemented and merged in #383 as b5b51017ab1888ecdadbb638590afa645ee5f62a.

    Final scope and evidence:

    • parser prefetch and normal loads now use the same resource-kind, resolved-URL, initiator-origin, and cookie partition key;
    • cross-engine single-flight remains limited to credential-omitting requests or an explicitly shared compilation-cache host; Set-Cookie, uncacheable, origin-changing, and cookie-changing responses remain engine-private;
    • Chrome 153 WPT-derived contract passed 3/3 in 60 ms, covering fresh reuse, validator/304 reuse, and 100 parser cycles with one network request;
    • native focused gate passed 100 cycles with p95 3.90671 ms, stable V8 heap, bounded RSS, cache-policy and credential partition coverage, and teardown coverage;
    • exact-head CI passed Linux X64, macOS ARM64, portable V8, NativeAOT Avalonia 11/12, and native Linux document contracts;
    • NuGet packaging and postmerge tails were canceled because they are outside this focused resource-runtime slice.

    No filesystem resolve, AppScene, CSS, consolidation, or vscode-demo paths changed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    vscode-oss/plannedPlanned for the AppScene/WebScene VS Code OSS integration

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions