Compiled cached data functionality got broken between v8 v6.3 and v6.6

[A.M.]

Generating compiled script data and reusing it used to work in v6.3 in the code like this:

v8::Local<v8::String> v8script = v8::String::NewFromUtf8(isolate, script.c_str(), v8::NewStringType::kNormal, (int) script.length()).ToLocalChecked();
v8::ScriptOrigin scriptOrigin(v8::String::NewFromUtf8(isolatescriptName.c_str()), v8::Local<v8::Uint32>(), v8::Local<v8::Uint32>(), v8::Boolean::New(isolate, false), v8::Int32::New(isolate, scriptID++));

v8::ScriptCompiler::CachedData *cachedData = ... get a new'ed cached data structure;
v8::ScriptCompiler::CompileOptions compileOptions = cachedData ? v8::ScriptCompiler::kConsumeCodeCache : v8::ScriptCompiler::kProduceCodeCache;

v8::ScriptCompiler::Source source(v8script, scriptOrigin, cachedData);

v8::MaybeLocal<v8::Script> compiledScript = v8::ScriptCompiler::Compile(context, &source, compileOptions);

if(!compiledScript.IsEmpty()) {
    //
    // In v6.3.292.49 source.GetCachedData() returned a non-NULL pointer and in v6.6.346.24
    // the returned pointer is always NULL.
    //
    if(compileOptions == v8::ScriptCompiler::kProduceCodeCache && source.GetCachedData())
       cacheScriptData(... , *source.GetCachedData());
}

In v6.6 `source.GetCachedData()` always returns a NULL pointer in the code above. When recompiled with the v6.3 headers and libraries, caching works without any changes in the application code.





This looks like a bug in the code that produces cached data. Using cached data made things run faster 3-4 times for repeated scripts and now I'm taking quite a hit on the application response time.





Any thoughts on how to tweak caching to make it work again?





Thanks!





Andre


[Yang Guo]

This is not a bug. The API you are using has been deprecated. Instead, you should use v8::ScriptCompiler::CreateCodeCache.

Cheers,

Yang

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

•  Yang Guo  •  Google Germany GmbH  •  Erika-Mann-Str. 33  •  80636 Munich  •  yan...@google.com

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks.

[A.M.]

> This is not a bug. The API you are using has been deprecated. Instead, you should use v8::ScriptCompiler::CreateCodeCache.

Thanks, Yang. Updating Doxygen comments for `v8::ScriptCompiler` would be helpful. As it stands now, the comment describes one of the parameters as "\param pre_data Pre-parsing data, as obtained by ScriptData::PreCompile()" and neither parameter nor the mentioned method even exist in v6.6.

[A.M.]

> This is not a bug. The API you are using has been deprecated. Instead, you should use v8::ScriptCompiler::CreateCodeCache.

I implemented caching using the new mechanism and have to say that the old way was more logical and probably faster for a couple of reasons:

* Passing `kProduceCodeCache` into `v8::ScriptCompiler::CompileUnboundScript` makes no sense now because it never produces cached data

* The old mechanism had an opportunity to scan the source only once (whether it did or not is another story) and now it has to scan the source twice - once when it's compiled and once when the code cache is created.

Anyway, working now. Thanks for pointing out the new method.

Andre

[Yang Guo]

The old API is deprecated. The options related to it will eventually be removed.

We don't scan the source when creating a code cache.

The new API is superior because you can create a code cache at arbitrary time, and are not forced to makr the decision at initial compile. If you create the cache after execution, the code cache would also include compiled code for inner functions that have been executed.

Yang

--

--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[A.M.]

 > We don't scan the source when creating a code cache.

Poor choice of words on my part with regards to scanning the source, since the the method that returns cached data is a compiled script. I was referring to `CodeSerializer::Serialize`, which has to traverse the compiled script structures and the logic would suggest that this would touch same structures that were created while compiling, but I see what you are saying about being able to create code cache at different times. Thank you for this details. Much appreciated.

[Yang Guo]

What we used to to is to serialize right after compiling. Compiling and serialization are two totally separate pieces. So tearing them apart with this new API really doesn't add any work.

There is more info here: https://v8project.blogspot.com/2018/04/improved-code-caching.html

Cheers,

Yang

On Wed, Jul 4, 2018 at 5:18 PM A.M. <cis7...@gmail.com> wrote:

 > We don't scan the source when creating a code cache.

Poor choice of words on my part with regards to scanning the source, since the the method that returns cached data is a compiled script. I was referring to `CodeSerializer::Serialize`, which has to traverse the compiled script structures and the logic would suggest that this would touch same structures that were created while compiling, but I see what you are saying about being able to create code cache at different times. Thank you for this details. Much appreciated.

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Leszek Swirski]

The same traversal of compiled structures happened in the old system too (since the snapshot has to contain a transitive closure of all objects that the compilation creates, which is more than you might think), it was just hidden from the API. If you were to call Serialize immediately after Compile, you'd have the exact same behaviour (performance and all) as previously with Compile(..., kProduceCodeCache), it's just that you can now choose to call it later.

See also the blog post on this, there are a lot of benefits to splitting the two up:
https://v8project.blogspot.com/2018/04/improved-code-caching.html

On Wed, Jul 4, 2018 at 4:18 PM A.M. <cis7...@gmail.com> wrote:

 > We don't scan the source when creating a code cache.

Poor choice of words on my part with regards to scanning the source, since the the method that returns cached data is a compiled script. I was referring to `CodeSerializer::Serialize`, which has to traverse the compiled script structures and the logic would suggest that this would touch same structures that were created while compiling, but I see what you are saying about being able to create code cache at different times. Thank you for this details. Much appreciated.

[A.M.]

I see. Makes sense. Thanks for taking the time to explain, Leszek.