- 09 Mar, 2010 1 commit
-
-
kasperl@chromium.org authored
stats to make sure PRIVATE_EXTERNAL_ASCII_STRING_TYPE fits. Review URL: http://codereview.chromium.org/726002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 01 Mar, 2010 1 commit
-
-
kaznacheev@chromium.org authored
This is a subset of a CL reviewed earlier(http://codereview.chromium.org/551093). The register usage optimisation part has been reviewed and submitted separately. Two fast cases supported: HeapNumber operands and String operands for ADD. Review URL: http://codereview.chromium.org/553117 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3988 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 28 Jan, 2010 1 commit
-
-
kasperl@chromium.org authored
memory blocks filling them out with recognizable non-zero bit pattern in debug mode. Review URL: http://codereview.chromium.org/558016 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3729 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Jan, 2010 1 commit
-
-
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
-
- 21 Jan, 2010 1 commit
-
-
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
-
- 14 Jan, 2010 1 commit
-
-
erik.corry@gmail.com authored
* Add a test case that generates a serialization of a single flat string. Review URL: http://codereview.chromium.org/542073 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3606 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Jan, 2010 1 commit
-
-
erik.corry@gmail.com authored
for partial snapshots. After reserving space we can be sure that allocations will happen linearly (no GCs and no free-list allocation). This change also contains the start of the partial snapshot support, which, however is not yet completed or tested. Review URL: http://codereview.chromium.org/545026 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3584 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Dec, 2009 1 commit
-
-
antonm@chromium.org authored
Force mark sweep instead of compcation if size of map space is too big to allow forward pointers encoding. Review URL: http://codereview.chromium.org/507025 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3497 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 17 Dec, 2009 1 commit
-
-
sgjesse@chromium.org authored
On 32-bit the maps are now aligned on a 32-byte boundary in order to encode more maps during compacting GC. The actual size of a map on 32-bit is 28 bytes making this change waste 4 bytes per map. On 64-bit the encoding for compacting GC is now using more than 32-bits and the maps here are still pointer size aligned. The actual size of a map on 64-bit is 48 bytes and this change does not intruduce any waste. My choice of 16 bits for kMapPageIndexBits for 64-bit should give the same maximum number of pages (8K) for map space. As maps on 64-bit are larger than on 32-bit the total number of maps on 64-bit will be smaller than on 32-bit. We could consider raising this to 17 or 18. I moved the kPageSizeBits to globals.h as the calculation of the encoding really depended on this. There are still an #ifdef/#endif in objects.h and this constant could be moved to globaks.h as well, but I kept it together with the related constants. All the tests run in debug mode with additional options --gc-global --always-compact as well (except for a few tests on which also fails before this change when run with --gc-global --always-compact). BUG=http://code.google.com/p/v8/issues/detail?id=524 BUG=http://crbug.com/29428 TEST=test/mjsunit/regress/regress-524.js Review URL: http://codereview.chromium.org/504026 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3481 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Nov, 2009 1 commit
-
-
lrn@chromium.org authored
Set warning level to /W3 and change implicit conversions from size_t to int. Most "fixes" are simply manifesting the implicit casts or using a special strlen replacement that returns int. Review URL: http://codereview.chromium.org/390004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3273 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 27 Oct, 2009 1 commit
-
-
erik.corry@gmail.com authored
are different). Is able to deserialize the whole heap and run some stuff. Not available as the primary snapshot system yet. Review URL: http://codereview.chromium.org/335009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3142 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Oct, 2009 1 commit
-
-
ager@chromium.org authored
when using snapshots. The alignment of new space has to match the alignment in the snapshot, but the max committed amount of memory does not. For now, we assume that the default semispace size is always used in a snapshot. Review URL: http://codereview.chromium.org/300036 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3106 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Oct, 2009 1 commit
-
-
mikhail.naganov@gmail.com authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3098 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Oct, 2009 1 commit
-
-
whesse@chromium.org authored
Recommit coderanges putting code objects within a 2 GB range, reserving only a 256 MB range of virtual memory for the code range. Review URL: http://codereview.chromium.org/243087 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3018 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 01 Oct, 2009 2 commits
-
-
http://codereview.chromium.org/244022whesse@chromium.org authored
Revert change r3004, issue http://codereview.chromium.org/244022, because Linux 64-bit Chrome crashes with more than 10 tabs. Linux may not like 10 processes, each reserving 2 GB of virtual address space. Review URL: http://codereview.chromium.org/246064 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3006 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
whesse@chromium.org authored
Review URL: http://codereview.chromium.org/244022 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3004 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Sep, 2009 1 commit
-
-
whesse@chromium.org authored
Stop "cooking" targets of jumps and calls in code objects. Do not convert jump and call targets to absolute pointers to Code objects during GC, heap verification, and serialization. Review URL: http://codereview.chromium.org/203070 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2941 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Sep, 2009 1 commit
-
-
whesse@chromium.org authored
Review URL: http://codereview.chromium.org/210020 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2935 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 Sep, 2009 1 commit
-
-
ager@chromium.org authored
space. This can happen if a very big sequential string gets externalized. Review URL: http://codereview.chromium.org/185005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2817 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Aug, 2009 1 commit
-
-
ager@chromium.org authored
Review URL: http://codereview.chromium.org/174219 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2740 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Aug, 2009 1 commit
-
-
ager@chromium.org authored
Our memory tests show little improvement by only growing by 50%. Review URL: http://codereview.chromium.org/174133 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2728 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 19 Aug, 2009 2 commits
-
-
ager@chromium.org authored
Additionally fix NewSpace capacity bug by removing the duplicated capacity and maximum capacity book keeping. The capacity and maximum capacity of NewSpace is the capacity and maximum capacity of one of it's semispaces. Review URL: http://codereview.chromium.org/174052 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2717 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
ager@chromium.org authored
policy change. I will put the changes back one at a time so we can see the effect of them in isolation. Also, there is a bug in the growth policy change that I will fix before putting it back again. Review URL: http://codereview.chromium.org/174050 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2712 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 13 Aug, 2009 2 commits
-
-
bak@chromium.org authored
As a benefit, this eliminates an ifdef ARDROID. Review URL: http://codereview.chromium.org/165453 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2685 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bak@chromium.org authored
Review URL: http://codereview.chromium.org/164469 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2678 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Aug, 2009 1 commit
-
-
bak@chromium.org authored
- Changed the semi space growth policy from doubling to increasing by 50%. This slows down V8BenchmarkSuite with 1.32% but reduces the memory footprint with 8MB per V8 instance. Review URL: http://codereview.chromium.org/164397 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2667 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 23 Jul, 2009 1 commit
-
-
kmillikin@chromium.org authored
Coverity Prevent. All are benign. Review URL: http://codereview.chromium.org/159264 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2525 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 14 Jul, 2009 1 commit
-
-
feng@chromium.org authored
Renamed some macros to ANDROID. Review URL: http://codereview.chromium.org/155538 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2460 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 Jul, 2009 1 commit
-
-
ager@chromium.org authored
The abstractions have led to bugs because it looks like descriptor streams are GC safe but they are not. I have moved the descriptor stream helper functions to descriptor arrays and I find most of the code just as readable now as it was before. Review URL: http://codereview.chromium.org/149458 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2428 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Jul, 2009 3 commits
-
-
kmillikin@chromium.org authored
verification code was refactored to avoid verifying that property cells have correct remembered sets. Review URL: http://codereview.chromium.org/149392 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2423 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
kmillikin@chromium.org authored
Review URL: http://codereview.chromium.org/155287 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2418 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
kmillikin@chromium.org authored
space is similar to map space in that it has fixed-size objects. A common superclass for a space with fixed size objects is used for the map space and cell space. Allocate all cells in cell space. Handle it during all GCs. Modify the free-list node representation (so that the size is not at a fixed offset in all cells) to allow two-pointer free-list nodes. Clean up some stuff in the MC collector. Review URL: http://codereview.chromium.org/155211 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2411 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Jul, 2009 1 commit
-
-
erik.corry@gmail.com authored
register on ARM. * Make some compile-time loops into run-time loops for compactness. Review URL: http://codereview.chromium.org/149324 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2398 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Jun, 2009 1 commit
-
-
lrn@chromium.org authored
Remove references to Array:kHeaderSize. Review URL: http://codereview.chromium.org/150098 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2303 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 26 May, 2009 1 commit
-
-
erik.corry@gmail.com authored
Review URL: http://codereview.chromium.org/113825 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2054 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 May, 2009 2 commits
-
-
iposva@chromium.org authored
bits in a page. Review URL: http://codereview.chromium.org/113819 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2045 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mikhail.naganov@gmail.com authored
This issue was raised by Brett Wilson while reviewing my changelist for readability. Craig Silverstein (one of C++ SG maintainers) confirmed that we should declare one namespace per line. Our way of namespaces closing seems not violating style guides (there is no clear agreement on it), so I left it intact. Review URL: http://codereview.chromium.org/115756 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2038 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 14 May, 2009 1 commit
-
-
kmillikin@chromium.org authored
When a paged space shrinks by an even multiple of the chunk size, ensure that the cached last page in the space is updated. Review URL: http://codereview.chromium.org/113267 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1944 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 May, 2009 1 commit
-
-
ager@chromium.org authored
to the page iterator leads to occasional crashes in tests. Review URL: http://codereview.chromium.org/113262 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1915 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 May, 2009 1 commit
-
-
kmillikin@chromium.org authored
at construction time. If allocation during iteration causes a paged space to expand, the iterator will not return the new pages. This makes it more closely match the HeapObjectIterator behavior, and it removes a possible source of bugs (if the allocation top was in the last page in the space, the old iterator would stop only when it reached the end of the space, potentially returning invalid pages from a freshly expanded space). Review URL: http://codereview.chromium.org/115074 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1895 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-