mythria: can you add more context about the kind of data to collect? did you want the service worker team to do this?

With IsolatedCodeCache, we fetch the code cache explicitly instead of fetching the cached code along with the resource from the HttpCache. For service worker controlled scripts, we don't fetch from code cache, because service worker cache maintains its own cache where it also stores the cached code [1]. If the fetch from service worker failed, we fetch the resource from the network/HttpCache. In these fallback cases, we don't re-fetch from code cache. We felt it would be good to have the data about these fallback cases. I think this is not a frequent case and hence I think shouldn't impact performance much. Though it will be nice to have some data about how frequent are these fallback cases.

[1] https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/loader/fetch/resource_loader.cc?q=resource_loader.cc&sq=package:chromium&g=0&l=345

I am also OK to close this if service worker team thinks it is more of a corner case and we don't need this data. 

I guess [1] in c#4 is about the script for the service worker itself. Probably are you talking about scripts loaded through service workers (like <script src="https://example.com/fetched_by_service_worker.js"></script> in a controlled page)?
I'm not familiar with IsolatedCodeCache, but let me briefly explain how the current service worker pass code caches from CacheStorage, which is a storage having cached responses.

We are saving code caches for scripts to CacheStorage as a blob side data [2] when cache API is called.
And when a service worker returns a response from the CacheStorage to its client (page), the code cache is served as a CachedMetaData [3].
From my quick scan of code, the served code cache reaches to ScriptResource::SetSerializedCachedMetadata() [4].

[2] https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/cache_storage/cache.cc?g=0&l=395
[3] https://cs.chromium.org/chromium/src/content/renderer/service_worker/service_worker_subresource_loader.cc?type=cs&sq=package:chromium&g=0&l=710
[4] https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/loader/resource/script_resource.cc?type=cs&sq=package:chromium&g=0&l=151

I'm interested in what IsolatedCodeCache will change. If IsolatedCodeCache starts not to use ScriptResource's cache handler, it'll affect code caches served from service workers. If CachedMetaData served from URLLoaders will still work after IsolatedCodeCache, that won't be a matter.

Yes, the comment is about scripts loaded through service workers. 

IsolatedCOdeCache doesn't change anything on the ScriptResource cache handler side. It will continue to use the cached data provided from the CacheStorage. 
However if there was a miss in the CacheStorage and we fallback to the network we may risk missing out on the code cache provided by the HttpCache. 

Earlier, the cached code was stored in the HttpCache. So the requests going through the network would check the HttpCache and return any resource + the cached code (as metadata). With IsolatedCodeCache, we no longer store cached code as a part of HttpCache and we request the cached code explicitly. 

For the service worker controlled pages, we don't request the IsolatedCodeCache because these are expected to serviced by the CacheStorage and nothing changes as long as CacheStorage has an entry for the script. It is only the cases that are not serviced here and that go through network which then checks for HttpCache that might be impacted. Again, if it is the first time we are fetching this resource, then we wouldn't have any cached data corresponding to it, so that wouldn't be different either.

In summary, for the scripts loaded through service workers, we continue to use cached code provided by the cache storage. In cases, where the resource is not present in the cache storage, we may risk missing out cached code from the HttpCache.

So I have some traces from google docs that shows that pass-through fetch code caching can be somewhat significant.  We do need some other code written to support this, though.  Please see  bug 917414  for that work.

If we go ahead with  bug 917414  maybe we can just close this bug since we won't need UMA data to decide?