Reviewers: Søren Gjesse,
Description:
Revert revision 593. This was a cleanup change but it caused layout
test regressions.
Please review this at http://codereview.chromium.org/8827
SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/
Affected files:
M src/execution.cc
M
Author: [EMAIL PROTECTED]
Date: Tue Oct 28 00:30:10 2008
New Revision: 615
Modified:
branches/bleeding_edge/src/execution.cc
branches/bleeding_edge/src/top.cc
branches/bleeding_edge/src/top.h
Log:
Revert revision 593. This was a cleanup change but it caused layout
test regressions.
LGTM
http://codereview.chromium.org/8827
--~--~-~--~~~---~--~~
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
-~--~~~~--~~--~--~---
Reviewers: Mads Ager,
Description:
Work around issue 131 by checking for empty handles
in a few places.
Please review this at http://codereview.chromium.org/8828
SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/
Affected files:
M src/api.cc
M src/top.cc
Index: src/
LGTM
On Tue, Oct 28, 2008 at 9:26 AM, <[EMAIL PROTECTED]> wrote:
> Reviewers: Mads Ager,
>
> Description:
> Work around issue 131 by checking for empty handles
> in a few places.
>
> Please review this at http://codereview.chromium.org/8828
>
> SVN Base: http://v8.googlecode.com/svn/branches/ble
Author: [EMAIL PROTECTED]
Date: Tue Oct 28 01:29:23 2008
New Revision: 616
Modified:
branches/bleeding_edge/src/api.cc
branches/bleeding_edge/src/top.cc
Log:
Work around issue 131 by checking for empty handles
in a few places.
Review URL: http://codereview.chromium.org/8828
Modified: br
Reviewers: Mads Ager,
Description:
Get ready for pushing version 0.4.1 to trunk.
Please review this at http://codereview.chromium.org/8829
SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/
Affected files:
M ChangeLog
M src/api.cc
Index: src/api.cc
=
LGTM!
On Tue, Oct 28, 2008 at 9:39 AM, <[EMAIL PROTECTED]> wrote:
> Reviewers: Mads Ager,
>
> Description:
> Get ready for pushing version 0.4.1 to trunk.
>
> Please review this at http://codereview.chromium.org/8829
>
> SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/
>
> Affected
Issue 131: Crash at bluefly.com in api.cc, ThrowException
http://code.google.com/p/v8/issues/detail?id=131
Comment #1 by [EMAIL PROTECTED]:
Fixed on bleeding_edge branch in revision 616.
Issue attribute updates:
Status: Fixed
Cc: [EMAIL PROTECTED] [EMAIL PROTECTED]
--
You rece
Author: [EMAIL PROTECTED]
Date: Tue Oct 28 01:42:47 2008
New Revision: 617
Modified:
branches/bleeding_edge/ChangeLog
branches/bleeding_edge/src/api.cc
Log:
Get ready for pushing version 0.4.1 to trunk.
Review URL: http://codereview.chromium.org/8829
Modified: branches/bleeding_edge/Cha
Reviewers: Mads Ager,
Description:
Merge in changes from version 0.4.1 to 0.3.7.
Please review this at http://codereview.chromium.org/8653
SVN Base: http://v8.googlecode.com/svn/branches/0.3/
Affected files:
M src/api.cc
M src/builtins.h
M src/builtins.cc
M src/code
Rubber-stamp LGTM
http://codereview.chromium.org/8653
--~--~-~--~~~---~--~~
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
-~--~~~~--~~--~--~---
Author: [EMAIL PROTECTED]
Date: Tue Oct 28 01:56:02 2008
New Revision: 619
Added:
branches/0.3/test/mjsunit/string-compare-alignment.js
- copied unchanged from r611,
/branches/bleeding_edge/test/mjsunit/string-compare-alignment.js
Modified:
branches/0.3/src/api.cc
branches/0.
Author: whessev8
Date: Tue Oct 28 02:07:25 2008
New Revision: 620
Removed:
changes/whessev8/print-strings-from-testshell/
Log:
Delete.
--~--~-~--~~~---~--~~
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
-~--~~-
Reviewers: Kasper Lund,
Description:
Fixing profiling when using snapshot.
Please review this at http://codereview.chromium.org/8655
SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/
Affected files:
M src/log.h
M src/log.cc
Index: src/log.cc
===
LGTM. You should talk to Christian about the !FLAG_log tests in general.
On Tue, Oct 28, 2008 at 10:33 AM, <[EMAIL PROTECTED]> wrote:
> Reviewers: Kasper Lund,
>
> Description:
> Fixing profiling when using snapshot.
>
> Please review this at http://codereview.chromium.org/8655
>
> SVN Base: htt
Reviewers: iposva,
Description:
Get the ARM simulator to throw an exception on unaligned accesses.
Please review this at http://codereview.chromium.org/8830
SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/
Affected files:
M src/simulator-arm.h
M src/simulator-arm.cc
Author: olehougaard
Date: Tue Oct 28 02:53:52 2008
New Revision: 621
Modified:
branches/bleeding_edge/src/log.cc
branches/bleeding_edge/src/log.h
Log:
Fixing profiling when using snapshot.
Review URL: http://codereview.chromium.org/8655
Modified: branches/bleeding_edge/src/log.cc
==
According to Christian, the other !FLAG_log tests are there by design.
On Tue, Oct 28, 2008 at 10:43 AM, Kasper Lund <[EMAIL PROTECTED]> wrote:
> LGTM. You should talk to Christian about the !FLAG_log tests in general.
>
> On Tue, Oct 28, 2008 at 10:33 AM, <[EMAIL PROTECTED]> wrote:
> > Reviewer
LGTM
http://codereview.chromium.org/8635/diff/208/210
File src/ast.h (right):
http://codereview.chromium.org/8635/diff/208/210#newcode1344
Line 1344: };
Now we have back-references with an index, the capture should hold the
matching index, so we can pair captures and back-references.
http://co
LGTM.
On Tue, Oct 28, 2008 at 11:22 AM, <[EMAIL PROTECTED]> wrote:
> Reviewers: Kasper Lund,
>
> Description:
> In my final round of refactoring, I accidentally broke my string
> lenght optimization. Here is the fix: check that the instance type
> not the receiver is JS_VALUE_TYPE.
>
>
> Please
Author: [EMAIL PROTECTED]
Date: Tue Oct 28 03:25:35 2008
New Revision: 622
Modified:
branches/bleeding_edge/src/ic-arm.cc
branches/bleeding_edge/src/stub-cache-ia32.cc
Log:
In my final round of refactoring, I accidentally broke my string
lenght optimization. Here is the fix: check that
Reviewers: Kasper Lund,
Description:
In my final round of refactoring, I accidentally broke my string
lenght optimization. Here is the fix: check that the instance type
not the receiver is JS_VALUE_TYPE.
Please review this at http://codereview.chromium.org/8656
SVN Base: http://v8.googlecode.
To me, this looks like a good first step. I'm not particularly fond of
the frame_ == NULL bailout checks when visiting statements, and I
think it might make sense to split out the virtual frame abstraction
into its own set of files. I'd like to hear Ivan's opinion on the
direction of the change...
http://codereview.chromium.org/8635/diff/208/212
File src/parser.cc (right):
http://codereview.chromium.org/8635/diff/208/212#newcode3244
Line 3244: next_ = in()->GetNext();
We know it will work because we advance twice after setting up the
pushback buffer.
http://codereview.chromium.org/8635/d
Author: [EMAIL PROTECTED]
Date: Tue Oct 28 04:18:25 2008
New Revision: 623
Modified:
branches/experimental/regexp2000/src/ast.cc
branches/experimental/regexp2000/src/ast.h
branches/experimental/regexp2000/src/jsregexp.cc
branches/experimental/regexp2000/src/parser.cc
branches/
Issue 129: Memory consumption hyperoscillations
http://code.google.com/p/v8/issues/detail?id=129
Comment #1 by [EMAIL PROTECTED]:
Running with --trace-gc shows the expected behavior (keeps going from 20MB
-> 1MB),
but if you use 'top' on linux to measure how much memory the process is
using i
Issue 129: Memory consumption hyperoscillations
http://code.google.com/p/v8/issues/detail?id=129
Comment #2 by victor.grishchenko:
In my case, gc reports crazy swings as well:
./shell --trace-gc ./drive-gc-mad.js
queue size: 2430
Mark-compact 280.5 -> 0.4 MB, 78 ms.
queue size: 2432
--
Y
Issue 129: Memory consumption hyperoscillations
http://code.google.com/p/v8/issues/detail?id=129
Comment #4 by [EMAIL PROTECTED]:
Yeah, this looks bad. I realize that --trace-gc doesn't show the expected
behavior. I
was wrong. This is really something we need to fix.
Issue attribute updates:
Issue 129: Memory consumption hyperoscillations
http://code.google.com/p/v8/issues/detail?id=129
Comment #5 by victor.grishchenko:
P.S. Another symptom I see that might be related is that I get that
weird "out of memory" crashes when the
program consumes just, say, 160M RAM. I even rewrote 512M
Issue 129: Memory consumption hyperoscillations
http://code.google.com/p/v8/issues/detail?id=129
Comment #3 by victor.grishchenko:
P.S. 17000 disposable objects take 312M RAM? 18K per object? Something
really weird happens under the
hood. (The real problem is that I have that effect in my "bi
Issue 129: Memory consumption hyperoscillations
http://code.google.com/p/v8/issues/detail?id=129
Comment #6 by victor.grishchenko:
When I comment the unqueue() call and just stuff the array to the limit, I
get a totally different effect: it eats
1Gb, creates 1815 objects, 55 bytes per objec
Reviewers: bak,
Message:
I'm running it paa robotten to see if there's any performance impact.
Description:
Check the growth of the old generation before expanding the paged
spaces (during normal allocation) and when allocating large objects.
If the promotion limit is reached, fail allocation to
Reviewers: Kasper Lund,
Description:
Change the order of two assignments, to make sure that the script type
field is always initialized to a Smi before we get any GCs.
Please review this at http://codereview.chromium.org/8833
SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/
Affe
LGTM.
On Tue, Oct 28, 2008 at 2:42 PM, <[EMAIL PROTECTED]> wrote:
> Reviewers: Kasper Lund,
>
> Description:
> Change the order of two assignments, to make sure that the script type
> field is always initialized to a Smi before we get any GCs.
>
>
> Please review this at http://codereview.chromi
Author: [EMAIL PROTECTED]
Date: Tue Oct 28 06:46:04 2008
New Revision: 624
Modified:
branches/bleeding_edge/src/factory.cc
branches/bleeding_edge/src/objects-inl.h
Log:
Change the order of two assignments, to make sure that the script type
field is always initialized to a Smi before we g
Reviewers: Mads Ager,
Description:
Introduce access control in propertyIsEnumerable.
Also, fix JSObject::getPropertyAttribute() so it deals correctly with
access control modifiers.
Please review this at http://codereview.chromium.org/8834
SVN Base: http://v8.googlecode.com/svn/branches/bleeding
FYI, this change doubles running time on some of our benchmarks. I would
say that's unacceptable and we'll have to come up with something different.
I'll take a closer look tomorrow.
On Tue, Oct 28, 2008 at 2:36 PM, <[EMAIL PROTECTED]> wrote:
> Reviewers: bak,
>
> Message:
> I'm running it paa
Author: [EMAIL PROTECTED]
Date: Tue Oct 28 07:47:50 2008
New Revision: 625
Modified:
branches/bleeding_edge/src/array.js
branches/bleeding_edge/src/factory.cc
branches/bleeding_edge/src/factory.h
branches/bleeding_edge/src/objects.cc
branches/bleeding_edge/src/runtime.cc
b
Reviewers: Feng Qian,
Description:
Fix lint issues.
[EMAIL PROTECTED]
Please review this at http://codereview.chromium.org/8659
SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/
Affected files:
M src/runtime.cc
Index: src/runtime.cc
==
Author: [EMAIL PROTECTED]
Date: Tue Oct 28 07:54:52 2008
New Revision: 626
Modified:
branches/bleeding_edge/src/runtime.cc
Log:
Fix lint issues.
[EMAIL PROTECTED]
Review URL: http://codereview.chromium.org/8659
Modified: branches/bleeding_edge/src/runtime.cc
===
I agree that the bailout is ugly. It's there to avoid overriding the
default implementation of VisitStatements and to get everything to work, but
I will clean it up.
One neat thing is that I've discovered all the places where we were
generating dead code, because unreachable generated code has no
Reviewers: Kasper Lund, Kevin Millikin,
Message:
Opening up for a first set of comments.
I know already that:
- the loop_nesting_ in the CodeGenerator needs accessors
- ARM code generation needs to be updated
Thanks,
-Ivan
Description:
Track whether a node or variable are likely to be a Smi v
LGTM. Seems easy to extend and understand.
http://codereview.chromium.org/8835/diff/1/12
File src/codegen-ia32.cc (right):
http://codereview.chromium.org/8835/diff/1/12#newcode817
Line 817: flags = ((loop_nesting_ > 0) && type->IsLikelySmi()) ?
SMI_CODE_INLINED :
Nit: I would move ? onto a new
LGTM
-Ivan
http://codereview.chromium.org/8830/diff/1/3
File src/simulator-arm.cc (right):
http://codereview.chromium.org/8830/diff/1/3#newcode444
Line 444: PrintF("Unaligned read at %x\n", addr);
It would be helpful to print the PC and the address in the failure
messages such as:
"Unaligned
lgtm, thanks
On Tue, Oct 28, 2008 at 7:54 AM, <[EMAIL PROTECTED]> wrote:
> Reviewers: Feng Qian,
>
> Description:
> Fix lint issues.
>
> [EMAIL PROTECTED]
>
> Please review this at http://codereview.chromium.org/8659
>
> SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/
>
> Affected
Author: [EMAIL PROTECTED]
Date: Tue Oct 28 09:27:09 2008
New Revision: 627
Modified:
branches/bleeding_edge/src/runtime.cc
Log:
fix build error in debug mode, TBR=iposva
Modified: branches/bleeding_edge/src/runtime.cc
=
LGTM
-Ivan
On Tue, Oct 28, 2008 at 09:27, <[EMAIL PROTECTED]> wrote:
>
> Author: [EMAIL PROTECTED]
> Date: Tue Oct 28 09:27:09 2008
> New Revision: 627
>
> Modified:
>branches/bleeding_edge/src/runtime.cc
>
> Log:
> fix build error in debug mode, TBR=iposva
>
> Modified: branches/bleeding_e
Reviewers: iposva, Kasper Lund,
Description:
Check that an index is in the range of 0 to array length in
ArrayConcatVisitor.
Elements out of range are discarded.
Please review this at http://codereview.chromium.org/8836
SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/
Affected f
LGTM
-Ivan
http://codereview.chromium.org/8836
--~--~-~--~~~---~--~~
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
-~--~~~~--~~--~--~---
Author: [EMAIL PROTECTED]
Date: Tue Oct 28 10:23:10 2008
New Revision: 628
Modified:
branches/bleeding_edge/src/runtime.cc
Log:
Check that an index is in the range of 0 to array length in
ArrayConcatVisitor.
Elements out of range are discarded.
Review URL: http://codereview.chromium.org/8
Reviewers: iposva,
Description:
Fix the lint error.
TBR=iposva
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=629
Please review this at http://codereview.chromium.org/8664
SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/
Affected files:
M src/runtime
Author: [EMAIL PROTECTED]
Date: Tue Oct 28 10:32:01 2008
New Revision: 629
Modified:
branches/bleeding_edge/src/runtime.cc
Log:
Fix the lint error.
TBR=iposva
Review URL: http://codereview.chromium.org/8664
Modified: branches/bleeding_edge/src/runtime.cc
==
LGTM
-Ivan
PS. We should make presubmit.py a part of gcl change or gcl upload...
http://codereview.chromium.org/8664
--~--~-~--~~~---~--~~
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
-~--~~~~--~~-
If d8 is going to become the defacto shell for v8, I'd like to request
that argument handling be setup to be more compatible with other
JavaScript shells (namely, SpiderMonkey & Rhino). Issue 39 addresses
this for the old shell.
--~--~-~--~~~---~--~~
v8-dev mailing
Thanks for the feedback. Applied the changes, made it lint and now I am
running more tests...
-Ivan
http://codereview.chromium.org/8835/diff/1/12
File src/codegen-ia32.cc (right):
http://codereview.chromium.org/8835/diff/1/12#newcode817
Line 817: flags = ((loop_nesting_ > 0) && type->IsLikelyS
Overall it looks like a good start.
The flow of values down and up (and back down) the AST is subtle and
needs some overview comments.
Revisiting already analyzed nodes looks like it could be quadratic in
the size of the expression.
Minor comments below.
http://codereview.chromium.org/8835/di
Overall, the change looks good. I think we have to be careful that we
do not search the prototype during propertyIsEnumerable. The ECMA-262
standard explictly states that propertyIsEnumerable does not consider
the prototype chain. Therefore, you would get:
var p = { x: 42 };
var o = { };
o.__p
Reviewers: Christian Plesner Hansen,
Description:
By default disable the general protection fault message box when
running tests on Windows. This requires
Added the option --win-error-box to enable general protection fault
message box which can be convenient when debugging failing tests on
Windo
http://codereview.chromium.org/8676/diff/1/3
File src/platform-win32.cc (right):
http://codereview.chromium.org/8676/diff/1/3#newcode786
Line 786: abort();
AFAIK abort is not going to work in the sandbox because it tries to
display a message box, and that does not work in the sandbox. When is
http://codereview.chromium.org/8676/diff/1/3
File src/platform-win32.cc (right):
http://codereview.chromium.org/8676/diff/1/3#newcode786
Line 786: abort();
On 2008/10/28 21:45:38, Nicolas Sylvain wrote:
> AFAIK abort is not going to work in the sandbox because it tries to
display a
> message box
Kevin,
Thanks for the input, updated the comment and some of the style.
I understand your concern about the quadratic behaviour, but I believe
that due to the fact that the information flows in both directions,
you will not see this in practice. Do I have absolute proof that the
algorithm is nev
http://codereview.chromium.org/8676/diff/1/3
File src/platform-win32.cc (right):
http://codereview.chromium.org/8676/diff/1/3#newcode786
Line 786: abort();
On 2008/10/28 22:15:57, sgjesse wrote:
> On 2008/10/28 21:45:38, Nicolas Sylvain wrote:
> > AFAIK abort is not going to work in the sandbox
New snapshot uploaded.
On Tue, Oct 28, 2008 at 11:18 PM, <[EMAIL PROTECTED]> wrote:
>
> http://codereview.chromium.org/8676/diff/1/3
> File src/platform-win32.cc (right):
>
> http://codereview.chromium.org/8676/diff/1/3#newcode786
> Line 786: abort();
> On 2008/10/28 22:15:57, sgjesse wrote:
>
>>
http://codereview.chromium.org/8835/diff/229/239
File src/rewriter.cc (right):
http://codereview.chromium.org/8835/diff/229/239#newcode58
Line 58: void AstOptimizer::Optimize(ZoneList* statements) {
Agreed, but not in this change list.
On 2008/10/28 19:10:41, Kevin Millikin wrote:
> The Visitor
Author: [EMAIL PROTECTED]
Date: Tue Oct 28 15:33:00 2008
New Revision: 630
Modified:
branches/bleeding_edge/src/ast.h
branches/bleeding_edge/src/codegen-ia32.cc
branches/bleeding_edge/src/codegen-ia32.h
branches/bleeding_edge/src/compiler.cc
branches/bleeding_edge/src/flag-def
Reviewers: Kasper Lund,
Description:
Fix compile failure with very strict gcc warning rules on Linux.
TBR=kasperl
Please review this at http://codereview.chromium.org/8857
SVN Base: http://v8.googlecode.com/svn/branches/bleeding_edge/
Affected files:
M src/variables.h
M src/var
Author: [EMAIL PROTECTED]
Date: Tue Oct 28 15:47:51 2008
New Revision: 631
Modified:
branches/bleeding_edge/src/variables.cc
branches/bleeding_edge/src/variables.h
Log:
Fix compile failure with very strict gcc warning rules on Linux.
TBR=kasperl
Review URL: http://codereview.chromium.o
Issue 132: Treatment of RegExp is different between JavaScriptCore and v8
http://code.google.com/p/v8/issues/detail?id=132
New issue report by polarjs:
This issue was discovered while investigating ecma_2/RegExp/regress-001.js
of the mozilla JS tests. Here's a piece of test code that reduces the
Issue 133: Inconsistent errors when using RegExp literals
http://code.google.com/p/v8/issues/detail?id=133
New issue report by polarjs:
This issue was discovered while investigating ecma_2/RegExp/regress-001.js
of the mozilla JS tests. Here's a piece of test code that reduces the
issue:
Issue 132: Treatment of RegExp is different between JavaScriptCore and v8
http://code.google.com/p/v8/issues/detail?id=132
Comment #1 by [EMAIL PROTECTED]:
FF3 (mac) output:
a = /[a-km-z]+/
typeof a = object
typeof RegExp = function
b = he
c = he
d = he
e = he
--
You received this message bec
LGTM.
On Tue, Oct 28, 2008 at 11:46 PM, <[EMAIL PROTECTED]> wrote:
> Reviewers: Kasper Lund,
>
> Description:
> Fix compile failure with very strict gcc warning rules on Linux.
>
> TBR=kasperl
>
>
> Please review this at http://codereview.chromium.org/8857
>
> SVN Base: http://v8.googlecode.com/
72 matches
Mail list logo
