Commit Graph

20 Commits

Author SHA1 Message Date
marja
df0cb9999f Parsing: Make Parser not know about Isolate during background parsing.
Parser must be able to operate independent of Isolate and the V8 heap during
parsing. After the heap-independent phase, there is a heap dependent phase,
during which we internalize strings, handle errors, etc.

This makes Isolate (also via CompilationInfo) unaccessible during parsing, and
thus decreases the probability of accidental code changes which would add
heap-dependent operations into the heap-independent phase.

Since Isolate is also accessible via CompilationInfo, now CompilationInfo is
only passed to the entry points of parsing, and not stored in Parser.

R=rossberg@chromium.org
BUG=

Review URL: https://codereview.chromium.org/908173003

Cr-Commit-Position: refs/heads/master@{#26612}
2015-02-12 13:02:44 +00:00
jochen@chromium.org
6a14d7d50f Reland 24052 - Require V8 to be explicitly initialized before an Isolate is created
> We also initialize the Isolate on creation.
>
> This should allow for getting rid of the last remaining default isolate
> traces. Also, it'll speed up several isolate related operations that no
> longer require locks.
>
> Embedders that relied on v8::Isolate to return an uninitialized Isolate
> (so they can set ResourceConstraints for example, or set flags that
> modify the way the isolate is created) should either do the setup before
> creating the isolate, or use the recently added CreateParams to pass e.g.
> ResourceConstraints.
>
> BUG=none
> LOG=y
> R=svenpanne@chromium.org
>
> Review URL: https://codereview.chromium.org/469783002

BUG=none
LOG=y
TBR=svenpanne@chromium.org

Review URL: https://codereview.chromium.org/583153002

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-09-19 08:01:35 +00:00
jochen@chromium.org
525ed1130e Revert "Require V8 to be explicitly initialized before an Isolate is created"
LOG=n
TBR=svenpanne@chromium.org
BUG=none

Review URL: https://codereview.chromium.org/582953002

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24055 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-09-18 21:57:10 +00:00
jochen@chromium.org
27f3cc1b9c Require V8 to be explicitly initialized before an Isolate is created
We also initialize the Isolate on creation.

This should allow for getting rid of the last remaining default isolate
traces. Also, it'll speed up several isolate related operations that no
longer require locks.

Embedders that relied on v8::Isolate to return an uninitialized Isolate
(so they can set ResourceConstraints for example, or set flags that
modify the way the isolate is created) should either do the setup before
creating the isolate, or use the recently added CreateParams to pass e.g.
ResourceConstraints.

BUG=none
LOG=y
R=svenpanne@chromium.org

Review URL: https://codereview.chromium.org/469783002

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24052 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-09-18 21:07:50 +00:00
yangguo@chromium.org
c71976d55a Also rename ascii to one-byte in tool scripts.
TBR=marja@chromium.org

Review URL: https://codereview.chromium.org/561743002

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23841 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-09-10 12:56:19 +00:00
bmeurer@chromium.org
d07a2eb806 Rename ASSERT* to DCHECK*.
This way we don't clash with the ASSERT* macros
defined by GoogleTest, and we are one step closer
to being able to replace our homegrown base/ with
base/ from Chrome.

R=jochen@chromium.org, svenpanne@chromium.org

Review URL: https://codereview.chromium.org/430503007

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22812 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-08-04 11:34:54 +00:00
vogelheim@chromium.org
a42612b4a7 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

Review URL: https://codereview.chromium.org/389573006

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22431 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-16 12:18:33 +00:00
jochen@chromium.org
abb0ff205c Buildfix for windows after r22180
TBR=yangguo@chromium.org
LOG=n
BUG=none

Review URL: https://codereview.chromium.org/367293002

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22181 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-03 07:57:29 +00:00
jochen@chromium.org
ca16bb7ae2 Split out libplatform into a separate libary
Also remove the "use default platform" compile flag. Instead, the embedder
has to provide the platform.

Change all binaries to use the default platfrom from libplatform.

Unless --job-based-sweeping is passed, nothing uses the platform yet, so
nothing will break for embedders (yet).

BUG=none
R=jkummerow@chromium.org
LOG=y

Review URL: https://codereview.chromium.org/345903004

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22180 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-07-03 07:37:27 +00:00
jochen@chromium.org
a4506cd3f2 Move platform abstraction to base library
Also split v8-core independent methods from checks.h to base/logging.h and
merge v8checks with the rest of checks.

The CPU::FlushICache method is moved to CpuFeatures::FlushICache

RoundUp and related methods are moved to base/macros.h

Remove all layering violations from src/libplatform

BUG=none
R=jkummerow@chromium.org
LOG=n

Review URL: https://codereview.chromium.org/358363002

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22092 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-30 13:25:46 +00:00
marja@chromium.org
62ffc7de20 New try: Parser: Delay internalizing strings and values
This is a reincarnation of r21841.

The previous try was https://codereview.chromium.org/314603004/ but it regressed
JSBench and morejs.

BUG=
R=rossberg@chromium.org

Review URL: https://codereview.chromium.org/335293004

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21972 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-24 14:03:24 +00:00
marja@chromium.org
9ad39a8043 Revert "Parser: Delay internalizing strings and values." (r21841)
Plus the fixes on top.

Reason: regresses benchmarks (JSBench) and perf (morejs).

TBR=rossberg@chromium.org
BUG=385404
LOG=N

Review URL: https://codereview.chromium.org/345513003

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21882 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-18 07:30:56 +00:00
marja@chromium.org
a290cf8cda Parser: Delay internalizing strings and values.
This is needed so that we can run Parser on a non-main thread (independent
of the Isolate and the V8 heap).

BUG=
R=rossberg@chromium.org

Review URL: https://codereview.chromium.org/314603004

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21841 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-13 13:31:56 +00:00
jochen@chromium.org
56a486c322 Use full include paths everywhere
- this avoids using relative include paths which are forbidden by the style guide
- makes the code more readable since it's clear which header is meant
- allows for starting to use checkdeps

BUG=none
R=jkummerow@chromium.org, danno@chromium.org
LOG=n

Review URL: https://codereview.chromium.org/304153016

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-06-03 08:12:43 +00:00
svenpanne@chromium.org
967a79d21a Unbreak samples and tools.
Removed a related TODO in d8.cc on the way.

BUG=v8::3318
LOG=y
R=dcarney@chromium.org

Review URL: https://codereview.chromium.org/275463002

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21195 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-05-08 06:52:35 +00:00
svenpanne@chromium.org
eeb1d7020e Revert "Simplify v8/Isolate teardown."
This reverts commit r20876, it broke non-snapshot tests.

TBR=bmeurer@chromium.org

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20879 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-04-22 10:45:43 +00:00
svenpanne@chromium.org
618ff3a3f5 Simplify v8/Isolate teardown.
This implies that one better has a v8::V8::Initialize when v8::V8::Dispose is used.

BUG=359977
LOG=y
R=jochen@chromium.org

Review URL: https://codereview.chromium.org/238353015

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20876 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-04-22 09:24:56 +00:00
marja@chromium.org
069d783a91 Remove the PreCompile API and ScriptData.
The new compilation API (ScriptCompiler::Compile) can produce the same data, so
the separate precompilation phase is not needed. ScriptData is replaced by
ScriptCompiler::CachedData.

R=svenpanne@chromium.org
BUG=

Review URL: https://codereview.chromium.org/225753004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20683 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-04-11 11:44:49 +00:00
marja@chromium.org
3d1a17c2ac Update tests to use the new compilation API + related fixes.
Esp. get rid of PreCompile in tests, as it's going to be removed.

Notes:
- The new compilation API doesn't have a separate precompilation phase, so there
is no separate way to check for errors except checking the compilation
errors. Removed some tests which don't make sense any more.
- test-api/Regress31661 didn't make sense as a regression test even before the
compilation API changes, because Blink doesn't precompile this short scripts. So
detecting this kind of errors (see crbug.com/31661 for more information) cannot rely
on precompilation errors.
- test-parsing/PreParserStrictOctal has nothing to do with PreParser, and the comment
about "forcing preparsing" was just wrong.
- test-api/PreCompile was supposed to test that "pre-compilation (aka
preparsing) can be called without initializing the whole VM"; that's no longer
true, since there's no separate precompilation step in the new compile
API. There are other tests (test-parsing/DontRegressPreParserDataSizes) which
ensure that we produce cached data.
- Updated tests which test preparsing to use PreParser directly (not via the
 preparsing API).
- In the new compilation API, the user doesn't need to deal with ScriptData
ever. It's only used internally, and needed in tests that test internal aspects
(e.g., modify the cached data before passing it back).
- Some tests which used to test preparse + parse now test first time parse +
  second time parse, and had to be modified to ensure we don't hit the
  compilation cache.

BUG=
R=ulan@chromium.org

Review URL: https://codereview.chromium.org/225743002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20511 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-04-04 12:36:23 +00:00
marja@chromium.org
dccd57f1ec Add parser-shell.
parser-shell will help to see how much PreParsing gets slower when PreParser
starts doing more checks (especially tracking variables and scopes). It will
also show how much having preparse data (or cached data) speeds up the parsing.

R=ulan@chromium.org
BUG=

Review URL: https://codereview.chromium.org/209353008

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20201 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
2014-03-24 14:43:41 +00:00