Is it per-source or per-function cache? How global is this cache (is it per page, frame, tab, browser)?
Is it clear for user why cache hit happens and how it increases performance of their app?

It looks like it mostly important during page load and DevTools performance panel has special action - "Start profiling and reload page" which disables debugger and other agents and reload page recording trace, at any time user can stop recording and inspect recorded profile, this profile can contain from cache / without cache information.

The cache is per-source, but we may not have produced code cache for every function in the script. So there may be functions that do not need to compile as the code originate from cache, and others that do need to compile.

The code cache we are talking about is persistent and part of the HTTP cache. I think for users that would care about this detail it is clear what benefits the code cache brings.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/5dcedc18c1dec88f0b2a7118fef551de1a45a8ec

commit 5dcedc18c1dec88f0b2a7118fef551de1a45a8ec
Author: Yang Guo <yangguo@chromium.org>
Date: Wed Sep 27 14:32:34 2017

[snapshot] correctly mark SFIs with deserialized code.

We used to only mark top-level SFIs with the 'deserialized' bit.
Now we do it for every SFI that has cached code. This is the
first step to surface caching information in the future.

R=cbruni@chromium.org

Bug:  chromium:769166 
Change-Id: I12f21511419ce54fd07a2cc277a65866660c366a
Reviewed-on: https://chromium-review.googlesource.com/686715
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48184}
[modify] https://crrev.com/5dcedc18c1dec88f0b2a7118fef551de1a45a8ec/src/snapshot/code-serializer.cc
[modify] https://crrev.com/5dcedc18c1dec88f0b2a7118fef551de1a45a8ec/test/cctest/test-serialize.cc

If I understand correctly, there are two caches that store scripts
- HTTP cache
- Cache Storage (aka "service worker cache")

Each script cache can also store V8 code caching. I think there's interest in being able to inspect whether code caching was used for both the Cache Storage and HTTP cache cases.

Is this the same one as what is discussed on the other thread? E.g. looks like there're two desires:

- It'd be great if whether something comes from cached bytecode or not could be indicated in tracing and perhaps in dev tools
- It'd be useful to have something like that in resource timings to collect that from wild

And this issue is about the former (for the latter Web Perf W3C WG is the right place to discuss).

Matt: and yes we'll want that info for both cases.

+kouhei, +hiroshige as they're going to look into adding more detailed UMA around V8 code caching.

Assigning horo@ per offline discussion. (Still P3 for now, please indicate if this needs higher priority)

I created a CL to show the V8 cache information in DevTools:
https://chromium-review.googlesource.com/c/chromium/src/+/694405

Deleted: V8CacheInfoInDevTools.png 53.9 KB

	V8CacheInfoInDevTools.png 53.9 KB View Download

Could DevTools + V8 confirm this is the UI we want (comment 9)? And does this meet Facebook's use case?

Note that the current caching info is only at the script granularity. If code for a script is cached, really only the top-level function and iifes benefit. We now also have a kProduceFullCodeCache option when compiling the script to cache code for all functions in the script. Once that option is used, we should provide a per-function way to surface caching information.

The change in #5 adds the per-function cache info, but that's not exposed yet, mainly because I don't know how to best expose it.

If V8 expose Function::Deserialized() method, Blink can check it in 
InspectorFunctionCallEvent::Data() and can show it in the DevTools
Timeline.

[1]: https://chromium-review.googlesource.com/c/v8/v8/+/694327
[2]: https://chromium-review.googlesource.com/c/chromium/src/+/694326

Deleted: Deserialized.png 65.1 KB

	Deserialized.png 65.1 KB View Download

Nate, Vladan: your feedback's also really appreciated.  Also +caseq@ for DevTools UI.

@horo, all Devtools related functionality should be exposed via inspector protocol going forward, so I'm not entirely sure whether exposing v8::Function::Deserialized is the right way to do it.

I'm not familiar enough with the performance tab.
But I think the performance tab is using the infrastructure of TRACE logs same as chrome://tracing, not using the inspector protocol.

Is my understanding incorrect? > DevTools team

> Nate, Vladan: your feedback's also really appreciated

This UI works for us.

Ieas for possible improvements:
- as you mentioned, seeing which specific functions were de-serialized and which were not would also be useful
- you might want to add a tooltip to the UI to explain to other users what "Deserialized" means. Maybe "File was loaded as pre-compiled code from HTTP cache"?
- it would be nice to know if the function was de-serialized from bytecode or JITed code

We never cached optimized code. With Ignition and TurboFan, this means that we only cache bytecode. It makes no sense to cache optimized code, since these are context-dependent, and since we deserialize into foreign contexts, cached optimized code would probably just deopt all the time.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f12653d66a5166628b845deabbbec4482e5ea38d

commit f12653d66a5166628b845deabbbec4482e5ea38d
Author: Tsuyoshi Horo <horo@chromium.org>
Date: Tue Oct 24 05:48:01 2017

Show the info of V8 cache and ScriptStream in DevTools

Screenshot:  crbug.com/769166#c9 

Bug:  769166 
Change-Id: I87a7b39bedbf22b54daf10356c45bf0eebeccf3d
Reviewed-on: https://chromium-review.googlesource.com/694405
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#511044}
[add] https://crrev.com/f12653d66a5166628b845deabbbec4482e5ea38d/third_party/WebKit/LayoutTests/http/tests/devtools/service-workers/resources/v8-cache-iframe.html
[add] https://crrev.com/f12653d66a5166628b845deabbbec4482e5ea38d/third_party/WebKit/LayoutTests/http/tests/devtools/service-workers/resources/v8-cache-script.js
[add] https://crrev.com/f12653d66a5166628b845deabbbec4482e5ea38d/third_party/WebKit/LayoutTests/http/tests/devtools/service-workers/resources/v8-cache-worker.js
[add] https://crrev.com/f12653d66a5166628b845deabbbec4482e5ea38d/third_party/WebKit/LayoutTests/http/tests/devtools/service-workers/service-worker-v8-cache-expected.txt
[add] https://crrev.com/f12653d66a5166628b845deabbbec4482e5ea38d/third_party/WebKit/LayoutTests/http/tests/devtools/service-workers/service-worker-v8-cache.html
[modify] https://crrev.com/f12653d66a5166628b845deabbbec4482e5ea38d/third_party/WebKit/LayoutTests/http/tests/devtools/tracing/timeline-js/compile-script-expected.txt
[modify] https://crrev.com/f12653d66a5166628b845deabbbec4482e5ea38d/third_party/WebKit/Source/bindings/core/v8/V8ScriptRunner.cpp
[modify] https://crrev.com/f12653d66a5166628b845deabbbec4482e5ea38d/third_party/WebKit/Source/core/inspector/InspectorTraceEvents.cpp
[modify] https://crrev.com/f12653d66a5166628b845deabbbec4482e5ea38d/third_party/WebKit/Source/core/inspector/InspectorTraceEvents.h
[modify] https://crrev.com/f12653d66a5166628b845deabbbec4482e5ea38d/third_party/WebKit/Source/devtools/front_end/performance_test_runner/TimelineTestRunner.js
[modify] https://crrev.com/f12653d66a5166628b845deabbbec4482e5ea38d/third_party/WebKit/Source/devtools/front_end/timeline/TimelineUIUtils.js

The patch #20 landed in 64.0.3249.0.

$ git find-releases f12653d66a5166628b845deabbbec4482e5ea38d
commit f12653d66a5166628b845deabbbec4482e5ea38d was:
  initially in 64.0.3249.0