The bit counting functions provided by CompilerIntrinsics were undefined
for zero, which was easily overlooked and unsafe in general. Also their
implementation was kinda hacky and mostly untested. Fixed the
implementation and moved the functions to base/bits.h.
TEST=base-unittests,cctest,compiler-unittests,mjsunit
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/494633002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23229 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
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
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
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
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
