Change ScriptCompiler::CompileOptions and add d8 --cache.

Change ScriptCompiler::CompileOptions to allow for two 'cache' modes
(parser or code) and to be explicit about cache consumption or production
(rather than making presence of cached_data imply one or the other.)

Also add a --cache flag to d8, to allow testing the functionality.

-----------------------------
API change

Reason: Currently, V8 supports a 'parser cache' for repeatedly executing the same script. We'd like to add a 2nd mode that would cache code, and would like to let the embedder decide which mode they chose (if any).

Note: Previously, the 'use cached data' property was implied by the presence of the cached data itself. (That is, kNoCompileOptions and source->cached_data != NULL.) That is no longer sufficient, since the presence of data is no longer sufficient to determine /which kind/ of data is present.

Changes from old behaviour:

- If you previously didn't use caching, nothing changes.
Example:
  v8::CompileUnbound(isolate, source, kNoCompileOptions);

- If you previously used caching, it worked like this:

  - 1st run:
  v8::CompileUnbound(isolate, source, kProduceToCache);
  Then, source->cached_data would contain the
  data-to-be cached. This remains the same, except you
  need to tell V8 which type of data you want.
  v8::CompileUnbound(isolate, source, kProduceParserCache);

  - 2nd run:
  v8::CompileUnbound(isolate, source, kNoCompileOptions);
  with source->cached_data set to the data you received in
  the first run. This will now ignore the cached data, and
  you need to explicitly tell V8 to use it:
  v8::CompileUnbound(isolate, source, kConsumeParserCache);
-----------------------------


BUG=
R=marja@chromium.org, yangguo@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=22431

[vogelheim, 2014-07-11 17:39:56]

The full change, as previously discussed. Does this make sense, overall?

[vogelheim, 2014-07-11 17:52:11]

+ulan, because API change.

[marja, 2014-07-14 07:45:46]

lgtm

https://codereview.chromium.org/389573006/diff/1/src/api.cc
File src/api.cc (right):

https://codereview.chromium.org/389573006/diff/1/src/api.cc#newcode1755
src/api.cc:1755: script_data != NULL) {
I don't think it's possible that (options == kProduceParserCache || options ==
kProduceCodeCache) and script_data == NULL, so that part of the if is
unnecessary.

[vogelheim, 2014-07-14 10:40:04]

https://codereview.chromium.org/389573006/diff/1/src/api.cc
File src/api.cc (right):

https://codereview.chromium.org/389573006/diff/1/src/api.cc#newcode1755
src/api.cc:1755: script_data != NULL) {
On 2014/07/14 07:45:46, marja wrote:
> I don't think it's possible that (options == kProduceParserCache || options ==
> kProduceCodeCache) and script_data == NULL, so that part of the if is
> unnecessary.

Well... if any kProduce*Cache is set and Compiler::CompileScript returns an
empty reference, then the script_data will be deleted just above. The comment
above suggests this doesn't happen in normal operation, but apparently in can
happen in tests?

[marja, 2014-07-14 10:41:12]

https://codereview.chromium.org/389573006/diff/1/src/api.cc
File src/api.cc (right):

https://codereview.chromium.org/389573006/diff/1/src/api.cc#newcode1755
src/api.cc:1755: script_data != NULL) {
On 2014/07/14 10:40:04, vogelheim wrote:
> On 2014/07/14 07:45:46, marja wrote:
> > I don't think it's possible that (options == kProduceParserCache || options
==
> > kProduceCodeCache) and script_data == NULL, so that part of the if is
> > unnecessary.
> 
> Well... if any kProduce*Cache is set and Compiler::CompileScript returns an
> empty reference, then the script_data will be deleted just above. The comment
> above suggests this doesn't happen in normal operation, but apparently in can
> happen in tests?
> 

Ahh, I missed the if above which actually does nullify it. My comment is
obsolete.

[Yang, 2014-07-14 11:22:49]

lgtm.

https://codereview.chromium.org/389573006/diff/1/test/cctest/test-compiler.cc
File test/cctest/test-compiler.cc (right):

https://codereview.chromium.org/389573006/diff/1/test/cctest/test-compiler.cc...
test/cctest/test-compiler.cc:397: TEST(SerializeToplevel) {
Note that I updated and moved this entire test to test-serialize.

[ulan, 2014-07-15 06:47:33]

On 2014/07/14 11:22:49, Yang wrote:
> lgtm.
> 
> https://codereview.chromium.org/389573006/diff/1/test/cctest/test-compiler.cc
> File test/cctest/test-compiler.cc (right):
> 
>
https://codereview.chromium.org/389573006/diff/1/test/cctest/test-compiler.cc...
> test/cctest/test-compiler.cc:397: TEST(SerializeToplevel) {
> Note that I updated and moved this entire test to test-serialize.

API doc lgtm, thank you!

[vogelheim, 2014-07-15 11:55:37]

Minor fixes to tests.
Added emulation of the old enum values so that embedders have a chance to adapt.

I'm currently wrestling with the trybots; will commit soon-ish unless someone
screams.

[vogelheim, 2014-07-16 12:18:55]

Committed patchset #5 manually as r22431 (presubmit successful).