RegExpCompileEvent acquieres mutex from Log class during MessageBuilder creation. LogRegExpSource, called from RegExpCompileEvent creates another MessageBuilder object which also acquires the same mutex. This mutex is not recursive, so during second acquirement, assertion fail is happening. Solution: LogRegExpSource should use the same MessageBuilder object as RegExpCompileEvent.
Review URL: https://codereview.chromium.org/1207433002
Cr-Commit-Position: refs/heads/master@{#29347}
Report builtins by name (e.g. "Builtin:ArgumentsAdaptorTrampoline")
instead of labeling everything "Builtin:A builtin from the snapshot".
BUG=
Review URL: https://codereview.chromium.org/1216833002
Cr-Commit-Position: refs/heads/master@{#29339}
When compiling on a laptop I like to concatenate the small test files.
This makes a big difference to compile times. These changes make that
easier.
R=ulan@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1163803002
Cr-Commit-Position: refs/heads/master@{#28742}
This flag mostly duplicates SharedFunctionInfo::optimization_disabled
and is only queried in places where the original is available. Remove
the brittle and error-prone duplication.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1148043002
Cr-Commit-Position: refs/heads/master@{#28520}
We want to move to a world where there's no Isolate::Current but we
always knows which isolate we're in. There's no way we can teach this
info to the C++ allocator.
BUG=none
R=hpayer@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1128023005
Cr-Commit-Position: refs/heads/master@{#28414}
The original code always returned the first entry from RelocInfo that matched with
bailout_id. But we may have a few different deopt reasons for one bailout_id.
So we need to get the one which matches with a particular call from JumpTable.
We can do this by checking not 'target_address' (it maps to bailout_id)
but 'from' address which maps to a particular JumpTable entry.
The test was reworked so it tests identical functions against different reasons.
BUG=chromium:452067
LOG=n
Review URL: https://codereview.chromium.org/984773003
Cr-Commit-Position: refs/heads/master@{#27076}
Problem:
Excuting with flags as "--prof --logfile-per-isolate --logfile=/path/to/filename"
expected file name: /path/to/isolate-<isolate id>-filename
current result: isolate-<isolate id>-/path/to/filename
This patch makes the file name we expected.
Review URL: https://codereview.chromium.org/960813004
Cr-Commit-Position: refs/heads/master@{#26955}
We accessed to cpu_profiler for tracking SharedFunctionInfo objects movements and used their addresses for generating function_id. Actually we could replace the manually generated shared_id by the pair script_id + position. In this case we can drop SharedFunctionInfo events support from cpu_profiler and remove the dependency.
BTW GetCallUid was used as an unique identifier of the function on the front-end side. Actually it is a hash which might not be unique. So I renamed GetCallUid with GetHash and implemented GetFunctionId method.
BUG=452067
LOG=n
Review URL: https://codereview.chromium.org/941973002
Cr-Commit-Position: refs/heads/master@{#26775}
1) Deoptimizer::Reason was replaced with Deoptimizer::DeoptInfo
because it also has raw position. Also the old name clashes with DeoptReason enum.
2) c_entry_fp assignment call was added to EntryGenerator::Generate
So we can calculate sp and have a chance to record the stack for the deopting function.
btw it makes the test stable.
3) new kind of CodeEvents was added to cpu-profiler
4) GetDeoptInfo method was extracted from PrintDeoptLocation.
So it could be reused in cpu profiler.
BUG=452067
LOG=n
Review URL: https://codereview.chromium.org/910773002
Cr-Commit-Position: refs/heads/master@{#26545}
(1) --prof-cpp: Collects ticks like --prof, but ignores code creation events to reduce distortion (so all JS ticks will be "unaccounted"). Useful for profiling C++ code.
(2) --timed-range flag for tick processor: Ignores ticks before the first and after the last call to Date.now(). Useful for focusing on the timed section of a test.
Review URL: https://codereview.chromium.org/802333002
Cr-Commit-Position: refs/heads/master@{#26168}
During https://code.google.com/p/v8/source/detail?r=19925 checkin context bound scripts (Script)
and context unbound scripts (UnboundScript) are Distinguished.
And then Sven Panne helped to fix the vtune support compilation
error in https://code.google.com/p/v8/source/detail?r=20955.
The problem is that there is runtime error for vtune
support.
In our original implementation, we encapsulated and passed v8::internal::Script
to V8 API. It will leads to type check error for current V8::Script definition.
So I changed the Handle<Script> definition in JitCodeEvent
to Handle<UnboundScript>
and add the corresponding change in log.cc.
If you do NOT prefer to change in include/v8.h. I think I can change the definition of
CodeEventLogger::LogRecordedBuffer(...) so that the we can pass the correct
type (JSFunction) as V8::Script to V8 API.
BUG=
R=danno@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/334263018
Patch from Chunyang Dai <chunyang.dai@intel.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22393 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This adds timestamps to allow profiling with code space reuse. Also a couple of updates to reflect the changes in the JIT perf interface + a move of the perf-related stuff into separate files.
Unfortunately, the change only works with the latest patch to the perf tool from a Linux perf tool contributor (Stephane Eranian).
BUG=
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/255803003
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22098 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
