During generation code and relocation info are generated simultaneously.
When code generation is done you each code object has associated "relocation info".
Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
correspondences between the machine program counter and source locations for stack walking.
This patch:
1. Add more source positions info in reloc info to make it suitable for source level mapping.
The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
(2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
If a source line is found that hit counter is increased by one for this line.
3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
4.Add a test that checks how the samples are distributed through source lines.
It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
Patch from Denis Pravdin <denis.pravdin@intel.com>;
R=svenpanne@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/682143003
Patch from Weiliang <weiliang.lin@intel.com>.
Cr-Commit-Position: refs/heads/master@{#25182}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25182 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The bug has always been there: when the parser is operating in the "immediately
internalize" mode and calls GetString, we get FlatContent of a string and then
do heap allocation.
The bug was uncovered by https://codereview.chromium.org/693803004/ (which put
the parser to the "immediately internalize" mode more often), but looking at the
code, it's possible that it can happen in other cases too.
This CL makes AstValueFactory handle this situation gracefully: it won't try to
internalize inside GetString(Handle<String>); it's unnecessary anyway since we
have the Handle<String> already.
BUG=
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/706533005
Cr-Commit-Position: refs/heads/master@{#25179}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25179 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Emscripten requires little-endian arch. It has assertion for endianness:
assert(HEAPU8[0] === 255 && HEAPU8[3] === 0,
'Typed arrays 2 must be run on a little-endian system');
TEST=mjsunit/asm/embenchen/*
BUG=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/708663003
Patch from Paul Lind <paul.lind@imgtec.com>.
Cr-Commit-Position: refs/heads/master@{#25177}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25177 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The bug has always been there: when the parser is operating in the "immediately
internalize" mode and calls GetString, we get FlatContent of a string and then
do heap allocation.
The bug was uncovered by https://codereview.chromium.org/693803004/ (which put
the parser to the "immediately internalize" mode more often), but looking at the
code, it's possible that it can happen in other cases too.
This CL makes AstValueFactory handle this situation gracefully: it won't try to
internalize inside GetString(Handle<String>); it's unnecessary anyway since we
have the Handle<String> already.
R=rossberg@chromium.org
BUG=
Review URL: https://codereview.chromium.org/699343004
Cr-Commit-Position: refs/heads/master@{#25155}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25155 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The bad scenario this fix handles:
We have a slot in a free list, then promote the object pointed-to by
the slot during scavenge. When allocating the space for the promoted
object, we overwrite the slot with the free list entry map if the
object is allocated just before the slot. After the allocation,
ScavengingVisitor::PromoteObject overwrites the slot with the
address of the allocated object, thus corrupting the free list.
Unfortunately, we do not have a way to construct a reliable repro
case because we would need to somehow craft a free list and store
buffer slot to be in the right configuration.
R=hpayer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/695213004
Cr-Commit-Position: refs/heads/master@{#25143}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25143 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This contains the following changes squashed together:
- Switch BasicBlock::loop_end to be a basic block instead of an RPO.
- Switch ScheduleLate to use dominator depth instead of RPO.
- Switch ScheduleEarly to use dominator depth instead of RPO.
- Push out absolute RPO ordering everywhere else in the scheduler.
- Keep linked list of blocks in RPO order while scheduling.
- Switch from RPO number to depth for dominator calculation.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/696363002
Cr-Commit-Position: refs/heads/master@{#25138}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25138 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The default double precision control of FPU is extended double-precision.
While the number definition for JavaScript is double-precision. We use
the FPU control word to set the doulbe precision and replace the original
solution which store the data to memory and load it again.
This patch also fixes the error that Sunspider 1.0.2 can not run with V8 if
sse2 support is disabled.
BUG=
R=weiliang.lin@intel.com
Review URL: https://codereview.chromium.org/700053003
Patch from Chunyang Dai <chunyang.dai@intel.com>.
Cr-Commit-Position: refs/heads/master@{#25125}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25125 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
