BUG=none
R=hpayer@chromium.org
LOG=n

Review URL: https://codereview.chromium.org/437993003

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

This way we don't clash with the ASSERT* macros
defined by GoogleTest, and we are one step closer
to being able to replace our homegrown base/ with
base/ from Chrome.

R=jochen@chromium.org, svenpanne@chromium.org

Review URL: https://codereview.chromium.org/430503007

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

R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/426233002

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

Also add IC tracing to a path where it was missing.

R=jarin@chromium.org

Review URL: https://codereview.chromium.org/368833003

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

This is a mostly mechanical CL (more than 90% Emacs macros and
query-replace-regexp) moving FILE*/StringStream*-based APIs to
OStream-based APIs. There are a few places where this had to stop,
otherwise the CL would be even bigger, but this can easily and
incrementally cleaned up later.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/363323003

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

BUG=none
R=jkummerow@chromium.org
LOG=n

Review URL: https://codereview.chromium.org/316133002

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

- this avoids using relative include paths which are forbidden by the style guide
- makes the code more readable since it's clear which header is meant
- allows for starting to use checkdeps

BUG=none
R=jkummerow@chromium.org, danno@chromium.org
LOG=n

Review URL: https://codereview.chromium.org/304153016

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

BUG=chromium:377209
LOG=n
R=dslomov@chromium.org

Review URL: https://codereview.chromium.org/306543002

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

Support x87-only platform (ia32 without SSE)

R=danno@chromium.org

Review URL: https://codereview.chromium.org/293743005

Patch from Weiliang Lin <weiliang.lin@intel.com>.

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

R=svenpanne@chromium.org

Review URL: https://codereview.chromium.org/296853007

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

This parameter will soon be used when a few pseudo-classes like
Serializer are turned into real classes. The current CL is already big
enough, untying our Gordian knot called "startup" will continue...

BUG=359977
LOG=y
R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/260003006

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

R=svenpanne@chromium.org

Review URL: https://codereview.chromium.org/259183002

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

R=mstarzinger@chromium.org
BUG=v8:3296
LOG=N

Review URL: https://codereview.chromium.org/256113003

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

This CL mechanically removes all useless Isolate* parameters from code
stub functions, making things quite a bit simpler.

BUG=359977
LOG=y
R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/255543003

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

This is a purely mechanical change, adding an Isolate* to the CodeStub
constructor and a corresponding field plus a getter. A few methods in
CodeStub and its subclasses can be simplified now, but this is done in
a separate CL.

The underlying reason apart from simplicity is that deep down in the
call chain we need to detect if the serializer is active or not. This
information will be part of the Isolate, not a global variable with
funky synchronization primitives around it (which is fundamentally
wrong and the underlying cause for race conditions and a catch-22
during initialization).

BUG=359977
LOG=y
R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/246643014

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

R=jarin@chromium.org

Review URL: https://codereview.chromium.org/239113009

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

This reverts r20802 .

TBR=jarin@chromium.org

Review URL: https://codereview.chromium.org/239543010

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

R=mvstanton@chromium.org, ulan@chromium.org

Review URL: https://codereview.chromium.org/237673014

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

Ensure that the stack contains the correct constant pool pointer when a
function deopts.

This CL depends on https://codereview.chromium.org/183803022/ landing first.

R=ulan@chromium.org

Review URL: https://codereview.chromium.org/188063002

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

BUG=
R=dcarney@chromium.org

Review URL: https://codereview.chromium.org/148223002

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

This CL fixes some bugs in the out of line constant pool implementation when
constant pools are GCed.  Namely:
  - Push/Pop pp register in exit frames and VisitPointer on it to ensure it is
    updated if the ConstantPoolArray is moved by GC.
  - Mark pp as a SafePoint Register for optimized functions.
  - Ensure that StandardFrame::IterateExpressions also iterates over the
    constant pool pointer in the stackframe.
  - Fix calculation of last_ptr_offset in ConstantPoolArray body iterator.
  - Make ensure that CONSTANT_POOL_ARRAY_TYPE is a pointer object InstanceType.

R=ulan@chromium.org

Review URL: https://codereview.chromium.org/123263005

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

Made operator* return reference to the raw type, not pointer. New method 'get()' should be used when raw pointer is needed.

Also removed useless inline modifier from the SmaprtPointer methods and added const modifier to the methods that don't change smart pointer.

Made ~SmartPointerBase protected to avoid accidental calls of the non-virtual base class's destructor.

drive-by: fixed use after free in src/factory.cc

BUG=None
LOG=N
R=alph@chromium.org, svenpanne@chromium.org

Review URL: https://codereview.chromium.org/101763003

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

R=yangguo@chromium.org
BUG=v8:3029
TEST=mjsunit/regress/regress-3029
LOG=N

Review URL: https://codereview.chromium.org/96773002

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

It results in a lot of dead code, and Isolate::PrintStack itself
crashes most of the time when something went wrong earlier.
Furthermore, we have plans do get better information into the
minidump, anyway.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/78003002

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

BUG=
R=danno@chromium.org

Review URL: https://chromiumcodereview.appspot.com/71783003

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

This reverts commit r17746 for breaking layout tests.

TBR=verwaest@chromium.org
BUG=

Review URL: https://codereview.chromium.org/72753002

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

R=danno@chromium.org

Review URL: https://chromiumcodereview.appspot.com/23537067

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

R=svenpanne@chromium.org
BUG=

Review URL: https://codereview.chromium.org/23708030

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

R=svenpanne@chromium.org
BUG=

Review URL: https://codereview.chromium.org/23886002

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

The FP setting is different for X32 than the other platforms as
kFPOnStackSize is double the kPointerSize and we have to clear the
higher 32 bits to 0.

R=danno@chromium.org

Review URL: https://codereview.chromium.org/20073004

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

The SafeStackFrameIterator used by CPU profiler checked if Isolate::c_entry_fp is null and if it is not it would think that the control flow currently is in some native code. This assumption is wrong because the native code could have called a JS function but JSEntryStub would not reset c_entry_fp to NULL in that case. This CL adds a check in SafeStackFrameIterator::IsValidTop for the case when there is a JAVA_SCRIPT frame on top of EXIT frame.

Also this CL changes ExternalCallbackScope behavior to provide access to the whole stack of the scope objects instead of only top one. This allowed to provide exact callback names for those EXIT frames where external callbacks are called. Without this change it was possible only for the top most native call.

BUG=None
R=loislo@chromium.org, yangguo@chromium.org

Review URL: https://codereview.chromium.org/19775017

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

BUG=None
R=danno@chromium.org

Review URL: https://codereview.chromium.org/19802002

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

Revert "Addressed danno's comments" and "Introduce kRegisterSize, kPCOnStackSize and kFPOnStackSize constants"

BUG=None
R=jkummerow@chromium.org

Review URL: https://codereview.chromium.org/19483007

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

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

This removes the isolate=>heap=>isolate nonsense and has the additional bonus
that it re-enables printing of code objects in GDB. NOT: To make the latter
work, one has to adapt GDB any macros using FindCodeObject! Keeping things as it
is and outlining Isolate::heap() was not really an option...

Side note: Currently we are lucky that we still have Isolate::Current()
available in GDB, although it is marked as INLINE. :-}

R=verwaest@chromium.org

Review URL: https://codereview.chromium.org/19785004

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

BUG=

Review URL: https://codereview.chromium.org/18404009

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

R=yangguo@chromium.org

Review URL: https://codereview.chromium.org/18509003

Patch from Haitao Feng <haitao.feng@intel.com>.

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

Their values are not used neither by the tick processor nor by CpuProfiler so it is just a waste of space.

TickSample used to be a transport for grabbed register values to TickSample::Trace, now they are passed in a special structure RegisterState which is allocated on the stack for the sampling period.

Some common pieces were moved from platform-dependent code into Sampler::SampleStack and TickSample::Init.

BUG=None
R=jkummerow@chromium.org, loislo@chromium.org

Review URL: https://codereview.chromium.org/18620002

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

When pc is inside FunctionApply builtin function the top frame may be either
2) Internal stack frame created by FunctionApply itself.
In this case we know its caller's pc and can correctly resolve calling function.
1) Frame of the calling JavaScript function that invoked .apply(). In this case we have no practical reliable way to find out the caller's pc so we mark the caller's frame as 'unresolved'.

All this logic is implemented in ProfileGenerator. SafeStackFrameIterator is extended to provide type of the current top stack frame (iteration actually starts from the caller's frame as we know top function from pc).

BUG=252097
R=jkummerow@chromium.org, loislo@chromium.org

Review URL: https://codereview.chromium.org/18269003

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

R=jkummerow@chromium.org

Review URL: https://codereview.chromium.org/18037002

Patch from Haitao Feng <haitao.feng@intel.com>.

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