- 26 Jan, 2010 7 commits
-
-
ager@chromium.org authored
Review URL: http://codereview.chromium.org/555099 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3711 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
sgjesse@chromium.org authored
This test have been timing out on ARM hardware from time to time. Review URL: http://codereview.chromium.org/543206 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3710 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
sgjesse@chromium.org authored
As the start index is already passed it is easy to calculate the "at start" boolean in generated code. Also as direct entry has been implemented this needs to be done in generated code anyway, and therefore might as well be moved to the generated code for RegExp. The "at start" value is now calcualted as a local variable on the native RegExp frame based on the value of the start index argument. The x64 version have been tested on both Linux and 64-bit Windows Vista. For ARM I have tested cctest/test-regexp on ARM hardware, but the rest of the tests have only been run on the ARM simulator. Review URL: http://codereview.chromium.org/554078 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3709 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
kaznacheev@chromium.org authored
1. MUL and DIV on SMIs. 2. When calling GenericBinaryOpStub from a virtual frame. 3. When generating code for a loop counter. Overall performance gain is about 0.6%. Review URL: http://codereview.chromium.org/555098 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3708 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
erik.corry@gmail.com authored
Review URL: http://codereview.chromium.org/556018 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3705 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
whesse@chromium.org authored
Review URL: http://codereview.chromium.org/549147 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3703 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
sgjesse@chromium.org authored
Review URL: http://codereview.chromium.org/546147 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3700 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Jan, 2010 11 commits
-
-
antonm@chromium.org authored
This reduces chances of improper usage, see http://code.google.com/p/v8/issues/detail?id=586 for more details. BUG=586 Review URL: http://codereview.chromium.org/555072 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3696 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
kaznacheev@chromium.org authored
See Kevin's comments for http://codereview.chromium.org/554062. Review URL: http://codereview.chromium.org/543193 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3695 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
kaznacheev@chromium.org authored
Also fixing some formatting issues. Review URL: http://codereview.chromium.org/556002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3694 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
ager@chromium.org authored
Review URL: http://codereview.chromium.org/545125 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3693 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
kaznacheev@chromium.org authored
Currently arguments are never passed on registers (due to the way ArgsInRegistersSupported is written) and if they were, the stub would break in several places because registers are not preserved properly in the course of execution. This CL makes use of registers more often (than never) and makes sure that registers are handler properly. A peformance gain is small (0.2-0.3%) but stable. This CL was extracted from the one sent out earlier (http://codereview.chromium.org/551093). git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3692 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
whesse@chromium.org authored
Review URL: http://codereview.chromium.org/543187 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3691 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
lrn@chromium.org authored
See Chromium bug 32637. Review URL: http://codereview.chromium.org/553067 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3689 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
ager@chromium.org authored
Patch by Erich Ocean and Ryan Dahl. Review URL: http://codereview.chromium.org/545125 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3688 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
whesse@chromium.org authored
Review URL: http://codereview.chromium.org/545155 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3687 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
lrn@chromium.org authored
Review URL: http://codereview.chromium.org/555049 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3683 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
kasperl@chromium.org authored
2.1.0. This means that the next version pushed to trunk will be the first version in the 2.1.x series. Review URL: http://codereview.chromium.org/551139 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3682 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 Jan, 2010 4 commits
-
-
fschneider@chromium.org authored
We now test for a smi before calling ToNumber and inline the smi increment/decrement for ++ and --. There only a small increase in code size but loops in top-level code are becoming much faster as a result. Review URL: http://codereview.chromium.org/553056 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3681 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
antonm@chromium.org authored
BUG=589,27967. Review URL: http://codereview.chromium.org/555048 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3680 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mikhail.naganov@gmail.com authored
As an afterthought, I realized that I put function objects moves reporting into a method that deals with only code object moves. I've looked up that function objects are allocated in old pointer space and new space, so I moved logging to the corresponding VM methods. BUG=553 Review URL: http://codereview.chromium.org/552089 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3679 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
sgjesse@chromium.org authored
The stub for calling RegExp directly now also handles two byte strings. Support for flat cons strings added for both ascii and two byte. Some code code simplifications and added a few constants. Review URL: http://codereview.chromium.org/545151 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3678 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Jan, 2010 10 commits
-
-
peter.rybin@gmail.com authored
Review URL: http://codereview.chromium.org/543154 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3676 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
peter.rybin@gmail.com authored
Review URL: http://codereview.chromium.org/552068 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3675 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
peter.rybin@gmail.com authored
Review URL: http://codereview.chromium.org/552043 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3674 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mikhail.naganov@gmail.com authored
The problem appeared due to a fact that stubs doesn't create a stack frame, reusing the stack frame of the caller function. When building stack traces, the current function is retrieved from PC, and its callees are retrieved by traversing the stack backwards. Thus, for stubs, the stub itself was discovered via PC, and then stub's caller's caller was retrieved from stack. To fix this problem, a pointer to JSFunction object is now captured from the topmost stack frame, and is saved into stack trace log record. Then a simple heuristics is applied whether a referred function should be added to decoded stack, or not, to avoid reporting the same function twice (from PC and from the pointer.) BUG=553 TEST=added to mjsunit/tools/tickprocessor Review URL: http://codereview.chromium.org/546089 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3673 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
antonm@chromium.org authored
Always invoke HeapObjectIterator::has_next() before invoking HeapObjectIterator::next(). This is necessary as ::has_next() has an important side-effect of going to the next page when current page is exhausted. And to find if pointers are encodable use more precise data---top of map space, not a number of pages, as pages might stay in map space due to chunking. Review URL: http://codereview.chromium.org/552066 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3672 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
erik.corry@gmail.com authored
Review URL: http://codereview.chromium.org/545153 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3671 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
lrn@chromium.org authored
Backport optimizations from x64 version to ia32. Review URL: http://codereview.chromium.org/546087 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3670 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
erik.corry@gmail.com authored
compiler for all code. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3669 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
erik.corry@gmail.com authored
I will revert when the bots have picked this one up. Review URL: http://codereview.chromium.org/549118 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3668 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
erik.corry@gmail.com authored
non-optimizing compiler can cope with. By default it bails out to the old compiler on encountering a for loop (for performance) but with this change the --always-fast-compiler flag will enable functions with for loops to be compiled in the non-optimizing compiler. Also enables the non-optimizing compiler on functions that can be lazily compiled (again only with the flag). Review URL: http://codereview.chromium.org/552065 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3667 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Jan, 2010 8 commits
-
-
peter.rybin@gmail.com authored
Review URL: http://codereview.chromium.org/549111 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3666 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
peter.rybin@gmail.com authored
Review URL: http://codereview.chromium.org/543121 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3665 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
whesse@chromium.org authored
Review URL: http://codereview.chromium.org/545134 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3664 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
peter.rybin@gmail.com authored
Review URL: http://codereview.chromium.org/536089 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3663 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
kmillikin@chromium.org authored
Review URL: http://codereview.chromium.org/549109 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3662 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
fschneider@chromium.org authored
This is a preparation step for including number type information in the virtual frame. We need a common place where we can update the number type information of the result of a binary operation since we should not modify the state of the virtual frame elements directly. Review URL: http://codereview.chromium.org/551080 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3661 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
kmillikin@chromium.org authored
always ambiguous whether it tried to generate fast code, or generate it quickly. Review URL: http://codereview.chromium.org/549108 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3660 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
vitalyr@chromium.org authored
BUG=582 TEST=cctest/test-api/NativeFunctionConstructCall Review URL: http://codereview.chromium.org/546088 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3659 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-