- 06 Feb, 2014 18 commits
-
-
verwaest@chromium.org authored
R=dslomov@chromium.org Review URL: https://codereview.chromium.org/153743005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19152 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
jarin@chromium.org authored
I have also cleaned up HOptimizedGraphBuilder::GenerateCallFunction to use IfBuilder. R=jkummerow@chromium.org BUG= Review URL: https://codereview.chromium.org/131343013 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19151 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
R=hpayer@chromium.org Review URL: https://codereview.chromium.org/153563006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19150 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
svenpanne@chromium.org authored
Ownership in this part is still very convoluted and should probably be cleaned up, this is only the minimal CL needed to fix the leak. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/153623009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19148 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
This reverts r19140. Reason: Octane regression. BUG= TBR=verwaest@chromium.org Review URL: https://codereview.chromium.org/156673002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19147 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
hpayer@chromium.org authored
BUG= R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/153863005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19144 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
dcarney@chromium.org authored
R=verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/156623002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19142 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
hpayer@chromium.org authored
BUG= R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/153273003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19141 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
It is only needed in (Pre)Parser::ParseExpressionOrLabelledStatement for not recognizing parenthesized identifiers as labels and in (Pre)Parser::ParseSourceElements for not recognizing a parenthesized string as directive prologue. Parser Expressions don't keep track of whether they're parenthesized, so PreParser Expressions shouldn't either. In addition, add helper funcs for checking if an Expression is identifier or a given identifier. (PreParser Expressions can do this.) BUG=3126 LOG=N R=ulan@chromium.org Review URL: https://codereview.chromium.org/150103004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19140 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
svenpanne@chromium.org authored
The exports_ hash map itself should live in the zone, too, not only its entries. R=rossberg@chromium.org Review URL: https://codereview.chromium.org/156643002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19138 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
There's only one error message for "eval" and "arguments", so no need to pass it to PreParser::StrictModeIdentifierViolation. BUG=3126 LOG=N R=ulan@chromium.org Review URL: https://codereview.chromium.org/139713005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19137 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
R=hpayer@chromium.org Review URL: https://codereview.chromium.org/153533003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19135 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
jarin@chromium.org authored
R=jkummerow@chromium.org BUG= Review URL: https://codereview.chromium.org/132453009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19132 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
dcarney@chromium.org authored
R=verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/155913002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19129 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
svenpanne@chromium.org authored
Bumped an assembler buffer on the way, it is necessary for some combinations of debugging flags. Note that the allocation profiler still leaks, this is handled in a separate CL. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/152643006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19128 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
svenpanne@chromium.org authored
R=yangguo@chromium.org, yurys@chromium.org Review URL: https://codereview.chromium.org/155513004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19127 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
plind44@gmail.com authored
This resolves many mjsunit failures if long branches are forced to be emitted. TEST= BUG= R=plind44@gmail.com Review URL: https://codereview.chromium.org/153983002 Patch from Dusan Milosavljevic <Dusan.Milosavljevic@rt-rk.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19126 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
machenbach@chromium.org authored
R=jkummerow@chromium.org TBR=jkummerow@chromium.org Review URL: https://codereview.chromium.org/152483005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19123 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Feb, 2014 19 commits
-
-
palfia@homejinni.com authored
Port r19095 (caf48ad) Original commit message: Objects can actually be stored into themselves. This fails when no write barrier is needed (eg, the object was just allocated). BUG= R=plind44@gmail.com Review URL: https://codereview.chromium.org/149343003 Patch from Balazs Kilvady <kilvadyb@homejinni.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19122 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
plind44@gmail.com authored
The call to C++ function has to be done through t9 register for the position independent code. The crashes occur only for shared library build. TEST=cctest/test-api/SetFunctionEntryHook BUG= R=plind44@gmail.com Review URL: https://codereview.chromium.org/132113009 Patch from Dusan Milosavljevic <Dusan.Milosavljevic@rt-rk.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19121 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
plind44@gmail.com authored
Due to a different NaN representation on MIPS, the canonical nan constant embedded in generated code that comes from snapshot will differ from the one used on MIPS hardware. TEST=mozilla/ecma/Array/15.4.4.2.js BUG= R=plind44@gmail.com Review URL: https://codereview.chromium.org/150663009 Patch from Dusan Milosavljevic <Dusan.Milosavljevic@rt-rk.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19118 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
hpayer@chromium.org authored
BUG= R=danno@chromium.org Review URL: https://codereview.chromium.org/149573014 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19115 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
We used to have error messages which provide context, like "Variable name may not be eval or arguments in strict mode", but for other illegal words we only have non-context specific error messages like "Unexpected reserved word". Providing the context makes the code unnecessarily complex, since every individual place must remember to check for eval or arguments. This CL produces a unified error message ("Unexpected eval or arguments in strict mode"), and puts the error reporting to (Pre)Parser::ParseIdentifier. Notes: - The module feature is so experimental, that I decided to not allow "eval" or "arguments" as module-related identifiers in the strict mode (even though this check wasn't there before). - Unfortunately, there were some inconsistencies, since it was the responsibility of the caller of ParseIdentifier to check "eval" and "arguments" and some places didn't have the check for no good reason. This CL is supposed to keep backward compatibility and *not* introduce any new errors. - ECMA allows "eval" and "arguments" as labels even in strict mode. (Syntax: "LabelledStatement: Identifier : Statement", and no strict mode restrictions on Identifier are listed.) - Tests which compare error message strings will fail, and need to be updated. BUG=3126 LOG=N R=ulan@chromium.org Review URL: https://codereview.chromium.org/152813005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19112 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
dcarney@chromium.org authored
R=verwaest@chromium.org BUG= Review URL: https://codereview.chromium.org/146023004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19110 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
BUG= R=dcarney@chromium.org Review URL: https://codereview.chromium.org/149803007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19109 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
R=dcarney@chromium.org Review URL: https://codereview.chromium.org/137263021 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19108 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
We need a way to assert that for a given source code snippet, an error *is* produced or *is not* produced. Otherwise we might accidentally create new errors or start accepting code which was previously not accepted. Just checking that Parser and PreParser produce the same result doesn't cut it. BUG=3126 LOG=N R=ulan@chromium.org Review URL: https://codereview.chromium.org/154243005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19107 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
R=dcarney@chromium.org Review URL: https://codereview.chromium.org/150573010 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19106 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
ishell@chromium.org authored
R=verwaest@chromium.org Review URL: https://codereview.chromium.org/149093011 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19105 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
ishell@chromium.org authored
Check elimination improvement: propagation of state through phis is supported, CheckMap narrowing implemented. R=titzer@chromium.org Review URL: https://codereview.chromium.org/141653009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19102 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
If a function is marked or queued for concurrent compilation, %OptimizeFunctionOnNextCall becomes a no-op. That can be wrong if concurrent recompilation does not complete at the time we expect the function to have been optimized. R=hpayer@chromium.org Review URL: https://codereview.chromium.org/151343006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19100 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
To avoid race with e.g. StackGuard::RequestInstallCode called from another thread when both access postpone_interrupts_nesting_. R=mvstanton@chromium.org BUG=290964 LOG=N Review URL: https://codereview.chromium.org/138833006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19099 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
Objects can actually be stored into themselves. This fails when no write barrier is needed (eg, the object was just allocated). R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/148733005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19095 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
R=ishell@chromium.org Review URL: https://codereview.chromium.org/150663005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19094 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
This is what I think is a better solution to the "external strings in old pointer space" problem. Basically, it is an issue because GC scans all fields of objects in old pointer space and if the cached address of the backing store is unaligned, it looks like a heap object, boom. The solution here is to use short external strings when we externalize a string in old pointer space, and when the address is unaligned. Short external strings don't cache the address, so GC has no issues. BUG=268686 LOG=Y R=dcarney@chromium.org Review URL: https://codereview.chromium.org/146183006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19093 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
BUG=3126 LOG=N R=ulan@chromium.org Review URL: https://codereview.chromium.org/154133002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19092 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
machenbach@chromium.org authored
R=jkummerow@chromium.org TBR=jkummerow@chromium.org Review URL: https://codereview.chromium.org/153973003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19087 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Feb, 2014 3 commits
-
-
verwaest@chromium.org authored
TBR=dcarney@chromium.org Review URL: https://codereview.chromium.org/154873002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19086 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
BUG= R=dcarney@chromium.org Review URL: https://codereview.chromium.org/153933002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19085 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
rafaelw@chromium.org authored
R=rossberg@chromium.org, rossberg BUG= Review URL: https://codereview.chromium.org/131413008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19084 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-