When compiling with the macro DCHECK_ALWAYS_ON defined, DCHECKs and
supporting code gets compiled and enabled.
This increases test coverage for chromium release buildbots
BUG=v8:3731
R=jkummerow@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/760213005
Cr-Commit-Position: refs/heads/master@{#25701}
This introduces Hydrogen for %_GetPrototype. The code falls back on
runtime if the object needs access checks or if its prototype is a
hidden prototype.
BUG=None
LOG=Y
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/756423006
Cr-Commit-Position: refs/heads/master@{#25694}
These methods for used for compressed libraries, where GetSource* functions
contained the compressed sources and [GS]etRawSource* the uncompressed
sources. This is dead code since the API no longer supports compression.
(If you need/want compressed sources, use the external startup data and
compress/uncompress on the Embedder's side.)
BUG=
Review URL: https://codereview.chromium.org/772853003
Cr-Commit-Position: refs/heads/master@{#25666}
Instead, make it possible for indifidual tests to pass "always true flags" which
are not part of the varying flag set.
The downside is that if an experimental flag changes parsing of some of the
unrelated code snippets, it's noticed later (only after the flag is turned on by
default). But this is a reasonable trade off for faster tests.
Additional fix: Some tests (ErrorsFutureStrictReservedWords) were using
always_flags incorrectly (running two different tests with different
always_flags basically iterates over every flag combination anyway - most of
them twice).
BUG=v8:3707
LOG=N
Review URL: https://codereview.chromium.org/772823002
Cr-Commit-Position: refs/heads/master@{#25628}
- Create a first-class Edge type.
- Separate node and edge iterators
- Make iterators only responsible for iteration
- Make it possible to modify the use edge iterator while iterating.
- Add the ability to update inputs to Edges directly.
Review URL: https://codereview.chromium.org/765983002
Cr-Commit-Position: refs/heads/master@{#25616}
This relands macroassembler instructions and weak cell caching and
does not include parts that caused "Linux ASan LSan" test failures.
BUG=v8:3663
LOG=N
Review URL: https://codereview.chromium.org/764003003
Cr-Commit-Position: refs/heads/master@{#25615}
Most of the run time came from testing with all possible flag combinations. None
of the flags passed affect the test, and there are specialized tests for testing
the features behind the flags; no need to slow down the generic test.
With these changes, run time for debug build goes from 186 s to 0.5 s.
In addition, fixed some missing commas between the test cases.
R=svenpanne@chromium.org
BUG=v8:3707
LOG=N
Review URL: https://codereview.chromium.org/766673003
Cr-Commit-Position: refs/heads/master@{#25612}
Groups and implicit references are no longer relevant at this point.
Also add tests that fail if the first or second round of ephemeral
marking is omitted
BUG=none
R=mstarzinger@chromium.org,hpayer@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/761343004
Cr-Commit-Position: refs/heads/master@{#25606}
v8::Object already has GetIdentityHash on it. This change adds its counterpart to v8::Name.
BUG=chromium:437416
LOG=Y
Review URL: https://codereview.chromium.org/753373003
Cr-Commit-Position: refs/heads/master@{#25598}
Running this in x64.release mode on a powerful HP620 takes 4 seconds,
this is at least 2 orders of magnitude too slow and leads to tons of
false positives on our build bots due to timeouts. As it is, the
cost-benefit ratio is far too low.
The whole approach needs to be changed: Instead of trying to exhaust
some search space in unit tests, this should be turned into a fuzzing
test where only a small but random number of things are tested. The
exhaustive approach can be done separately, but definitely not in the
unit tests.
BUG=v8:3707
Review URL: https://codereview.chromium.org/762743002
Cr-Commit-Position: refs/heads/master@{#25510}
cctest/test-threads/ThreadJoinSelf is suppressed for Android, but the
test has since been moved to unittests/Thread.SelfJoin. Move the
suppression to unittests.status.
unittests/ThreadLocalStorageTest.DoTest fails on older Android devices
as it assumes the availability of more TLS slots than many devices
implement. Test a smaller number of slots (32) on Android. Remove old
suppression of test-platform-tls/FastTLS (which no longer exists).
cctest/test-mark-compact/RegressJoinThreadsOnIsolateDeinit can't deal
with shared mappings. Check for 's' instead of '-'.
BUG=v8:3706
LOG=
Review URL: https://codereview.chromium.org/735863003
Cr-Commit-Position: refs/heads/master@{#25492}
If we run out of code range, then GC wouldn't be able to compact code space,
because it wouldn't be able to allocate a new page. This can cause code space
fragmentation and OOM crashes.
BUG=chromium:430118
LOG=Y
Review URL: https://codereview.chromium.org/742733002
Cr-Commit-Position: refs/heads/master@{#25441}
JavaScript shifts perform an implicit '& 0x1F' on their right operand, this
patch removes it when the underlying architecture already does it.
BUG=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/732103002
Cr-Commit-Position: refs/heads/master@{#25438}
Since checking all possible combinations is taking so long this
reduces the test to test the odd cases (let, yield and static) as
well as a single ordinary case.
BUG=v8:3707
LOG=n
Review URL: https://codereview.chromium.org/724713004
Cr-Commit-Position: refs/heads/master@{#25428}
Skip one hard fail, and two frequent flakes while we investigate.
BUG=
NOTRY=true
Review URL: https://codereview.chromium.org/728653004
Cr-Commit-Position: refs/heads/master@{#25418}
This essentially performs the following transformation
JSToNumber(phi(x1,...,xn,control):primitive)
=> phi(JSToNumber(x1),...,JSToNumber(xn),control):number
which is similar to what we already do for JSToBoolean.
TEST=mjsunit/asm
R=svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/732463003
Cr-Commit-Position: refs/heads/master@{#25390}
We add a new ScopeType, ScopeType.Script. The scope with
ScopeType.Script is always present in the scope chain (ScopeIterator
fakes it if neededi - i.e. if ScriptContext for a script has not been
allocated since that script has no lexical declarations).
ScriptScope reflects ScriptContextTable.
R=yurys@chromium.org,yangguo@chromium.org
BUG=v8:3690
LOG=N
Review URL: https://codereview.chromium.org/726643002
Cr-Commit-Position: refs/heads/master@{#25383}
Don't use the generic algorithm, but instead start going into the
direction of ControlReducer, using a stack plus a revisit queue to
not miss any more possibilities for reductions anymore.
TEST=cctest,unittests
R=dcarney@chromium.org
Committed: f047507370
Committed: 6e148989a4
Review URL: https://codereview.chromium.org/726513002
Cr-Commit-Position: refs/heads/master@{#25377}
With Int32Add we lose the int/uint distinction, so later, in simplified lowering we can make a wrong decision. E.g., see the attached test case, where we lower NumberAdd -> Int32Add because inputs are Uint32, but during simplified lowering we change the inputs to Int32, so we get a wrong result.
Simplified lowering will lower the NumberAdd operations anyway, so we should lose performance.
BUG=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/721723004
Cr-Commit-Position: refs/heads/master@{#25368}
Don't use the generic algorithm, but instead start going into the
direction of ControlReducer, using a stack plus a revisit queue to
not miss any more possibilities for reductions anymore.
TEST=cctest,unittests
R=dcarney@chromium.org
Committed: f047507370
Review URL: https://codereview.chromium.org/726513002
Cr-Commit-Position: refs/heads/master@{#25345}
Revert "Fix for an assertion failure in Map::FindTransitionToField(...). Appeared after r25136."
This revert is made in order to revert r25099 which potentially causes renderer hangs.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/722873004
Cr-Commit-Position: refs/heads/master@{#25332}
Don't use the generic algorithm, but instead start going into the
direction of ControlReducer, using a stack plus a revisit queue to
not miss any more possibilities for reductions anymore.
TEST=cctest,unittests
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/726513002
Cr-Commit-Position: refs/heads/master@{#25326}
There's no need to apply the 0x1f mask to right hand sides of shifts if
the input is already in range [0,31].
TEST=cctest,unittests
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/718193003
Cr-Commit-Position: refs/heads/master@{#25313}
Lowering of NumberToUint32 and NumberToInt32 was not correctly accounting for the sign of the input and the sign of the output, emitting the wrong representation changes.
Along the way, I've found cases where MachineOperatorBuilder would break if fed a machine type for loads or stores that was not cached, requiring MachineOperatorBuilder to take zone to allocate operators for these cases.
R=bmeurer@chromium.org, jarin@chromium.org
BUG=
Review URL: https://codereview.chromium.org/714613002
Cr-Commit-Position: refs/heads/master@{#25247}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25247 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implements correct semantics for "extensible" top level lexical scope.
The entire lexical scope is represented at runtime by GlobalContextTable, reachable from native context and accumulating global contexts from every script loaded into the context.
When the new script starts executing, it does the following validation:
- checks the GlobalContextTable and global object (non-configurable own) properties against the set of declarations it introduces and reports potential conflicts.
- invalidates the conflicting PropertyCells on global object, so that any code depending on them will miss/deopt causing any contextual lookups to be reexecuted under the new bindings
- adds the lexical bindings it introduces to the GlobalContextTable
Loads and stores for contextual lookups are modified so that they check the GlobalContextTable before looking up properties on global object, thus implementing the shadowing of global object properties by lexical declarations.
R=adamk@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/705663004
Cr-Commit-Position: refs/heads/master@{#25220}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The spec explicitly forbids them. V8 never handled them properly either, just
the Scanner accepted them (it had code to add them literally to the
LiteralBuffer) and later on, Regexp constructor disallowed them.
According to the spec, unicode escapes in regexp flags should be an early error
("It is a Syntax Error if IdentifierPart contains a Unicode escape sequence.").
Note that Scanner is still more relaxed about regexp flags than the
spec. Especially, it accepts any identifier parts (not just a small set of
letters) and doesn't check for duplicates.
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/700373003
Cr-Commit-Position: refs/heads/master@{#25215}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25215 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
Not clearing can lead to a crash under following conditions:
1. Backing store of a weak map is allocated in large object space.
2. The backing store is marked incrementaly via the weak map.
3. The weak map is updated and gets a new backing store.
4. The store buffer overflows and marks the chunk of the old backing store as
"scan on scavenge."
5. Mark-compact collection kills some elements of the weak map. Note that the
old backing store survives because it was marked incrementally, but its dead
elements are not cleared.
6. Scavenger iterates over the old backing store, tries to move a dead object
and crashes.
BUG=v8:3631
LOG=N
TEST=cctest/test-heap/Regress3631
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/686783003
Cr-Commit-Position: refs/heads/master@{#25032}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25032 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This simplifies escape handling and makes it easier to extend escapes for ES6.
PushBack just before detecting ILLEGAL is unnecessary, since we will abort the
scanning / parsing anyway at that point, and it doesn't matter where the cursor
exactly is. The error messages w/ PushBack are not any better or more correct
than without.
In addition: remove a comment about handling invalid escapes gracefully when we
no longer do. (*)
This CL includes a behavioral change: For input "var r = /foobar/g\urrrr;" we
used to report "unexpected_token: ILLEGAL" for "\u", but now we report
malformed_regexp_flags which is a more correct error message. (Note that the
code for reporting invalid_regexp_flags was dead, and invalid_regexp_flags is
not the right error message.)
Note that the V8 is more relaxed about unicode escapes in regexp flags than ES6
(see
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-regular-expressions )
and this CL doesn't change it. (V8 accepts any \uxxxx, ES6 spec says only a
certain value range is acceptable.)
(*) Code archaeology:
Originally, doing PushBack in ScanHexEscape made sense (see e.g., here
https://codereview.chromium.org/5063003/diff/6001/src/prescanner.h ), since we
wouldn't return ILLEGAL but treat an invalid escape sequence "\uxxxx" as
"uxxxx".
(The repo at that point contains another instance of the same function, from the
initial commit. The logic is the same.)
This behavior was changed in a "renaming" commit
https://codereview.chromium.org/7739020.
BUG=
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/684873002
Cr-Commit-Position: refs/heads/master@{#25031}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25031 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This analysis computes the set of variables that are assigned in each loop. This is useful to avoid creating redundant loop phis when building an SSA graph, which just waste memory and require analysis to get rid of.
This CL implements an AST walk for the analysis and plugs the result into the TurboFan graph builder. I left this analysis under a flag for A/B testing and until sufficient unit tests can be developed.
R=danno@chromium.org, mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/656123005
Cr-Commit-Position: refs/heads/master@{#24957}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24957 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
A FeedbackNexus is the combination of a feedback vector, a slot(s) in
the vector, along with methods to query and manipulate that information
in a type-correct way.
A CallIC will have a CallICNexus, a LoadIC a LoadICNexus, etc.,
reflecting the fact that different types of ICs configure their data
in unique ways.
This CL limits itself to introducing and using the nexus type only for
CallICs. A follow-up will use them for Load and KeyedLoadICs for the
case when the --vector-ics flag is turned on.
The notion of a Nexus is also embedded at the lowest level of the IC
class. This makes sense because more ICs should become vector-based
in the future.
R=ishell@chromium.org
Review URL: https://codereview.chromium.org/683933002
Cr-Commit-Position: refs/heads/master@{#24952}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24952 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
A FeedbackNexus is the combination of a feedback vector, a slot(s) in
the vector, along with methods to query and manipulate that information
in a type-correct way.
A CallIC will have a CallICNexus, a LoadIC a LoadICNexus, etc.,
reflecting the fact that different types of ICs configure their data
in unique ways.
This CL limits itself to introducing and using the nexus type only for
CallICs. A follow-up will use them for Load and KeyedLoadICs for the
case when the --vector-ics flag is turned on.
The notion of a Nexus is also embedded at the lowest level of the IC
class. This makes sense because more ICs should become vector-based
in the future.
This CL is based on https://codereview.chromium.org/679073002/ which
should land first.
BUG=
R=ishell@chromium.org
Review URL: https://codereview.chromium.org/680883004
Cr-Commit-Position: refs/heads/master@{#24945}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24945 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
ES6 no longer makes duplicate properties an error. However, we
continue to treat duplicate properties in strict mode object
literals as errors. With this change we allow duplicate properties
in class bodies. We continue to flag duplicate constructors as an
error as required by ES6.
BUG=v8:3570
LOG=Y
R=marja@chromium.org
Review URL: https://codereview.chromium.org/677953004
Cr-Commit-Position: refs/heads/master@{#24933}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24933 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Allow reservation of additional input capacity when creating nodes to prevent switching to deque representation when adding well-known additional inputs.
Also ensure that only a single temporary buffer is used to create temporary input arrays before allocating nodes.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/644083003
Cr-Commit-Position: refs/heads/master@{#24896}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24896 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Each time a transition is added to a hidden class, the whole
transitions array must be copied, which causes poor performance
in some circumstances. This change limits the maximum size of
the transition array, avoiding this behavior in the pathological
case. For example, this improves the performance of the EtchMark
benchmark by nearly 60%.
BUG=v8:3616
LOG=
R=verwaest@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/635883003
Patch from Kevin M. McCormick <mckev@amazon.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24857 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Branch can now have an optional hint, when the condition is
likely true or false, and if such a hint is present the other
basic block will be marked as deferred and placed at the end
of the function.
We currently use this feature for tagging int32/uint32 in
change lowering, and for load/store bounds checks in simplified
lowering.
TEST=cctest,unittests
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/642883003
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24802 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Updates Object.prototype.toString() to use algorithm described in harmony drafts.
Currently, the behaviour is essentially the same as ES262's version, however this changes when internal structures
such as Promise make use of symbolToStringTag (as they are supposed to, see v8:3241), and changes further once
Symbol.toStringTag is exposed publicly.
BUG=v8:3241, v8:3502
LOG=N
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/546803003
Patch from Caitlin Potter <caitpotter88@gmail.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24783 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
1) Since we fill the output buffer both from the chunks and the conversion
buffer, it's possible that we run out of space and call CopyCharsHelper with 0
length. The underlying functions don't handle it gracefully, so check there.
2) There was a bug where we used to try to copy too many characters from the
beginning of the data chunk into the conversion buffer. Continuation bytes in
UTF-8 are of the form 0b10XXXXXX. If a byte is bigger than that, it's the first
byte of a new UTF-8 character and we should ignore it.
These two together (or maybe in combination with surrogates) are a probable
reason for crbug.com/420932.
3) The test data was off; \uc481 is \xec\x92\x81.
BUG=420932
LOG=N
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/662003003
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24725 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Trimming the graph consists of breaking links from nodes that are not reachable from end to nodes that are reachable from end. Such dead nodes show up in the use lists of the live nodes and though mostly harmless, just clutter up the graph. They also can limit instruction selection opportunities, so it is good to get rid of them.
This CL is one half of the ControlReducer functionality, the other half
being branch folding.
R=bmeurer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/661923002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24694 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This adds flags in Scope to track wheter a Scope uses "this" and,
"arguments". The information is exposed via Scope::uses_this(),
and Scope::uses_arguments(), respectively. Flags for tracking
usage on any inner scope uses are available as well via
Scope::inner_uses_this(), and Scope::inner_uses_arguments().
Knowing whether scopes use "this" and "arguments" will be handy
to generate the code needed to capture their values when generating
the code for arrow functions.
BUG=v8:2700
LOG=
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/422923004
Patch from Adrian Perez de Castro <aperez@igalia.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24663 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Extend verifier to check types of JS and Simplified nodes.
- Untyped nodes now contain NULL as types, enforcing hard failure.
- Typer immediately installs itself as a decorator; remove explicit decorator installation.
- Decorator eagerly types all nodes that have typed inputs
(subsumes typing of constant cache, removing its typing
side-channel and various spurious dependencies on the typer).
- Cut down typer interface to prevent inconsistently typed graphs.
- Remove verification from start, since it caused too much trouble
with semi-wellformed nodes.
- Fix a couple of bugs on the way that got uncovered.
To do: verifying machine operators. Also, various conditions in the
verifier are currently commented out, because they don't yet hold.
BUG=
R=jarin@chromium.org,titzer@chromium.org
Review URL: https://codereview.chromium.org/658543002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24626 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The scheduler rewires control based on the last *control*
node that appears in the schedule of a block. This is not
sufficient to account for dependencies.
This patch adds additional dependencies to floating control
nodes. Given a floating control node A, every non-control
dependency of every node B that depends on A is introduces
as an additional dependency of A.
This allows the scheduler to correctly schedule two
diamonds A, B, if their only correct schedule is to
schedule B into the ifTrue successor in A.
TEST=cctest/test-scheduler/NestedFloatingDiamonds
R=mstarzinger@chromium.org, titzer@chromium.org
Review URL: https://codereview.chromium.org/602083003
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24561 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The problem was that there can be several multi-byte UTF-8 characters near the
splitting point of the data chunks, and the code didn't handle it properly.
This was also the source of crbug.com/417891 - I thought the crash can only
happen when V8 is passed invalid UTF-8 data, but it can also happen in the
abovementioned case. After the fix, we handle the valid UTF-8 case and also
guard against invalid UTF-8 data.
R=yangguo@chromium.org
BUG=chromium:417891
LOG=N
Review URL: https://codereview.chromium.org/654503002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24547 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The StaticParameterTraits are broken by design, and cause way too much
trouble. The compilers usually pick the wrong specialization (i.e. the
default specialization is picked for Load and Phi even tho there is a
specialization for MachineType), which is not only the reason why GVN is
ineffective and slow, but can also lead to correctness issues in some
rare cases.
Also clean up some minor bugs/inconsistencies on the way.
TEST=cctest,unittests
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/636893002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24437 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
On platforms without TurboFan (PowerPC) the CompareWrapper test was
failing. It appears the line
RawMachineAssemblerTester<int32_t> m;
was causing the issue, and does not appear to be required for the
test to operate correctly. Removing it resolves the crash on non
TurboFan platforms
BUG=
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/618043002
Patch from Andrew Low <andrew_low@ca.ibm.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24424 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Reason for revert:
It broke layout test fast/events/window-onerror-02.html, error column reported by window.onerror is now wrong (I believe it is because of the change in full-codegen):
http://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2064%20%28dbg%29/builds/652
Original issue's description:
> Extend CPU profiler with mapping ticks to source lines
>
> The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
> 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>
> BUG=None
> LOG=Y
> R=svenpanne@chromium.org
>
> Committed: https://code.google.com/p/v8/source/detail?r=24389TBR=svenpanne@chromium.org,danno@chromium.org,alph@chromium.org,denis.pravdin@intel.com,weiliang.lin@intel.com
BUG=None
LOG=N
Review URL: https://codereview.chromium.org/624443005
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24394 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
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>
BUG=None
LOG=Y
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/616963005
Patch from Denis Pravdin <denis.pravdin@intel.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24389 ce2b1a6d-e550-0410-aec6-3dcde31c8c00