Reason for revert:
MAC GCSTRESS failure on new test.
Original issue's description:
> Protect the emptiness of Array prototype elements with a PropertyCell.
>
> Not just emptiness, but also a particular structure.
>
> BUG=v8:4044
> LOG=N
TBR=jkummerow@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4044
Review URL: https://codereview.chromium.org/1099203004
Cr-Commit-Position: refs/heads/master@{#27998}
Not just emptiness, but also a particular structure.
BUG=v8:4044
LOG=N
Review URL: https://codereview.chromium.org/1092043002
Cr-Commit-Position: refs/heads/master@{#27993}
The embedder can control how many threads it wants to use via the
v8::Platform implementation. V8 internally doesn't spin up threads
anymore. If the embedder doesn't want to use any threads at all, it's
v8::Platform implementation must either run the background jobs on
the foreground thread, or the embedder should specify --predictable
BUG=none
R=yangguo@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1064723005
Cr-Commit-Position: refs/heads/master@{#27833}
This switches full-codegen to no longer push and pop StackHandler
markers onto the operand stack, but relies on a range-based handler
table instead. We only use StackHandlers in JSEntryStubs to mark the
transition from C to JS code.
Note that this makes deoptimization and OSR from within any try-block
work out of the box, makes the non-exception paths faster and should
overall be neutral on the memory footprint (pros).
On the other hand it makes the exception paths slower and actually
throwing and exception more expensive (cons).
R=yangguo@chromium.org
TEST=cctest/test-run-jsexceptions/DeoptTry
Review URL: https://codereview.chromium.org/1010883002
Cr-Commit-Position: refs/heads/master@{#27440}
Reason for revert:
Failing Blink tests on Win and Mac:
- plugins/netscape-plugin-property-access-exception.html
- http/tests/plugins/cross-frame-object-access.html
Original issue's description:
> Cleanup and unify Isolate::ReportPendingMessages.
>
> Note that this is a pure cleanup CL and shouldn't have an observable
> impact on the functional behavior of message reporting.
>
> R=yangguo@chromium.orgTBR=yangguo@chromium.org,machenbach@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1016323002
Cr-Commit-Position: refs/heads/master@{#27306}
This relands commit 96f79568a9.
This makes the Isolate::Throw logic not depend on a prediction of
whether an exception is caught or uncaught. Such a prediction is
inherently undecidable because a finally block can decide between
consuming or re-throwing an exception depending on arbitray control
flow.
There still is a conservative prediction mechanism in place that
components like the debugger or tracing can use for reporting.
With this change we can get rid of the StackHandler::kind field, a
pre-requisite to do table-based lookups of exception handlers.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/997213003
Cr-Commit-Position: refs/heads/master@{#27263}
Reason for revert:
Layout test failure in inspector/sources/debugger/debugger-pause-on-promise-rejection.html
Original issue's description:
> Remove kind field from StackHandler.
>
> This makes the Isolate::Throw logic not depend on a prediction of
> whether an exception is caught or uncaught. Such a prediction is
> inherently undecidable because a finally block can decide between
> consuming or re-throwing an exception depending on arbitray control
> flow.
>
> There still is a conservative prediction mechanism in place that
> components like the debugger or tracing can use for reporting.
>
> With this change we can get rid of the StackHandler::kind field, a
> pre-requisite to do table-based lookups of exception handlers.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/96f79568a926966ebcf0685bf9adc947f4e1fbff
> Cr-Commit-Position: refs/heads/master@{#27210}
TBR=yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1009903002
Cr-Commit-Position: refs/heads/master@{#27215}
This makes the Isolate::Throw logic not depend on a prediction of
whether an exception is caught or uncaught. Such a prediction is
inherently undecidable because a finally block can decide between
consuming or re-throwing an exception depending on arbitray control
flow.
There still is a conservative prediction mechanism in place that
components like the debugger or tracing can use for reporting.
With this change we can get rid of the StackHandler::kind field, a
pre-requisite to do table-based lookups of exception handlers.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1002203002
Cr-Commit-Position: refs/heads/master@{#27210}
This moves the decision whether to report a message or not to when
the pending exception is propagated instead of trying to preserve the
decision in a ThreadLocalTop field.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/998943003
Cr-Commit-Position: refs/heads/master@{#27150}
The external v8::TryCatch handler was computed eagerly and kept in
intact. This changes it to be computed lazily for simplicity and
readability of the code.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/997863003
Cr-Commit-Position: refs/heads/master@{#27132}
This removes the separate tracking of the pending message script,
because that script is already stored in the message object and
duplicating it in the ThreadLocalTop makes it more brittle.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/995013005
Cr-Commit-Position: refs/heads/master@{#27127}
This makes sure that the pending message location is only tracked by
the message object, as only this is saved for finally-blocks. The
location information is duplicated and becomes stale.
R=titzer@chromium.org
TEST=maeh, not so much.
Review URL: https://codereview.chromium.org/987353002
Cr-Commit-Position: refs/heads/master@{#27109}
We no longer expect NewError to return an empty handle to signal termination
exception, since TryCall simply requests a new terminate exception interrupt.
BUG=chromium:403509
LOG=N
Review URL: https://codereview.chromium.org/952483002
Cr-Commit-Position: refs/heads/master@{#26811}
Additionally handlify the "transition" field so that GC can stop caring about it.
BUG=
Review URL: https://codereview.chromium.org/935033003
Cr-Commit-Position: refs/heads/master@{#26718}
When embedder detaches the global objects, its context must be garbage
collected eventually.
BUG=
Review URL: https://codereview.chromium.org/898663005
Cr-Commit-Position: refs/heads/master@{#26450}
For exception in promise we generate v8::Message API object from exception object. And in cases of Syntax or Reference Error we don't have enough information in exception object - we can't restore Error location from top stack frame.
In this patch three aditional private fields introduced for exception object. In case of Syntax Error we store line, column and script on Exception object and receive this information when restoring message.
BUG=443140
LOG=Y
R=yurys@chromium.org
Review URL: https://codereview.chromium.org/885043002
Cr-Commit-Position: refs/heads/master@{#26393}
This solves an issue with the custom startup snapshot, in cases where
deserializing the isolate requires more than one page per space.
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/876613002
Cr-Commit-Position: refs/heads/master@{#26285}
There might be a number of clients that would like to
setup an interrupt request on the Isolate.
The patch also deprecates ClearInterrupt API. As long as
the interrupt handler is called outside of locks there's no way
to guarantee that the handler will not be called after
ClearInterrupt was invoked as it might have already started execution.
Review URL: https://codereview.chromium.org/796623003
Cr-Commit-Position: refs/heads/master@{#25910}
There are no users of this infrastructure yet, so it's behind an off-by-default flag.
Review URL: https://codereview.chromium.org/768633002
Cr-Commit-Position: refs/heads/master@{#25829}
> We also initialize the Isolate on creation.
>
> This should allow for getting rid of the last remaining default isolate
> traces. Also, it'll speed up several isolate related operations that no
> longer require locks.
>
> Embedders that relied on v8::Isolate to return an uninitialized Isolate
> (so they can set ResourceConstraints for example, or set flags that
> modify the way the isolate is created) should either do the setup before
> creating the isolate, or use the recently added CreateParams to pass e.g.
> ResourceConstraints.
>
> BUG=none
> LOG=y
> R=svenpanne@chromium.org
>
> Review URL: https://codereview.chromium.org/469783002
BUG=none
LOG=y
TBR=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/583153002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We also initialize the Isolate on creation.
This should allow for getting rid of the last remaining default isolate
traces. Also, it'll speed up several isolate related operations that no
longer require locks.
Embedders that relied on v8::Isolate to return an uninitialized Isolate
(so they can set ResourceConstraints for example, or set flags that
modify the way the isolate is created) should either do the setup before
creating the isolate, or use the recently added CreateParams to pass e.g.
ResourceConstraints.
BUG=none
LOG=y
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/469783002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24052 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Centralize a register definition in an IC that provides:
1) symbolic names for the register (like, edx == receiver)
2) defines ordering when passed on the stack
Code that implements or uses the IC should use this definition instead of "knowing" what the registers are. Or at least have the definition to validate it's assumptions.
As a side effect of avoiding runtime static initializers (enforced by tools/check-static-initializers.sh, neat), I gave ownership of the registers array to CodeStubInterfaceDescriptor. This prompted a cleanup of that struct.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/352583002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22011 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This avoids the appearence of a leak due to storing a JSObject
as the microtask_state in the strong root list, and allows callers
to call Isolate::RunMicrotasks() without having any v8::Context
available (as at least Blink has interest in doing).
The queue is now a strong root, represented as a FixedArray of JSFunctions
(or empty_fixed_array, if it's empty); it doubles in size when it needs to grow.
The number of elements in the queue is stored in Isolate::pending_microtask_count().
LOG=Y
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/290633010
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21356 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Instead of tracking simple absolute offset from the start of the script like other places do, track a pair of (inlining id, offset from the start of inlined function).
This enables us to pinpoint with inlining path an instruction came from. Previously in multi-script environments we emitted positions that made very little sense because inside a single optimized function they would point to different scripts without a way to distinguish them.
Start dumping the source of every inlined function to make possible IR viewing tools with integrated source views as there was previously no way to acquire this information from IR dumps. We also dump source position at which each inlining occured.
Tracked positions are written into hydrogen.cfg as pos:<inlining-id>_<offset>.
Flag --emit-opt-code-positions is renamed by this change into --hydrogen-track-positions to better convey it's meaning.
In addition this change assigned global unique identifier to each optimization performed inside isolate. This allows to precisely match compilation artifacts (e.g. IR and disassembly) and deoptimizations.
BUG=
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/140683011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19360 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch generalizes Object.observe callbacks and promise resolution into a FIFO queue called a "microtask queue".
It also exposes new V8 API which exposes the microtask queue to the embedder. In particular, it allows the embedder to
-schedule a microtask (EnqueueExternalMicrotask)
-run the microtask queue (RunMicrotasks)
-control whether the microtask queue is run automatically within V8 when the last script exits (SetAutorunMicrotasks).
R=dcarney@chromium.org, rossberg@chromium.org, dcarney, rossberg, svenpanne
BUG=
Review URL: https://codereview.chromium.org/154283002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19344 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
version is passing all the existing test + a bunch of new tests
(packaged in the change list, too).
The patch extends the SlotRef object to describe captured and duplicated
objects. Since the SlotRefs are not independent of each other anymore,
there is a new SlotRefValueBuilder class that stores the SlotRefs and
later materializes the objects from the SlotRefs.
Note that unlike the previous implementation of SlotRefs, we now build
the SlotRef entries for the entire frame, not just the particular
function. This is because duplicate objects might refer to previous
captured objects (that might live inside other inlined function's part
of the frame).
We also need to store the materialized objects between other potential
invocations of the same arguments object so that we materialize each
captured object at most once. The materialized objects of frames live
in the new MaterielizedObjectStore object (contained in Isolate),
indexed by the frame's FP address. Each argument materialization (and
deoptimization) tries to lookup its captured objects in the store before
building new ones. Deoptimization also removes the materialized objects
from the store. We also schedule a lazy deopt to be sure that we always
get rid of the materialized objects and that the optmized function
adopts the materialized objects (instead of happily computing with its
captured representations).
Concerns:
- Is the FP address the right key for a frame? (Note that deoptimizer's
representation of frame is different from the argument object
materializer's one - it is not easy to find common ground.)
- Performance is suboptimal in several places, but a quick local run of
benchmarks does not seem to show a perf hit. Examples of possible
improvements: smarter generation of SlotRefs (build other functions'
SlotRefs only for captured objects and only if necessary), smarter
lookup of stored materialized objects.
- Ideally, we would like to share the code for argument materialization
with deoptimizer's materializer. However, the supporting data structures
(mainly the frame descriptor) are quite different in each case, so it
looks more like a separate project.
Thanks for any feedback.
R=danno@chromium.org, mstarzinger@chromium.org
LOG=N
BUG=
Committed: https://code.google.com/p/v8/source/detail?r=18918
Review URL: https://codereview.chromium.org/103243005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18936 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
mostly to make sure that it is going in the right direction. The current
version is passing all the existing test + a bunch of new tests
(packaged in the change list, too).
The patch extends the SlotRef object to describe captured and duplicated
objects. Since the SlotRefs are not independent of each other anymore,
there is a new SlotRefValueBuilder class that stores the SlotRefs and
later materializes the objects from the SlotRefs.
Note that unlike the previous implementation of SlotRefs, we now build
the SlotRef entries for the entire frame, not just the particular
function. This is because duplicate objects might refer to previous
captured objects (that might live inside other inlined function's part
of the frame).
We also need to store the materialized objects between other potential
invocations of the same arguments object so that we materialize each
captured object at most once. The materialized objects of frames live
in the new MaterielizedObjectStore object (contained in Isolate),
indexed by the frame's FP address. Each argument materialization (and
deoptimization) tries to lookup its captured objects in the store before
building new ones. Deoptimization also removes the materialized objects
from the store. We also schedule a lazy deopt to be sure that we always
get rid of the materialized objects and that the optmized function
adopts the materialized objects (instead of happily computing with its
captured representations).
Concerns:
- Is there a simpler/more correct way to store the already-materialized
objects? (At the moment there is a custom root reference to JSArray
containing frames' FixedArrays with their captured objects.)
- Is the FP address the right key for a frame? (Note that deoptimizer's
representation of frame is different from the argument object
materializer's one - it is not easy to find common ground.)
- Performance is suboptimal in several places, but a quick local run of
benchmarks does not seem to show a perf hit. Examples of possible
improvements: smarter generation of SlotRefs (build other functions'
SlotRefs only for captured objects and only if necessary), smarter
lookup of stored materialized objects.
- Ideally, we would like to share the code for argument materialization
with deoptimizer's materializer. However, the supporting data structures
(mainly the frame descriptor) are quite different in each case, so it
looks more like a separate project.
Thanks for any feedback.
R=mstarzinger@chromium.org, danno@chromium.org
LOG=N
BUG=
Review URL: https://codereview.chromium.org/103243005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18918 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This reverts:
r18749 "Reland (and fix) "Add hydrogen support for ArrayPop, and remove the handwritten call stubs."",
r18790 "Remove ArrayPush from the custom call generators, and instead call directly to the handler in crankshaft.", and
r18798 "MIPS: Remove ArrayPush from the custom call generators, and instead call directly to the handler in crankshaft."
For causing crashes on Canary.
BUG=chromium:337686
LOG=N
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/146003006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18805 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
call machinery. The change replaces CallNamed, CallKeyed,
CallConstantFunction and CallKnownGlobal hydrogen instructions with two
new instructions with a more lower level semantics:
1. CallJSFunction for direct calls of JSFunction objects (no
argument adaptation)
2. CallWithDescriptor for calls of a given Code object according to
the supplied calling convention.
Details:
CallJSFunction should be straightforward, the main difference from the
existing InvokeFunction instruction is the absence of argument adaptor
handling. (As a next step, we will replace InvokeFunction with an
equivalent hydrogen code.)
For CallWithDescriptor, the calling conventions are represented by a
tweaked version of CallStubInterfaceDescriptor. In addition to the
parameter-register mapping, we also define parameter-representation
mapping there. The CallWithDescriptor instruction has variable number of
parameters now - this required some simple tweaks in Lithium, which
assumed fixed number of arguments in some places.
The calling conventions used in the calls are initialized in the
CallDescriptors class (code-stubs.h, <arch>/code-stubs-<arch>.cc), and
they live in a new table in the Isolate class. I should say I am not
quite sure about Representation::Integer32() representation for some of
the params of ArgumentAdaptorCall - it is not clear to me wether the
params could not end up on the stack and thus confuse the GC.
The change also includes an earlier small change to argument adaptor
(https://codereview.chromium.org/98463007) that avoids passing a naked
pointer to the code entry as a parameter. I am sorry for packaging that
with an already biggish change.
Performance implications:
Locally, I see a small regression (.2% or so). It is hard to say where
exactly it comes from, but I do see inefficient call sequences to the
adaptor trampoline. For example:
;;; <@78,#24> constant-t
bf85aa515a mov edi,0x5a51aa85 ;; debug: position 29
;;; <@72,#53> load-named-field
8b7717 mov esi,[edi+0x17] ;; debug: position 195
;;; <@80,#51> constant-s
b902000000 mov ecx,0x2 ;; debug: position 195
;;; <@81,#51> gap
894df0 mov [ebp+0xf0],ecx
;;; <@82,#103> constant-i
bb01000000 mov ebx,0x1
;;; <@84,#102> constant-i
b902000000 mov ecx,0x2
;;; <@85,#102> gap
89d8 mov eax,ebx
89cb mov ebx,ecx
8b4df0 mov ecx,[ebp+0xf0]
;;; <@86,#58> call-with-descriptor
e8ef57fcff call ArgumentsAdaptorTrampoline (0x2d80e6e0) ;; code: BUILTIN
Note the silly handling of ecx; the hydrogen for this code is:
0 4 s27 Constant 1 range:1_1 <|@
0 3 t30 Constant 0x5bc1aa85 <JS Function xyz (SharedFunctionInfo 0x5bc1a919)> type:object <|@
0 1 t36 LoadNamedField t30.[in-object]@24 <|@
0 1 t38 Constant 0x2300e6a1 <Code> <|@
0 1 i102 Constant 2 range:2_2 <|@
0 1 i103 Constant 1 range:1_1 <|@
0 2 t41 CallWithDescriptor t38 t30 t36 s27 i103 i102 #2 changes[*] <|@
BUG=
R=verwaest@chromium.org, danno@chromium.org
Review URL: https://codereview.chromium.org/104663004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18626 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We don't use the worker pool yet, however, there are tests. Yay. The
next step is to use the worker pool for parallel sweeping.
I've also started to move the platform related files into a sub
directory. The goal is to eventually build all the platform stuff as
a separate library which is used by d8 and cctest (and other embedders
that wish to use the default implementation) but not by chromium.
BUG=v8:3015
R=hpayer@chromium.org, svenpanne@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/104583003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18380 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
It was only used for Math.log, and even then only in full code and in %_MathLog. For crankshafted code, Intel already used the FP operations directly, while the ARM/MIPS ports were a bit lazy and simply called the stub. The latter directly call the C library now without any cache. It would be possible to directly generate machine code if somebody has the time, from what I've seen out in the wild it should be only about a dozen instructions.
LOG=y
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/113343003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18344 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Based on prototype at
https://github.com/rossberg-chromium/js-promise
which informed the latest spec draft version at
https://github.com/domenic/promises-unwrapping/blob/master/README.md
Activated by --harmony-promises.
Feature complete with respect to the draft spec, plus the addition of .when and .deferred methods. Final naming and other possible deviations from the current draft will hopefully be resolved soon after the next TC39 meeting.
This CL also generalises the Object.observe delivery loop into a simplistic microtask loop. Currently, all observer events are delivered before invoking any promise handler in a single fixpoint iteration. It's not clear yet what the final semantics is supposed to be (should there be a global event ordering?), but it will probably require a more thorough event loop abstraction inside V8 once we get there.
R=dslomov@chromium.org, yhirano@chromium.org
BUG=
Review URL: https://codereview.chromium.org/64223010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18113 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is controlled by two flags:
--redirect_code_traces
--redirect_code_traces_to=<filename>
When redirection is enabled but --redirect_code_traces_to is not specified traces are written to a file code-<pid>-<isolate>.asm. This mangling scheme matches hydrogen.cfg and allows easy discovery of compilation artifacts in a multi-V8 environment (e.g. when compilation is traced from inside Chromium).
D8 defines --redirect_code_traces_to=code.asm similar to hydrogen.cfg redirection.
BUG=
R=danno@chromium.org
Review URL: https://codereview.chromium.org/43273004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17571 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The RandomNumberGenerator is a pseudorandom number generator
with 48-bit state. It is properly seeded using either
(1) the --random-seed if specified, or
(2) the entropy_source function if configured, or
(3) /dev/urandom if available, or
(4) falls back to Time and TimeTicks based seeding.
Each Isolate now contains a RandomNumberGenerator, which replaces
the previous private_random_seed.
Every native context still has its own random_seed. But this random
seed is now properly initialized during bootstrapping,
instead of on-demand initialization. This will allow us to cleanup
and speedup the HRandom implementation quite a lot (this is delayed
for a followup CL)!
Also stop messing with the system rand()/random(), which should
not be done from a library anyway! We probably re-seeded the
libc rand()/random() after the application (i.e. Chrome) already
seeded it (with better entropy than what we used).
Another followup CL will replace the use of the per-isolate
random number generator for the address randomization and
thereby get rid of the Isolate::UncheckedCurrent() usage in
the platform code.
TEST=cctest/test-random-number-generator,cctest/test-random
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/23548024
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16612 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Drop the previous Mutex and ScopedLock classes from platform files.
Add new Mutex, RecursiveMutex and LockGuard classes, which are
designed after their C++11 counterparts, so that at some point
we can simply drop our custom code and switch to the C++11
classes. We distinguish regular and recursive mutexes, as the
latter don't work well with condition variables, which will be
introduced by a followup CL.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/23625003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16416 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
This change removes per-isolate counter of active SafeStackFrameIterators. The counter is used by stack frames implementations to avoid accessing pointers to heap objects when traversing stack for CPU profiler (so called "safe" mode). Each StackFrame instance is owned by single iterator and has a pointer to it so we can simply mark the iterator as "safe" or not and read the field in the stack frames instead of going into the isolate.
BUG=None
R=loislo@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/17585008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15317 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
