Adds support for compiling top level code to bytecode to be run in the
interpreter.
Also moves PassesFilter to String:: so that it can be used to filter top
level script names as well as functions (used in
https://codereview.chromium.org/1379093002/)
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1372293005
Cr-Commit-Position: refs/heads/master@{#31142}
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}
It was supposed to be used by the CPU profiler. But as long as
these ranges are not built when profiler is not running, once
the profiler is started there're no ranges for already compiled
functions. So basically this code never worked.
As long as now CPU profiler uses another approach this code is no
longer needed.
Review URL: https://codereview.chromium.org/1376333003
Cr-Commit-Position: refs/heads/master@{#31056}
This enables linter checking for "readability/namespace" violations
during presubmit and instead marks the few known exceptions that we
allow explicitly.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1371083003
Cr-Commit-Position: refs/heads/master@{#31019}
This name makes it clear that the flag (also the variant in the Compiler)
is talking about specializing to the function context instead of i.e. the
native context.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1372513003
Cr-Commit-Position: refs/heads/master@{#30934}
Replaces all instances of the code which computed the debug
name of a stub or function with calls to CompileInfo::GetDebugName instead.
Also:
- Removes useless parameter on CodeStub::GetMajorName
- Removes FakeStubForTesting since it is no longer required
- Adds CompileInfo::ShouldEnsureSpaceForLazyDeopt() to replace unclear calls to IsStub().
Review URL: https://codereview.chromium.org/1297203002
Cr-Commit-Position: refs/heads/master@{#30324}
Prior to this patch, we enter a global debug mode whenever a break point
is set. By entering this mode, all code is deoptimized and activated
frames are recompiled and redirected to newly compiled debug code.
After this patch, we only deoptimize/redirect for functions we want to
debug. Trigger for this is Debug::EnsureDebugInfo, and having DebugInfo
object attached to the SFI prevents optimization/inlining.
The result is that we can have optimized code for functions without break
points alongside functions that do have break points, which are not
optimized.
R=mstarzinger@chromium.org, ulan@chromium.org
BUG=v8:4132
LOG=Y
Review URL: https://codereview.chromium.org/1233073005
Cr-Commit-Position: refs/heads/master@{#29758}
We have to reland these two commits at once, because the first breaks
some asm.js benchmarks without the second. The change was reverted
because of bogus checks in the verifier, which will not work in the
presence of OSR (and where hidden because of the type back propagation
hack in OSR so far). Original messages are below:
[turbofan] Add new JSFrameSpecialization reducer.
The JSFrameSpecialization specializes an OSR graph to the current
unoptimized frame on which we will perform the on-stack replacement.
This is used for asm.js functions, where we cannot reuse the OSR
code object anyway because of context specialization, and so we could as
well specialize to the max instead.
It works by replacing all OsrValues in the graph with their values
in the JavaScriptFrame.
The idea is that using this trick we get better performance without
doing the unsound backpropagation of types to OsrValues later. This
is the first step towards fixing OSR for TurboFan.
[turbofan] Perform OSR deconstruction early and remove type propagation.
This way we don't have to deal with dead pre-OSR code in the graph
and risk optimizing the wrong code, especially we don't make
optimistic assumptions in the dead code that leaks into the OSR code
(i.e. deopt guards are in dead code, but the types propagate to OSR
code via the OsrValue type back propagation).
BUG=v8:4273
LOG=n
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1226673005
Cr-Commit-Position: refs/heads/master@{#29486}
The JSFrameSpecialization specializes an OSR graph to the current
unoptimized frame on which we will perform the on-stack replacement.
This is used for asm.js functions, where we cannot reuse the OSR code
object anyway because of context specialization, and so we could as well
specialize to the max instead.
It works by replacing all OsrValues in the graph with their values in
the JavaScriptFrame.
The idea is that using this trick we get better performance without
doing the unsound backpropagation of types to OsrValues later. This is
the first step towards fixing OSR for TurboFan.
R=jarin@chromium.org
BUG=v8:4273
LOG=n
Review URL: https://codereview.chromium.org/1225683004
Cr-Commit-Position: refs/heads/master@{#29476}
Note that prior to having canonical shared function infos, this has
been a source of duplicate shared function infos.
R=bmeurer@chromium.org
BUG=chromium:504787
LOG=N
Review URL: https://codereview.chromium.org/1209383002
Cr-Commit-Position: refs/heads/master@{#29326}
- Thread Type::FunctionType through stubs and the TF pipeline.
- Augment Typer to decorate parameter nodes with types from
a Type::FunctionType associated with interface descriptors.
- Factor interface descriptors into platform-specific and
platform-independent components so that all descriptors share
a common Type::FunctionType for all platforms.
Review URL: https://codereview.chromium.org/1197703002
Cr-Commit-Position: refs/heads/master@{#29248}
Speculative revert in the hopes of fixing serializer crashes seen in canary.
This reverts commit c166945083, as well as
followup change "Do not look for existing shared function info when compiling a new script."
(commit 7c43967bb7).
BUG=chromium:503552,v8:4132
TBR=yangguo@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1207583002
Cr-Commit-Position: refs/heads/master@{#29241}
Each Script object now keeps a WeakFixedArray of SharedFunctionInfo
objects created from this script.
This way, when compiling a function, we do not create duplicate shared
function info objects when recompiling with either compiler.
This fixes a class of issues in the debugger, where we set break points
on one shared function info, but functions from duplicate shared function
infos are not affected.
LOG=N
BUG=v8:4132
Review URL: https://codereview.chromium.org/1183733006
Cr-Commit-Position: refs/heads/master@{#29151}
Reason for revert:
Breaks Windows debug.
Original issue's description:
> [turbofan] Record the SharedFunctionInfo of ALL inlined functions.
>
> Previously we only recorded the SharedFunctionInfo of inlined functions
> that had at least one (lazy) deopt point left at code generation time.
>
> R=mstarzinger@chromium.org
>
> Committed: ffa0b4007cTBR=mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1178683004
Cr-Commit-Position: refs/heads/master@{#28920}
Previously we only recorded the SharedFunctionInfo of inlined functions
that had at least one (lazy) deopt point left at code generation time.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1175953002.
Cr-Commit-Position: refs/heads/master@{#28919}
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}
This stub will be used as the basis of a Math.floor-specific CallIC to
detect and track calls to floor that return -0.
Along the way:
- Create a TurboFanCodeStub super class from which the StringLength and
MathRound TF stubs derive.
- Fix the ugly hack that passes the first stub parameter as the "this"
pointer in the the TF-compiled JS function.
- Fix bugs in the ia32/x64 disassembler.
Review URL: https://codereview.chromium.org/1137703002
Cr-Commit-Position: refs/heads/master@{#28339}
Now all nodes that care about deoptimization always take frame state
inputs no matter whether deoptimization is enabled for a particular
function. In case that deoptimization is off, the AstGraphBuilder just
inserts the empty frame state. This greatly simplifies the logic in
various places and makes testing easier as well, and is probably the
first step towards enabling --turbo-deoptimization by default.
There seems to be no noticable performance impact on asm.js programs.
Also fix the graph replay in order to regenerate the scheduler unittests.
Review URL: https://codereview.chromium.org/1106613003
Cr-Commit-Position: refs/heads/master@{#28026}
This removes the CompilationInfoWithZone class from the header file
because it is more than a pure convenience class and shouldn't be used
outside of the compiler at all.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1000353004
Cr-Commit-Position: refs/heads/master@{#27411}
it is the last patch of https://codereview.chromium.org/1012633002
All that we need here is to push the collected info to the profiler
and convert it into actionable information about deopt.
On the Next: get the info accessible by embedder.
BUG=chromium:452067
LOG=n
TEST=DeoptAtFirstLevelInlinedSource, DeoptAtSecondLevelInlinedSource, DeoptUntrackedFunction
Review URL: https://codereview.chromium.org/1013143003
Cr-Commit-Position: refs/heads/master@{#27403}
This removes the stub-based constructor from CompilationInfoWithZone
as this class is more than a pure convenience class and only by chance
doesn't have an effect in the destructor.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1026513004
Cr-Commit-Position: refs/heads/master@{#27376}
Use a delegating constructor for CompilationInfo, reducing duplicated
code. Simplified handling of InlinedFunctionInfos on the way: When we
start compiling, we have bigger things to worry about than a default
vector.
Reduced the usage of a SharedFunctionInfo for compiling, this is a
slighty strange concept.
Review URL: https://codereview.chromium.org/1018853004
Cr-Commit-Position: refs/heads/master@{#27299}
This is the fifth part of https://codereview.chromium.org/1012633002
In this part we collect the offsets of deopt calls and save it into
an inlined function info.
On the Next:
Later when deopt happens we will get the offset of deopt call and
search it among inlined infos.
BUG=chromium:452067
LOG=n
Review URL: https://codereview.chromium.org/1011113004
Cr-Commit-Position: refs/heads/master@{#27258}
this is the second part of https://codereview.chromium.org/1012633002.
almost mechanical change.
I'd like to enable positions tracking when cpu profiler is working.
But I'll switch it on for cpu-profiler in another patch.
BUG=chromium:452067
LOG=n
Review URL: https://codereview.chromium.org/995183005
Cr-Commit-Position: refs/heads/master@{#27224}
I did some investigation and found that in the most cases
the old schema with the separate List for functions and inlines
gives us no memory benefits because more frequently we inlines
different functions into parent function. So the plain schema
wins a tens or even hundreds bytes a few thousand times.
The only drawback is that we will print the inlined body
the each time when we inline it. But is not a problem
because it happens only under FLAG_hydrogen_track_positions.
Also I added script_id to the structure, so it could be used later
by cpu-profiler.
BUG=chromium:452067
LOG=n
Review URL: https://codereview.chromium.org/996153003
Cr-Commit-Position: refs/heads/master@{#27134}
Rationale: separate the inputs and outputs of parsing + analysis from the business of compiling (i.e. generating machine code).
BUG=
Review URL: https://codereview.chromium.org/974213002
Cr-Commit-Position: refs/heads/master@{#27078}
We mark certain builtins for inlining, and those should always be
inlined into optimized code (CrankShaft already handles it this way), so
we should support that in TurboFan as well. Currently this mainly
affects a certain set of Math functions, but once have the basics in
place we can extend this to any kind of builtin/code stub/accessor.
This adds a new flag --turbo_builtin_inlining (enabled by default), that
forces the inliner to always inline builtins marked for inlining, but
does not affect inlining of other functions (this is still controlled by
the --turbo-inlining flag).
BUG=v8:3952
LOG=n
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/993473002
Cr-Commit-Position: refs/heads/master@{#27059}
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}
Save Unknown position as zero in RelocInfo.
Remove copy constructor of SourcePosition because it is trivial.
Mechanical replace int raw_position with SourcePosition position.
BUG=452067
LOG=n
Review URL: https://codereview.chromium.org/959203002
Cr-Commit-Position: refs/heads/master@{#26916}
A function could be deoptimized due to a deopt in the inlined code.
The inlined function might be defined in another script. So we need to
track the information about the inlined functions (scriptId and offset).
We already have the tracking code which is behind FLAG_hydrogen_track_position.
So as the first step we need to make the info accessible by CPU profiler.
In the follow-up patches I'll add the code which will enable position
tracking and push the info into CodeEntry entries.
BUG=452067
LOG=n
Review URL: https://codereview.chromium.org/914413007
Cr-Commit-Position: refs/heads/master@{#26680}
Use a fake code stub instead, basically following the null object pattern.
Review URL: https://codereview.chromium.org/918973002
Cr-Commit-Position: refs/heads/master@{#26610}
Several tiny changes for the upcoming TurboFan-genrated handlers/stubs:
* Relaxed the type of code_stub().
* Made GetCodeKind() public, it effectly was like this, anyway.
* Const-corrected GetStubType().
Review URL: https://codereview.chromium.org/915583002
Cr-Commit-Position: refs/heads/master@{#26542}
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}
It doesn't do anything for now, but it implies strict mode. Added tests to
test-parsing.cc to test that.
BUG=
Review URL: https://codereview.chromium.org/898983002
Cr-Commit-Position: refs/heads/master@{#26460}
This enables adding more language modes in the future.
For maximum flexibility, LanguageMode is a bitmask, so we're not restricted to
use a sequence of language modes which are progressively stricter, but we can
express the language mode as combination of features.
For now, LanguageMode can only be "sloppy" or "strict", and there are
STATIC_ASSERTS in places which need to change when more modes are added.
LanguageMode is a bit like the old LanguageMode when "extended" mode was still
around (see https://codereview.chromium.org/8417035 and
https://codereview.chromium.org/181543002 ) except that it's transmitted through
all the layers (there's no StrictModeFlag).
BUG=
Review URL: https://codereview.chromium.org/894683003
Cr-Commit-Position: refs/heads/master@{#26419}
If a (pure) node has two or more uses, but there exists a path from the
common dominator of these uses to end, which does not contain a use,
then we split the node such that no unnecessary computation takes place.
Note however, that this only applies if the node cannot be hoisted out
of a loop.
BUG=v8:3864
LOG=n
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/899433005
Cr-Commit-Position: refs/heads/master@{#26404}
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}
The approach taken in this CL is to incrementally move toward the
currently-specced version of modules in ES6. The biggest change in this
patch is separating the parsing of modules from the parsing of scripts,
getting rid of the 'module' keyword and thus disallowing modules-in-scripts
as well as modules-in-modules.
The syntax supported by import/export declarations has not yet been significantly
changed, with the major exception being that import declarations require a string
as the 'from' part.
Most of the existing tests have been disabled, with a first new test added
in cctest/test-parsing.
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/881623002
Cr-Commit-Position: refs/heads/master@{#26299}
Along the way:
- Thread isolate parameter explicitly through code that used to
rely on getting it from the zone.
- Canonicalize the parameter position of isolate and zone for
affected code
- Change Hydrogen New<> instruction templates to automatically
pass isolate
R=mstarzinger@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/868883002
Cr-Commit-Position: refs/heads/master@{#26252}
(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
- Don't bake in length/capacity into full codegen calls of stubs,
allowing boilerplates to increase their capacity without regenerating
code.
- Unify all variants of the clone stub into a single,
length-independent version.
- Various tweaks to make sure that the clone stub doesn't spill and
therefore need an eager stack frame.
- Handle all lengths of array literals in the fast case.
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/272513004
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21230 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
Instead of tracking simple absolute offset from the start of the script like other places do, track a pair of (inlining id, offset from the start of inlined function).
This enables us to pinpoint with inlining path an instruction came from. Previously in multi-script environments we emitted positions that made very little sense because inside a single optimized function they would point to different scripts without a way to distinguish them.
Start dumping the source of every inlined function to make possible IR viewing tools with integrated source views as there was previously no way to acquire this information from IR dumps. We also dump source position at which each inlining occured.
Tracked positions are written into hydrogen.cfg as pos:<inlining-id>_<offset>.
Flag --emit-opt-code-positions is renamed by this change into --hydrogen-track-positions to better convey it's meaning.
In addition this change assigned global unique identifier to each optimization performed inside isolate. This allows to precisely match compilation artifacts (e.g. IR and disassembly) and deoptimizations.
BUG=
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/140683011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19360 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If OSR happens before regular recompilation, the unoptimized function code
on the stack may not have deoptimization support. In that case, graph
creation compiles the unoptimized code again to include support. That
code is then installed as shared code. When we patch code for OSR, the
function code on the stack and not the shared code is what we want.
R=titzer@chromium.org
TEST=block-conflicts.js with --always-osr --concurrent-osr
Review URL: https://codereview.chromium.org/99013003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18261 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change means that code which is never executed is garbage collected immediately, and code which is only executed once is collected more quickly (limiting heap growth), however, code which is re-executed is reset to the young age, thus being kept around for the same number of GC generations as currently.
BUG=280984
R=danno@chromium.org, hpayer@chromium.org
Review URL: https://codereview.chromium.org/23480031
Patch from Ross McIlroy <rmcilroy@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17343 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
InstallOptimizedCode aquires ownership on the compilation info and deletes
it on return, tearing down the attached zone. The OptimizingCompiler
object is a zone object allocated in just that zone, so it also gets
deleted. Effectively, InstallOptimizedCode cleans up when it's done, so
the OptimizingCompiler object it receives is invalidated afterwards.
R=titzer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/23769007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16609 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(),
which are broken in several ways. The ElapsedTimer class implements a
stopwatch using TimeTicks::HighResNow() for high resolution, monotonic
timing.
Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime()
methods to actually return the time relative to the unix epoch as stated
in the documentation (previously that was relative to some arbitrary
point in time, i.e. boot time).
The previous Windows issues have been resolved, and we now use GetTickCount64()
on Windows Vista and later, falling back to timeGetTime() with rollover
protection for earlier Windows versions.
BUG=v8:2853
R=machenbach@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/23490015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16413 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(),
which are broken in several ways. The ElapsedTimer class implements a
stopwatch using TimeTicks::HighResNow() for high resolution, monotonic
timing.
Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime()
methods to actually return the time relative to the unix epoch as stated
in the documentation (previously that was relative to some arbitrary
point in time, i.e. boot time).
BUG=v8:2853
R=machenbach@chromium.org
Review URL: https://codereview.chromium.org/23469013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16398 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(),
which are broken in several ways. The ElapsedTimer class implements a
stopwatch using TimeTicks::HighResNow() for high resolution, monotonic
timing.
Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime()
methods to actually return the time relative to the unix epoch as stated
in the documentation (previously that was relative to some arbitrary
point in time, i.e. boot time).
BUG=v8:2853
R=machenbach@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/23295034
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16388 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
I'd like to propagate bailout reason to cpu profiler.
So I need to save it into heap object SharedFunctionInfo.
But:
1) all bailout reason strings spread across all the sources.
2) they are native strings and if I convert them into String then I may have a performance issue.
3) one byte is enough for 184 bailout reasons. Otherwise we need 8 bytes for the pointer.
Also I think it would be nice to have error strings collected in one place.
In that case we will get additional benefits:
It allows us to keep this set of messages under control.
It gives us a chance to internationalize them.
It slightly reduces the binary footprint.
From the other hand the developers have to add new strings into that enum.
BUG=
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/20843012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16024 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
Notes:
- For now, just adds the missing type info fields to the AST nodes directly.
I'd like to factor that out more nicely in a follow-up CL.
- All type feedback now is uniformly collected through AST nodes'
RecordTypeFeedback functions. At some point, this logic should be moved
out of ast.cc.
- The typing pass currently simulates the exact same conditions under
which feedback was collected in Hydrogen before. That also should be
made more generic in the future.
- Type information itself is unchanged. Making it more regular is
yet more future work.
Some additional cleanups:
- Lifted out nested class ObjectLiteral::Property, to enable forward declaration.
- Moved around some auxiliary enums.
R=svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/14990014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14825 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Stack iterator takes return address based on the frame pointer (ebp) and detects JS frames based on value at fp + StandardFrameConstants::kMarkerOffset. So in order the iterator to work correctly this values should be already setup for the current function. Stack frame is constructed at the very beginning of JS function code and destroyed before return. If sample is taken before before the frame construction is completed or after it was destroyed the stack iterator will wrongly think that FP points at the current functions frame base and will skip callers frame. To avoid this we mark code ranges where stack frame doesn't exist and completely ignore such samples.
This fixes cctest/test-cpu-profiler/CollectCpuProfile flakiness.
BUG=v8:2628
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/14253015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14670 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
