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
