- 17 Dec, 2010 1 commit
-
-
erik.corry@gmail.com authored
use cross thread synchronization in Crankshaft. Review URL: http://codereview.chromium.org/5979001 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6075 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 15 Dec, 2010 1 commit
-
-
erik.corry@gmail.com authored
the distance between bleeding edge and the gc branch minimal. Review URL: http://codereview.chromium.org/5788002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6016 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Dec, 2010 1 commit
-
-
erik.corry@gmail.com authored
and then trimming it when the length is known. This way we only have to traverse the input once. Review URL: http://codereview.chromium.org/5556012 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5951 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Dec, 2010 3 commits
-
-
kasperl@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5922 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
kasperl@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5921 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
kasperl@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5920 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 15 Nov, 2010 1 commit
-
-
mikhail.naganov@gmail.com authored
I observed that used heap size provided by Heap::SizeOfObjects() is usually about ~10% bigger than the number calculated by summing up heap objects sizes. This aligns DevTools Timeline stats with Heap profiler stats. Review URL: http://codereview.chromium.org/4888001 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5825 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 13 Nov, 2010 1 commit
-
-
antonm@chromium.org authored
MemoryAllocator::AvailableExecutable should return intptr_t, the difference of intptr_t's. TBR=ager@chromium.org Review URL: http://codereview.chromium.org/4972001 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5818 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 Nov, 2010 2 commits
-
-
ager@chromium.org authored
TBR=jschuh@chromium.org Review URL: http://codereview.chromium.org/4656002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5801 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
ager@chromium.org authored
Add 128MB limit for executable pages. BUG=http://code.google.com/p/v8/issues/detail?id=925 TEST=None. TBR=jschuh@chromium.org Review URL: http://codereview.chromium.org/4634003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5799 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Oct, 2010 1 commit
-
-
erik.corry@gmail.com authored
Review URL: http://codereview.chromium.org/3970005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5698 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 19 Oct, 2010 1 commit
-
-
ager@chromium.org authored
This can happen on Mac where C++ code can be in the 4-8K range. Review URL: http://codereview.chromium.org/3781020 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5656 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Sep, 2010 1 commit
-
-
erik.corry@gmail.com authored
This one has been approved by the 64 bit compiler in MSVC 2005 so I hope it also passes the 2008 version. The --max-new-space-size option is now in kBytes. The --max-old-space-size option is now in MBytes. Some issues remain with 64 bit heaps and the counters. See http://code.google.com/p/v8/issues/detail?id=887 Review URL: http://codereview.chromium.org/3573005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5559 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 28 Sep, 2010 3 commits
-
-
erik.corry@gmail.com authored
be done from Windows where the compiler is stricter about truncating changes. Review URL: http://codereview.chromium.org/3454035 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5545 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
erik.corry@gmail.com authored
Fix test after 64 bit heap size change. Review URL: http://codereview.chromium.org/3432032 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5543 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
erik.corry@gmail.com authored
removing the 1Gbyte limit. Review URL: http://codereview.chromium.org/3418035 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5542 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Sep, 2010 1 commit
-
-
dimich@chromium.org authored
The object's space in Page starts after Page header and is aligned to kMapAlignment which is 32 bytes on 32-bit and 8 bytes on 64-bit. In case of 64-bit target, the current page header size is exactly 32 bytes so we get the code magically aligned at 32 bytes but it is better to have a separate CODE_POINTER_ALIGN macro to make sure the object space in Page is aligned properly for both maps and code. There could be a small waste of bytes sometimes (since both Page header and Code header sizes are aligned separately) but it seems the optimal one would involve cross-dependencies between .h files and not clear if it's worth it. This is a back-port from Isolates branch. Review URL: http://codereview.chromium.org/3461021 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5526 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Sep, 2010 2 commits
-
-
sgjesse@chromium.org authored
TBR=pmehta@chromium.org Review URL: http://codereview.chromium.org/3333015 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5404 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
sgjesse@chromium.org authored
Allows the host application to provide a mechanism for notification and custom logging through a callback (set through the API V8::AddMemoryAllocationCallback and removed through V8::RemoveMemoryAllocationCallback), when V8 allocates ro frees memory. This replaces the current histogram data "V8.ExecutableMemoryMax" by allowing usage data to be logged by the application as required rather than always through V8. BUG=http://crbug.com/54222 TEST=Set the callback function with the API and cause V8 to allocate memory. Patch by Paul Mehta <pmehta@chromium.org> Review URL: http://codereview.chromium.org/3329006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5403 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 01 Sep, 2010 1 commit
-
-
yurys@chromium.org authored
Review URL: http://codereview.chromium.org/3344001 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5395 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Aug, 2010 2 commits
-
-
antonm@chromium.org authored
That could improve chances for commit success as currently, if we moved free pages out of order, we cannot shrink spaces. However, when we experience problems commiting from space back, we should use most of resources at our disposal. Also get rid of currently unused parameter to DeallocateFunction. Review URL: http://codereview.chromium.org/3260001 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5372 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
ricow@chromium.org authored
the code object's instructions. This allows us to find a code object using just the pc. This approach uses a cache (PcToCodeCache) to make sure we don't continuously have to iterate heap pages. This change eliminates the need for cooking and uncooking of stack frames. Review URL: http://codereview.chromium.org/3226014 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5369 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Aug, 2010 1 commit
-
-
sgjesse@chromium.org authored
Tracks the maximum usage of executable memory allocated by V8 and allows the histogram data to be gathered and reported. This patch is contains only the usage tracking logic from 3030048 (already LGTM'd). It does not implement the RWX Limit. BUG=52122 TEST=Check the V8.ExecutableMemoryMax histogram in the Chrome about:histograms page Review URL: http://codereview.chromium.org/3161015 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5299 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Jun, 2010 1 commit
-
-
antonm@chromium.org authored
Naive algorithm for to update RSets for a span is rather inefficient as it performs many unnecessary operations (retrieving a mask, updating it with the same bit as many pointers go into a single region). Review URL: http://codereview.chromium.org/2727009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4849 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 27 May, 2010 1 commit
-
-
vegorov@chromium.org authored
Reapply r4715 with fixes reviewed in http://codereview.chromium.org/2276002. Review URL: http://codereview.chromium.org/2255004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4743 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 26 May, 2010 1 commit
-
-
vegorov@chromium.org authored
TBR=ager@chromium.org Review URL: http://codereview.chromium.org/2274001 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4723 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 May, 2010 1 commit
-
-
vegorov@chromium.org authored
- New сardmarking write barrier handles large objects and normal objects in a similar fashion (no more additional space for pointer tracking is required, no conditional branches in WB code). - Changes to enable oldspaces iteration without maps decoding: -- layout change for FixedArrays: length is stored as a smis (initial patch by Kevin Millikin) -- layout change for SharedFunctionInfo: integer fields are stored as smi on arm, ia32 and rearranged on x64. -- layout change for String: meaning of LSB bit is fliped (1 now means hash not computed); on x64 padding is added. -- layout of maps is _not_ changed. Map space is currently iterated in a special way. Review URL: http://codereview.chromium.org/2144006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4715 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 May, 2010 2 commits
-
-
vegorov@chromium.org authored
TBR=ager@chromium.org Review URL: http://codereview.chromium.org/2073018 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4704 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
vegorov@chromium.org authored
Reapplication of r4685 (reviewed http://codereview.chromium.org/2101002) with minor modifications: - Fix compilation problems on Win64. - Improve heap verification pass: search for garbage pointers to new space not only in dirty regions but in all regions. Review URL: http://codereview.chromium.org/2114015 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4703 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 May, 2010 2 commits
-
-
vegorov@chromium.org authored
TBR=ager@chromium.org Review URL: http://codereview.chromium.org/2071020 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4688 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
vegorov@chromium.org authored
-- layout change for FixedArrays: length is stored as a smis (initial patch by Kevin Millikin) -- layout change for SharedFunctionInfo: integer fields are stored as smi on arm, ia32 and rearranged on x64. -- layout change for String: meaning of LSB bit is fliped (1 now means hash not computed); on x64 padding is added. -- layout of maps is _not_ changed. Map space is currently iterated in a special way. - Cardmarking write barrier. New barrier handles large objects and normal objects in a similar fashion (no more additional space for pointer tracking is required, no conditional branches in WB code). Review URL: http://codereview.chromium.org/2101002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4685 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 23 Apr, 2010 1 commit
-
-
vegorov@chromium.org authored
- Style cleanup: use Page::is_valid() instead of NULL-check, use Heap::CreateFillerObjectAt() instead of dummy free list nodes Review URL: http://codereview.chromium.org/1691009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4484 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 Apr, 2010 2 commits
-
-
vegorov@chromium.org authored
- RelinkPageListInChunkOrder might relink unused pages into the middle of a sequence of used pages. Filler objects should be placed at the beginning of such unused pages otherwise generic iterators (e.g. HeapObjectIterator) would not handle them correctly. - ObjectAreaEnd() should not be used as an allocation limit for pages from FixedSpace. Pages in such spaces do not use top page_extra_ bytes of object area. TBR=ager@chromium.org Review URL: http://codereview.chromium.org/1700005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4476 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
vegorov@chromium.org authored
instead of adding them to the free list. Review URL: http://codereview.chromium.org/1683001 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4475 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Apr, 2010 1 commit
-
-
mikhail.naganov@gmail.com authored
Also pull out VMState into its own set of source files. Review URL: http://codereview.chromium.org/1519027 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4361 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
-
- 27 Jan, 2010 1 commit
-
-
sgjesse@chromium.org authored
64-bit version now builds on Windows again in both release and debug mode. The Visual Studio project files have been updated so that all three configurations work (32-bit, 64-bit and 32-bit with ARM simulator). They all convert from Visual Studio 2005 to Visual Studio 2008. TBR=lrn@chromium.org Review URL: http://codereview.chromium.org/549174 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3722 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
-
-
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
-
- 19 Jan, 2010 1 commit
-
-
antonm@chromium.org authored
Review URL: http://codereview.chromium.org/543113 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3655 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-