TBR=ager@chromium.org
Review URL: http://codereview.chromium.org/193056

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2855 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

TBR=yurys@chromium.org
Review URL: http://codereview.chromium.org/197056

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2854 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/199056

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2853 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Safari.  Fixed const error in api.

Review URL: http://codereview.chromium.org/200056


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2852 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Doing so makes the max new space size influence the initial total size
of the heap.

This change reduces the initial memory use of V8 by over 6MB.

Review URL: http://codereview.chromium.org/202017

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2851 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Support stepping out for recursive functions.Simply flooding JS function from the calling stack frame with one shot breakpoints is not enough to support step out action in all cases since the function on top of the stack may be turn recursive and we may end up flooding itself. To overcome this a pointer to the stack frame where the debugger should be invoked after stepping out is strored in the debugger.Chromium bug:http://code.google.com/p/chromium/issues/detail?id=17967
Review URL: http://codereview.chromium.org/200041

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2850 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

TBR=ager@chromium.org
Review URL: http://codereview.chromium.org/201059

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2849 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

memory usage in Chromium 64-bit Linux.

Review URL: http://codereview.chromium.org/200055

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2848 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/195024

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2847 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/196042

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2846 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

(Not yet fully functional)

Review URL: http://codereview.chromium.org/201042


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2845 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Removed a false assertion in ScopeIterator that assumed context extension to never be a JSContextExtensionObject.

The context extension object in a 'with' context is JSContextExtensionObject iff the 'with' statement is generated from a catch block in order to extend its local scope with a variable holding exception object. This is how we differentiate 'catch' scope from 'with' scope.

Chrome bug:
http://code.google.com/p/chromium/issues/detail?id=17229
Review URL: http://codereview.chromium.org/202005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2843 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/190004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2842 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

in old space. Before this change we would compute the fragmentation 
limit before the GC, but that means that we take all the garbage 
into account - and consequently we almost never hit the limit (because 
we have a lot of garbage).

This change changes the policy to compact on the *next* GC if we
determine that we have too much fragmentation after doing a GC.
We'll do a GC if we've wasted more than 1MB and more than 15% of
the old space size.

This can be further improved by computing whether or not to compact
during the marking phase.
Review URL: http://codereview.chromium.org/202008

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2841 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

was fixed in r2642.
Review URL: http://codereview.chromium.org/192037

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2840 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This is an attempth to address the flakiness of the test cctest/test-debug/DebuggerAgent on the Mac build-bot.
Review URL: http://codereview.chromium.org/200037

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2839 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Author: abdulla <abdulla.kamar@gmail.com>
Review URL: http://codereview.chromium.org/173262


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2838 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Removed bogus ASSERTs from Intel macro assemblers.

Added a debug mode generated code assert to allocation code.
Review URL: http://codereview.chromium.org/199044

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2837 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

All macro-assembler-*.cc used a number of common enums. Moved these to macro-assembler.h.

Removed unused enum ExitJSFlag from ARM macro assembler.
Review URL: http://codereview.chromium.org/202004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2836 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Use different output directories when building using the Visual Studion solution.The different Visual Studio solutions for building for the different architures ia32, x64 and arm (simulator) now use separate output directories. Debug/Release for ia32, Debug64/Release64 for x64 and DebugArm/ReleaseArm for arm (simulator).It was required to duplicate all the project files for arm to avoid output from ia32 and arm to get mixed.
Review URL: http://codereview.chromium.org/199006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2835 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Port specialized constructor code for constructing simple objects to ARM.

See http://codereview.chromium.org/173470 for description.
Review URL: http://codereview.chromium.org/196024

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2834 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

TBR=erik.corry@chromium.org
Review URL: http://codereview.chromium.org/193039

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2833 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Objects which require an additional fixed array to be allocated now have this allocated in generated code as well. Added allocation flags to the macro assembler new space allocation routines.

Changed the ia32 and x64 macro assemblers to take allocation flags to the allocation routines instead of boolean flag.
Review URL: http://codereview.chromium.org/201015

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2832 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Patch by Patrick Gansterer <paroga@paroga.com>.
Review at http://codereview.chromium.org/199043.


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2831 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Support stepping in functions called using CallFunction stub. When Debug::PrepareStep is called to prepare 'step in' and current code target is CallFunction stub, the debugger will find function being called on the expression stack and flood it with one shot breakpoints.

BreakLocationIterator changed to treat 'debugger;' statements as a possible break location. Since 'debugger;' statement should always invoke debugger it is hanled in a special way.

Related Chromium issue:
http://code.google.com/p/chromium/issues/detail?id=17978
Review URL: http://codereview.chromium.org/195015

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2830 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The configuration for building the Windows shared library was lost when adding x64 Windows build to the SCons build. This should now be back.
Review URL: http://codereview.chromium.org/197036

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2828 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

TBR=christian.plesner.hansen@gmail.com

Review URL: http://codereview.chromium.org/192024

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2827 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2826 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

I have several Chromium's core files having SIGPROF signal handler called in the context of an arbitrary thread, causing a crash. This change introduces checking of current thread in the signal handler.

Review URL: http://codereview.chromium.org/171115

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2825 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/194023

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2824 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Use the correct ifdef to detect Win64 (_WIN64, not __MSVC__).

Review URL: http://codereview.chromium.org/195014


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2823 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Seems to err in a few cases, depending on the current time.

Review URL: http://codereview.chromium.org/192022


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2822 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This is required by the mandelbrot test in the language shootout.

Patch by abdulla <abdulla.kamar@gmail.com>.


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2821 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

create a new persistent handle to hold the context to save when
entering another context, now we use a stack of direct pointers that
the gc knows about.

Review URL: http://codereview.chromium.org/199021

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2820 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/197006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2819 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The debugger in the ARM simulator is now working again.

Added a help command and a command to print all registers. Made the printobject command print something in release builds.
Review URL: http://codereview.chromium.org/191004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2818 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

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

Review URL: http://codereview.chromium.org/186006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2816 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Re-apply http://codereview.chromium.org/175045 with the single change that the line

  mov(scratch, Operand(new_space_allocation_top));

have been added to MacroAssembler::UndoAllocationInNewSpace after the #endif. Without this change the top was not reset.

TBR=erik.corry@gmail.com
Review URL: http://codereview.chromium.org/184009

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2815 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Review URL: http://codereview.chromium.org/186005


git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2814 ce2b1a6d-e550-0410-aec6-3dcde31c8c00