Got rid of the debug break on return entry code which did not add anything. It just jumped directly to the debug break on return code.

Removed the CodePatcher class on x64 as it was not implemented.

Added instruction cache flush to where the return sequence was patched on x64.

Added some missing ENABLE_DEBUGGER_SUPPORT #ifdef/#endif.
Review URL: http://codereview.chromium.org/193057

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

The algorithm for finding the inner-most function containing a script break point was not correct when the script only contained one function. In that case the script function and not the actual function in the script could be returned depending on the order of the objects in the heap.

TEST=cctest/test-debug/ScriptBreakPointReload
BUG=none

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

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

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

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

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

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

Also:
- move constructor name getter near similar class name getter method;
- if the constructor is not present, use 'Object', as for class name, this eliminates a special case.

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

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

followed by shrinking of new space earlier.

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

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

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

This reduces the initial V8 memory usage by roughly 2MB.

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

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

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