Moves all files related to AST and scopes into ast/,
and all files related to scanner & parser to parsing/.
Also eliminates a couple of spurious dependencies.
R=mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1481613002
Cr-Commit-Position: refs/heads/master@{#32351}
Introduce a new JSGlobalSpecialization advanced reducer that runs
during the initial inlining and context specialization, and specializes
the graph to the globals of the native context. Currently we assume
that we do not inline cross native context, but long-term we will grab
the global object from the JSLoadGlobal/JSStoreGlobal feedback (with the
new global load/store ICs that are currently in the workings), and then
this whole specialization will be fully compositional even across
cross-context inlining.
Note that we cannot really handle most of the stores to global object
property cells because TurboFan doesn't have a mechanism to enforce
certain representations. Also note that we cannot yet fully benefit
from the type feedback collected on the global object property cells,
because the type system cannot deal with maps in a reasonable way.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Committed: https://crrev.com/6fbf7903f94924ea066af481719898bd9667b6eb
Cr-Commit-Position: refs/heads/master@{#31139}
Review URL: https://codereview.chromium.org/1387393002
Cr-Commit-Position: refs/heads/master@{#31148}
Reason for revert:
Breaks GC stress: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/1984/steps/Bisect%20c5528ac1.Retry/logs/regress-crbug-450960
Original issue's description:
> [turbofan] Add initial support for global specialization.
>
> Introduce a new JSGlobalSpecialization advanced reducer that runs
> during the initial inlining and context specialization, and specializes
> the graph to the globals of the native context. Currently we assume
> that we do not inline cross native context, but long-term we will grab
> the global object from the JSLoadGlobal/JSStoreGlobal feedback (with the
> new global load/store ICs that are currently in the workings), and then
> this whole specialization will be fully compositional even across
> cross-context inlining.
>
> Note that we cannot really handle most of the stores to global object
> property cells because TurboFan doesn't have a mechanism to enforce
> certain representations. Also note that we cannot yet fully benefit
> from the type feedback collected on the global object property cells,
> because the type system cannot deal with maps in a reasonable way.
>
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
> R=jarin@chromium.org
> BUG=v8:4470
> LOG=n
>
> Committed: https://crrev.com/6fbf7903f94924ea066af481719898bd9667b6eb
> Cr-Commit-Position: refs/heads/master@{#31139}
TBR=jarin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4470
Review URL: https://codereview.chromium.org/1390073004
Cr-Commit-Position: refs/heads/master@{#31144}
Introduce a new JSGlobalSpecialization advanced reducer that runs
during the initial inlining and context specialization, and specializes
the graph to the globals of the native context. Currently we assume
that we do not inline cross native context, but long-term we will grab
the global object from the JSLoadGlobal/JSStoreGlobal feedback (with the
new global load/store ICs that are currently in the workings), and then
this whole specialization will be fully compositional even across
cross-context inlining.
Note that we cannot really handle most of the stores to global object
property cells because TurboFan doesn't have a mechanism to enforce
certain representations. Also note that we cannot yet fully benefit
from the type feedback collected on the global object property cells,
because the type system cannot deal with maps in a reasonable way.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1387393002
Cr-Commit-Position: refs/heads/master@{#31139}
This CL also allows to use arbitrary number of feedback vector elements for particular slot kind.
Review URL: https://codereview.chromium.org/1370303004
Cr-Commit-Position: refs/heads/master@{#31050}
Note that this tests performed unnecessary many iterations which led to
long runtimes in debug mode and also caused flaky GCs during that would
cause the optimized code map to be flushed and violated assumptions.
R=yangguo@chromium.org
BUG=v8:4363
LOG=N
Review URL: https://codereview.chromium.org/1280973002
Cr-Commit-Position: refs/heads/master@{#30070}
This allows the optimized code map to contain no context-dependent
entries, but still hold one context-independent entry. This is a
precursor to extending the lifetime of the context-independent entry.
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1249543005
Cr-Commit-Position: refs/heads/master@{#29788}
This allows context-independent code generated by TurboFan to be cached
in the optimized code map and reused across native contexts. Note that
currently this cache is still flushed at GC time.
R=bmeurer@chromium.org,mvstanton@chromium.org
TEST=cctest/test-compiler/OptimizedCodeSharing
Review URL: https://codereview.chromium.org/1208013002
Cr-Commit-Position: refs/heads/master@{#29313}
Before this we had 3 super related lexical bindings that got injected
into method bodies: .home_object, .this_function, and new.target.
With this change we get rid of the .home_object one in favor of using
.this_function[home_object_symbol] which allows some simplifications
throughout the code base.
BUG=v8:3768
LOG=N
R=adamk@chromium.org, wingo@igalia.com
Review URL: https://codereview.chromium.org/1154103005
Cr-Commit-Position: refs/heads/master@{#28802}
Embed constant pools within their corresponding Code
objects.
This removes support for out-of-line constant pools in favor
of the new approach -- the main advantage being that it
eliminates the need to allocate and manage separate constant
pool array objects.
Currently supported on PPC and ARM. Enabled by default on
PPC only.
This yields a 6% improvment in Octane on PPC64.
R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
BUG=chromium:478811
LOG=Y
Review URL: https://codereview.chromium.org/1162993006
Cr-Commit-Position: refs/heads/master@{#28801}
When we enter a method that needs access to the [[HomeObject]]
we allocate a local variable `.home_object` and assign it the
value from the [[HomeObject]] private symbol. Something along
the lines of:
method() {
var .home_object = %ThisFunction()[home_object_symbol];
...
}
BUG=v8:3867, v8:4031
LOG=N
Review URL: https://codereview.chromium.org/1135243004
Cr-Commit-Position: refs/heads/master@{#28644}
This just delegates to SharedFunctionInfo::optimization_disabled and
was primarily used for assertions. Removing it due to misleading name
because already optimized functions reported being "non-optimizable".
This relands commit 181d7b8597.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1146423002
Cr-Commit-Position: refs/heads/master@{#28577}
Reason for revert:
Causes assertions to fire when serializing optimized code.
Original issue's description:
> Remove obsolete JSFunction::IsOptimizable predicate.
>
> This just delegates to SharedFunctionInfo::optimization_disabled and
> was primarily used for assertions. Removing it due to misleading name
> because already optimized functions reported being "non-optimizable".
>
> R=titzer@chromium.org
>
> Committed: https://crrev.com/181d7b85977eb752b19e1de902093783e31330ef
> Cr-Commit-Position: refs/heads/master@{#28551}
TBR=titzer@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1148973005
Cr-Commit-Position: refs/heads/master@{#28554}
This just delegates to SharedFunctionInfo::optimization_disabled and
was primarily used for assertions. Removing it due to misleading name
because already optimized functions reported being "non-optimizable".
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1150683002
Cr-Commit-Position: refs/heads/master@{#28551}
When the page is controlled by a ServiceWorker, the ServiceWorker can return an opaque (non-CORS cross origin) resource response.
We need to treat the messages from such script resource as opaque.
Committed: https://crrev.com/7a599c5e1242d3c5ab7515ee149623da90ae69ec
Cr-Commit-Position: refs/heads/master@{#28445}
Review URL: https://codereview.chromium.org/1140673002
Cr-Commit-Position: refs/heads/master@{#28459}
When the page is controlled by a ServiceWorker, the ServiceWorker can return an opaque (non-CORS cross origin) resource response.
We need to treat the messages from such script resource as opaque.
Review URL: https://codereview.chromium.org/1140673002
Cr-Commit-Position: refs/heads/master@{#28445}
According to Source Map specification [1] source map url can be passed either as a magic comment at the end of script or as SourceMap http header. We already parse the former value and expose it on Script object. This change allows to unify the way we deal with source map urls received in http header by providing api for passing that url into the script being compiled.
source_map_url is intentionally not passed into CompilationCacheScript::Lookup. The cache is anyways disabled when debugger is on.
[1] https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit
LOG=Y
BUG=chromium:462572
Review URL: https://codereview.chromium.org/983603003
Cr-Commit-Position: refs/heads/master@{#27017}
This adds an "experimental" API hook (v8::ScriptCompiler::CompileModule)
allowing compilation of modules. The code gen is incredibly basic: the
module body is represented by a Block in the AST. But this at least gets
more of the pipeline working, and opens the door to writing mjsunit tests
(once d8 is modified to support module compilation).
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/902093002
Cr-Commit-Position: refs/heads/master@{#26496}
The first try failed because I needed to make a better distinction
between clearing ICs according to policy at GC time or unconditional
clearing (say, via %ClearFunctionTypeFeedback).
It was also blocked by an issue in super constructor calls.
This fix (https://codereview.chromium.org/892113002/) needs to land
before checking in this CL.
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/866493003
Cr-Commit-Position: refs/heads/master@{#26420}
Reason for revert:
Breaks a regression test on linux isloates, and linux with gcc 4.8.
Original issue's description:
> Use a WeakCell in the CallIC type vector.
>
> This allows us to clear the IC on a more sedate schedule, just
> like Load and Store ICs.
>
> R=ulan@chromium.org
> BUG=
>
> Committed: https://crrev.com/bcc79d33ca6d97d9ecfcfcf110a6ea84a0225389
> Cr-Commit-Position: refs/heads/master@{#26332}
TBR=ulan@chromium.org,mvstanton@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/886663004
Cr-Commit-Position: refs/heads/master@{#26334}
In DevTools we need one more flag for script origin - is debugger script. We already have "is shared origin" flag. The new flag added by analogy with the old but new has accessor in script object.
R=yurys@chromium.org
Review URL: https://codereview.chromium.org/879553002
Cr-Commit-Position: refs/heads/master@{#26324}
(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
Attempting to re-use the type feedback vector stored in the
SharedFunctionInfo turns out to be difficult among the various cases.
It will be much easier to do this when deferred type feedback processing
is removed, as is in the works.
Created bug v8:3212 to track re-introducing the optimization of reusing
the type vector on recompile before optimization.
The CL also brings back the type vector on the SharedFunctionInfo.
BUG=351257
LOG=Y
R=bmeurer@chromium.org, bmeuer@chromium.org
Review URL: https://codereview.chromium.org/199973004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19919 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This feature makes it possible to associate data with a script and get it back
when the script is compiled or when an event is handled. It was historically
used by Chromium Dev Tools, but not any more. It is not used by node.js.
Note: this has nothing to do with the preparse data, despite the confusing name.
The preparse data is passed as ScriptData*.
Note 2: This is the same as r19616 ( https://codereview.chromium.org/184403002/ )
with a unused variable fix in bootstrapper.cc.
R=svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/185533014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19702 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This feature makes it possible to associate data with a script and get it back
when the script is compiled or when an event is handled. It was historically
used by Chromium Dev Tools, but not any more. It is not used by node.js.
Note: this has nothing to do with the preparse data, despite the confusing name.
The preparse data is passed as ScriptData*.
R=svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/184403002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19616 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In order to properly sanitize exception data during a 'window.onerror'
handler, we need to know whether a script was served with proper CORS
headers at the time it was loaded into V8. This patch adds a single bool
to ScriptOrigin, and pipes that through the compiler to land on the
Script object. We can then retrieve the parameter when calling the
embedder's exception callback.
BUG=crbug.com/159566
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/20646006
Patch from Mike West <mkwst@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15963 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
