Thus DevTools will be able to disable tail call elimination dynamically upon user's choice.
BUG=v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1837513002
Cr-Commit-Position: refs/heads/master@{#35098}
Reason for revert:
Makes nosnap bots timeout due to having to rebuild bytecode handlers.
Original issue's description:
> [Interpreter] Remove separate Ignition snapshot.
>
> Removes the seperate Ignition snapshot and build the Ignition bytecode
> handlers in the default snapshot.
>
> BUG=v8:4280
> LOG=N
>
> Committed: https://crrev.com/1798f3fe84faff32ba44e09f6aed79245dd98d80
> Cr-Commit-Position: refs/heads/master@{#35058}
TBR=machenbach@google.com,yangguo@chromium.org,mstarzinger@chromium.org,machenbach@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280
Review URL: https://codereview.chromium.org/1827143002
Cr-Commit-Position: refs/heads/master@{#35059}
Removes the seperate Ignition snapshot and build the Ignition bytecode
handlers in the default snapshot.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1833643002
Cr-Commit-Position: refs/heads/master@{#35058}
HandleScopes in for-loops are rather expensive and pose a significant overhead
to some builtin/runtime-functions. The FOR_WITH_HANDLE_SCOPE macro is used to
only create a new HandleScope every 1024th iteration.
BUG=
Review URL: https://codereview.chromium.org/1785403002
Cr-Commit-Position: refs/heads/master@{#34856}
A startup snapshot is considered cold when it does not contain any
function code. We can now create a warm startup snapshot from a cold one
by running a warm-up script. Functions exercised by the warm-up script
are compiled and its code included in the warm startup snapshot. Side
effects caused by the warm-up script does not persist.
R=vogelheim@chromium.org
BUG=v8:4836
LOG=Y
Review URL: https://codereview.chromium.org/1805903002
Cr-Commit-Position: refs/heads/master@{#34849}
The OOM emergency GCs result in time outs on the stress GC bots. Doing a regular stress compaction GC is enough to stress the garbage collector.
BUG=
Review URL: https://codereview.chromium.org/1794943007
Cr-Commit-Position: refs/heads/master@{#34740}
Add S390 platform specific \#includes across various common files.
Add S390 CPU features to enum.
Add S390 implementation to extract sp/fp/pc from signal context.
R=danno@chromium.org,jkummerow@chromium.org,jochen@chromium.org,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1777593003
Cr-Commit-Position: refs/heads/master@{#34674}
This scope is used to control microtasks execution when MicrotasksPolicy::kScoped is engaged.
Attempt #2. First one was reverted due to chromium breakage: SetAutorunMicrotasks(false) was broken.
BUG=chromium:585949
LOG=Y
TEST=ScopedMicrotasks
Review URL: https://codereview.chromium.org/1741893003
Cr-Commit-Position: refs/heads/master@{#34504}
Reason for revert:
[Sheriff] Speculative. Seems to break a bunch of webkit tests and causes timeouts:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/5103
Please rebase upstream if intended.
Original issue's description:
> Introduce v8::MicrotasksScope.
>
> This scope is used to control microtasks execution when MicrotasksPolicy::kScoped is engaged.
>
> BUG=chromium:585949
> LOG=Y
> TEST=ScopedMicrotasks
>
> Committed: https://crrev.com/db77cec242dbdf8ee26da8232fa930270429f253
> Cr-Commit-Position: refs/heads/master@{#34472}
TBR=jochen@chromium.org,adamk@chromium.org,dgozman@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:585949
Review URL: https://codereview.chromium.org/1762943002
Cr-Commit-Position: refs/heads/master@{#34480}
This scope is used to control microtasks execution when MicrotasksPolicy::kScoped is engaged.
BUG=chromium:585949
LOG=Y
TEST=ScopedMicrotasks
Review URL: https://codereview.chromium.org/1741893003
Cr-Commit-Position: refs/heads/master@{#34472}
This calback is run after an attempt to run microtasks.
BUG=chromium:585949
LOG=Y
Review URL: https://codereview.chromium.org/1731773005
Cr-Commit-Position: refs/heads/master@{#34305}
For now WasmFrame doesn't summarize the wasm frames. That'll require adding the
metadata in wasm-compiler similar to DeoptimizationInputData.
Teach the basic backtrace to iterate over stack frames instead of JS frames.
Update the wasm stack test.
`git cl format` touches random lines in files I touch.
R=titzer@chromium.org
TEST=d8 --test --expose-wasm test/mjsunit/mjsunit.js test/mjsunit/wasm/stack.js
Originally landed in: https://codereview.chromium.org/1712003003/
Reverted in: https://codereview.chromium.org/1730673002/
This patch puts the JSFunction on the C++ stack.
Review URL: https://codereview.chromium.org/1724063002
Cr-Commit-Position: refs/heads/master@{#34225}
Reason for revert:
[Sheriff] Seems to break gcmole:
https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/8295
Original issue's description:
> Add WasmFrame, backtraces reflect wasm's presence
>
> For now WasmFrame doesn't summarize the wasm frames. That'll require adding the
> metadata in wasm-compiler similar to DeoptimizationInputData.
>
> Teach the basic backtrace to iterate over stack frames instead of JS frames.
>
> Update the wasm stack test.
>
> `git cl format` touches random lines in files I touch.
>
> R=titzer@chromium.org
> TEST=d8 --test --expose-wasm test/mjsunit/mjsunit.js test/mjsunit/wasm/stack.js
>
> Committed: https://crrev.com/aeca945786dcccad3efecfddbf2c07aefa524a56
> Cr-Commit-Position: refs/heads/master@{#34220}
TBR=titzer@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,jfb@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1730673002
Cr-Commit-Position: refs/heads/master@{#34221}
For now WasmFrame doesn't summarize the wasm frames. That'll require adding the
metadata in wasm-compiler similar to DeoptimizationInputData.
Teach the basic backtrace to iterate over stack frames instead of JS frames.
Update the wasm stack test.
`git cl format` touches random lines in files I touch.
R=titzer@chromium.org
TEST=d8 --test --expose-wasm test/mjsunit/mjsunit.js test/mjsunit/wasm/stack.js
Review URL: https://codereview.chromium.org/1712003003
Cr-Commit-Position: refs/heads/master@{#34220}
This patch makes ArraySpeciesCreate fast in V8 by avoiding two property reads
when the following conditions are met:
- No Array instance has had its __proto__ reset
- No Array instance has had a constructor property defined
- Array.prototype has not had its constructor changed
- Array[Symbol.species] has not been reset
For subclasses of Array, or for conditions where one of these assumptions is
violated, the full lookup of species is done according to the ArraySpeciesCreate
algorithm. Although this is a "performance cliff", it does not come up in the
expected typical use case of @@species (Array subclassing), so it is hoped that
this can form a good start. Array subclasses will incur the slowness of looking
up @@species, but their use won't slow down invocations of, for example,
Array.prototype.slice on Array base class instances.
Possible future optimizations:
- For the fallback case where the assumptions don't hold, optimize the two
property lookups.
- For Array.prototype.slice and Array.prototype.splice, even if the full lookup
of @@species needs to take place, we still could take the rest of the C++
fastpath. However, to do this correctly requires changing the calling convention
from C++ to JS to pass the @@species out, so it is not attempted in this patch.
With this patch, microbenchmarks of Array.prototype.slice do not suffer a
noticeable performance regression, unlike their previous 2.5x penalty.
TBR=hpayer@chromium.org
Review URL: https://codereview.chromium.org/1689733002
Cr-Commit-Position: refs/heads/master@{#34199}
This new callback is similar to CallCompletedCallback, but is executed before the call has been made.
Added Isolate* parameter to CallCompletedCallback, marking previous one as deprecated.
BUG=chromium:585949
LOG=Y
Review URL: https://codereview.chromium.org/1689863002
Cr-Commit-Position: refs/heads/master@{#34167}
Frame slots indexes numbers are used more consistently for
computation in both TurboFan and Crankshaft. Specifically,
Crankshaft now uses frame slot indexes in LChunk, removing
the need for some special-case maths when building the
deoptimization translation table.
LOG=N
R=mstarzinger@chromium.org
Committed: https://crrev.com/81423b84dbb2eaf7e1a57b0f6029fc8e643b4755
Cr-Commit-Position: refs/heads/master@{#34078}
Review URL: https://codereview.chromium.org/1702593002
Cr-Commit-Position: refs/heads/master@{#34114}
The idea here is to perform the handler lookup in the deoptimizer, and then take the information from the handler table to build the catch handler frame in the deoptimizer. Specifically, we use the pc offset, context location and stack height (in full-code) to tweak the output frame.
Sadly, this still requires nasty voodoo for the liveness analyzer so that it keeps variables alive if they are used in the catch handler.
Review URL: https://codereview.chromium.org/1416543006
Cr-Commit-Position: refs/heads/master@{#33936}
Additionally list C++ builtins as well under --runtime_call_stats.
Let's try to keep all counters in one place, that makes it a bit
easier to maintain and especially discard unused ones.
BUG=
Committed: https://crrev.com/6bc71431995d49d4ca4a2ea9c75e5add5f345225
Cr-Commit-Position: refs/heads/master@{#33847}
Review URL: https://codereview.chromium.org/1678973002
Cr-Commit-Position: refs/heads/master@{#33893}
Reason for revert:
failing gc-stress tests
Original issue's description:
> Reland of [counters] moving runtime counters to counter.h (patchset #1 id:1 of https://codereview.chromium.org/1681923003/ )
>
> Reason for revert:
> This CL was not the cause for the TSAN failures, the instruction-selector backend for x64 emitted a wrong compare which accidentally showed up with tsan + code moves.
> The instruction-selectors changes have been reverted with https://codereview.chromium.org/1693433002
>
> Original issue's description:
> > Revert of [counters] moving runtime counters to counter.h (patchset #1 id:1 of https://codereview.chromium.org/1678973002/ )
> >
> > Reason for revert:
> > [Sheriff] Breaks TSAN:
> > https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/7727
> >
> > Original issue's description:
> > > [counters] moving runtime counters to counter.h
> > >
> > > Additionally list C++ builtins as well under --runtime_call_stats.
> > > Let's try to keep all counters in one place, that makes it a bit
> > > easier to maintain and especially discard unused ones.
> > >
> > > BUG=
> > >
> > > Committed: https://crrev.com/6bc71431995d49d4ca4a2ea9c75e5add5f345225
> > > Cr-Commit-Position: refs/heads/master@{#33847}
> >
> > TBR=jarin@chromium.org,cbruni@chromium.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=
> >
> > Committed: https://crrev.com/2d669b96639517cfc33e6fc6d4c3814587bc7366
> > Cr-Commit-Position: refs/heads/master@{#33848}
>
> TBR=jarin@chromium.org,machenbach@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=
>
> Committed: https://crrev.com/ad943fe44ede22b90b871e1233334dff5ff545c3
> Cr-Commit-Position: refs/heads/master@{#33887}
TBR=jarin@chromium.org,machenbach@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1687313002
Cr-Commit-Position: refs/heads/master@{#33889}
Reason for revert:
This CL was not the cause for the TSAN failures, the instruction-selector backend for x64 emitted a wrong compare which accidentally showed up with tsan + code moves.
The instruction-selectors changes have been reverted with https://codereview.chromium.org/1693433002
Original issue's description:
> Revert of [counters] moving runtime counters to counter.h (patchset #1 id:1 of https://codereview.chromium.org/1678973002/ )
>
> Reason for revert:
> [Sheriff] Breaks TSAN:
> https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/7727
>
> Original issue's description:
> > [counters] moving runtime counters to counter.h
> >
> > Additionally list C++ builtins as well under --runtime_call_stats.
> > Let's try to keep all counters in one place, that makes it a bit
> > easier to maintain and especially discard unused ones.
> >
> > BUG=
> >
> > Committed: https://crrev.com/6bc71431995d49d4ca4a2ea9c75e5add5f345225
> > Cr-Commit-Position: refs/heads/master@{#33847}
>
> TBR=jarin@chromium.org,cbruni@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=
>
> Committed: https://crrev.com/2d669b96639517cfc33e6fc6d4c3814587bc7366
> Cr-Commit-Position: refs/heads/master@{#33848}
TBR=jarin@chromium.org,machenbach@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=
Review URL: https://codereview.chromium.org/1688783005
Cr-Commit-Position: refs/heads/master@{#33887}
Additionally list C++ builtins as well under --runtime_call_stats.
Let's try to keep all counters in one place, that makes it a bit
easier to maintain and especially discard unused ones.
BUG=
Review URL: https://codereview.chromium.org/1678973002
Cr-Commit-Position: refs/heads/master@{#33847}
This makes the field in question more generic by renaming it from the
previous "depth" to "data". Pure refactoring, no function change.
R=rmcilroy@chromium.org,yangguo@chromium.org
Review URL: https://codereview.chromium.org/1670983003
Cr-Commit-Position: refs/heads/master@{#33779}
This implements proper context switching while unwinding the stack due
to an exception being handled in interpreted code. The context under
which the handler is scoped is being preserved in a dedicated register
while the try-block is running. Both, the stack unwinding machinery as
well as the graph builder, restore the context from that register.
R=rmcilroy@chromium.org,bmeurer@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1665833002
Cr-Commit-Position: refs/heads/master@{#33733}
This change adds AbstractCode, which can be either Code or
BytecodeArray, and adds methods to calculate source position based
on that. Also cleans up to use code offsets instead of raw PC
where possible, and consistently uses the offset from instruction
start (as opposed to code object start).
R=rmcilroy@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1618343002
Cr-Commit-Position: refs/heads/master@{#33579}
Rename IntepreterExceptionEntryHandler builtin to InterpreterEnterBytecodeDispatch
and use it as the return address when building interpreter frames during deopt.
This ensures that we restart execution of the outer frame at the correct
bytecode.
BUG=v8:4280,v8:4678
LOG=N
Review URL: https://codereview.chromium.org/1633633002
Cr-Commit-Position: refs/heads/master@{#33512}
In d8, run with --runtime-call-stats and it will output the stats when d8 finishes.
In Chrome, run the following: (only on trusted code, this punches *massive* security hole into Chrome)
chrome --js-flags="--runtime-call-stats --allow-natives-syntax"
To get the stats in the console, just run
console.log(%GetAndResetRuntimeCallStats());
To output stats every second:
setInterval(function() { console.log(%GetAndResetRuntimeCallStats()); }, 1000)
Review URL: https://codereview.chromium.org/1615943002
Cr-Commit-Position: refs/heads/master@{#33462}
Reason for revert:
The random nature of the tests caused the following buildbot to fail: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/4724/steps/Check/logs/stdio
Original issue's description:
> [profiler] Implement POC Sampling Heap Profiler
>
> This implements a proof-of-concept sampling based heap profiler inspired by
> tcmalloc's heap profiler [1] and Go's mprof/memprofile [2].
>
> The basic idea is the sample allocations using a randomized Poisson process. At
> any point in time we can cheaply request the set of live sample objects that
> should be a representative sample of heap. Samples include stack-traces from the
> allocation sites, making this an effective tool for memory leak debugging.
>
> Unlike AllocationTracking, this is intended to be cheap and usable online in
> production.
>
> The proof-of-concept is only sampling new-space allocations at this point.
> Support for sampling paged space and native allocations is anticipated in the
> future.
>
> [1] http://goog-perftools.sourceforge.net/doc/heap_profiler.html
> [2] http://blog.golang.org/profiling-go-programs
>
> Committed: https://crrev.com/e5a9947811db9c9e23557dbad27f8b8a349b3262
> Cr-Commit-Position: refs/heads/master@{#33448}
TBR=jochen@chromium.org,alph@chromium.org,hpayer@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1615173002
Cr-Commit-Position: refs/heads/master@{#33449}
This implements a proof-of-concept sampling based heap profiler inspired by
tcmalloc's heap profiler [1] and Go's mprof/memprofile [2].
The basic idea is the sample allocations using a randomized Poisson process. At
any point in time we can cheaply request the set of live sample objects that
should be a representative sample of heap. Samples include stack-traces from the
allocation sites, making this an effective tool for memory leak debugging.
Unlike AllocationTracking, this is intended to be cheap and usable online in
production.
The proof-of-concept is only sampling new-space allocations at this point.
Support for sampling paged space and native allocations is anticipated in the
future.
[1] http://goog-perftools.sourceforge.net/doc/heap_profiler.html
[2] http://blog.golang.org/profiling-go-programs
Review URL: https://codereview.chromium.org/1555553002
Cr-Commit-Position: refs/heads/master@{#33448}
This implements a first prototype of stack unwinding for interpreted
frames. The unwinding machinery performs a range-based lookup in the
given handler table and potentially continues dispatching at the handler
offset. Note that this does not yet correctly restore the context to the
correct value when the handler is being entered.
R=rmcilroy@chromium.org,oth@chromium.org
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1605633003
Cr-Commit-Position: refs/heads/master@{#33414}
If the profiler is started via the API and not stopped, V8 will
intermittently crash during isolate teardown.
The fix is to run the DeleteAllProfiles function in Isolate::Deinit()
if cpu_profiler_ still exists.
https://groups.google.com/forum/#!topic/v8-dev/WsIlpbaD4mo
TEST= Run in debug mode, if you start a profile and don't stop it,
this assert should fail:
Fatal error in ../src/profiler/cpu-profiler.cc, line 414
Check failed: !is_profiling_.
Review URL: https://codereview.chromium.org/1526253005
Cr-Commit-Position: refs/heads/master@{#32953}
If many threads use the same Isolate (or many Isolates) and then
terminate, their PerIsolateThreadData objects are never cleaned
up, resulting in a slow memory leak and, worse, the
PerIsolateThreadData chain getting larger and larger, adversely
affecting performance.
In this situation, embedders will now be encouraged to apply
DiscardThreadSpecificMetadata against any Isolate a thread is
done with, especially if the thread is about to terminate.
Note that it is harmless to run DiscardThreadSpecificMetadata
against an Isolate for which a thread has no thread data and
per-Isolate thread data can be reestablished if a thread starts
using an Isolate again after running DiscardThreadSpecificMetadata
against it.
It is, however, an embedder error to run
DiscardThreadSpecificMetadata against an Isolate in thread with a
Locker for the Isolate in the stack or against an Entered Isolate.
This change cannot cause any change in behavior in existing apps
as the only added coded can only be reached via the new
DiscardThreadSpecificMetadata method.
R=Jakob, jochen
BUG=
Review URL: https://codereview.chromium.org/1522703002
Cr-Commit-Position: refs/heads/master@{#32909}
We can no longer just walk the prototype chain without doing proper access-checks. When installing a proxy as the __proto__ of the global object we might accidentally end up invoking cross-realm code without access-checks (see proxies-cross-realm-ecxeption.js).
Review URL: https://codereview.chromium.org/1521953002
Cr-Commit-Position: refs/heads/master@{#32903}
No need to have an indirection to get to the initial JSArray maps from
the native context; we only cache the fast elements maps anyway, so
those could live on the native context directly. This will also
integrate nicely with the load/store propagation in TurboFan (once we
propagate the immutable flag for FieldAccess as well).
Drive-by-fix: Also don't embed any of the initial JSArray maps in
TurboFan generated code when allocating a new JSArray, but instead
always load the appropriate map from the native context. This way
we ensure that we never leak a reference to one of those maps and
its as efficient as embedding a constant map.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1516433005
Cr-Commit-Position: refs/heads/master@{#32779}
Having beefed up GetKeys() to support everything, use it for everything now.
This fixes Object.getOwnPropertyNames and Object.getOwnPropertySymbols for
Proxies, and gets rid of a bunch of code duplication.
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1498593006
Cr-Commit-Position: refs/heads/master@{#32620}
* Add a sibling interface to InterpreterAssembler called
CodeStubAssembler which provides a wrapper around the
RawMachineAssembler and is intented to make it easy to build
efficient cross-platform code stubs. Much of the implementation
of CodeStubAssembler is shamelessly stolen from the
InterpreterAssembler, and the idea is to eventually merge the
two interfaces somehow, probably moving the
InterpreterAssembler interface over to use the
CodeStubAssembler. Short-term, however, the two interfaces
shall remain decoupled to increase our velocity developing the
two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
CodeStubAssembler. Replace and remove the old Hydrogen-stub
version.
* Remove a whole slew of machinery to support JavaScript-style
code stub generation, since it ultimately proved unwieldy,
brittle and baroque. This cleanup includes removing the shared
code stub context, several example stubs and a tangle of build
file changes.
BUG=v8:4587
LOG=n
Review URL: https://codereview.chromium.org/1475953002
Cr-Commit-Position: refs/heads/master@{#32508}
Moves all files related to AST and scopes into ast/,
and all files related to scanner & parser to parsing/.
Also eliminates a couple of spurious dependencies.
R=mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1481613002
Cr-Commit-Position: refs/heads/master@{#32351}
This change binds each {Cancelable} task to a so-called {CancelableTaskManager},
which is then used to handle concurrent cancelation as well as synchronizing
shutdown for already running tasks. Since ownership of tasks is transferred to
the platform executing a task (destructor), handling in the manager uses integer
ids. Note that this also mitigates (modulo integer size) the ABA problem.
All handling of {Cancelable} tasks is now encapsulated into the corresponding
manager, which is instantiated for each isolate.
R=hpayer@chromium.org
BUG=chromium:524425
LOG=N
CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg;tryserver.v8:v8_linux_gc_stress_dbg;tryserver.v8:v8_mac_gc_stress_dbg;tryserver.v8:v8_linux64_msan_rel;tryserver.v8:v8_linux64_tsan_rel;tryserver.v8:v8_mac64_asan_rel
Review URL: https://codereview.chromium.org/1409993012
Cr-Commit-Position: refs/heads/master@{#31997}
This CL fixes several sources of non-predictability by making Platform::MonotonicallyIncreasingTime() the only bottleneck for all time-querying functions and providing PredictablePlatform implementation.
Review URL: https://codereview.chromium.org/1415383004
Cr-Commit-Position: refs/heads/master@{#31959}
This removes several methods from JSFunction that just delegate to
SharedFunctionInfo. These methods are especially dangerous when they
hide the fact that they potentially affect all function instances
deriving from the same underlying SharedFunctionInfo.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1417213005
Cr-Commit-Position: refs/heads/master@{#31792}
The stack manipulation was expensive. Two virtual registers are better.
BUG=
Review URL: https://codereview.chromium.org/1376933006
Cr-Commit-Position: refs/heads/master@{#31204}
The --abort-on-uncaught-exception command line switch makes
Isolate::Throw abort if the error being thrown cannot be caught by a
try/catch block.
Embedders may want to use other mechanisms than try/catch blocks to
handle uncaught exceptions. For instance, Node.js has "domain" objects
that have error handlers that can handle uncaught exception like
following:
var d = domain.create();
d.on('error', function onError(err) {
console.log('Handling error');
});
d.run(function() {
throw new Error("boom");
});
These error handlers are called by isolates' message listeners.
If --abort-on-uncaught-exception is *not* used, the isolate's
message listener will be called, which will in turn call the domain's
error handler. The process will output 'Handling error' and will exit
successfully (not due to an uncaught exception). This is the behavior
that Node.js users expect.
However, if --abort-on-uncaught-exception is used and when throwing an
error within a domain that has an error handler, the process will abort
and the domain's error handler will not be called. This is not the
behavior that Node.js users expect.
Having a SetAbortOnUncaughtExceptionCallback API allows embedders to
determine when it's not appropriate to abort and instead handle the
exception via the isolate's message listener.
In the example above, Node.js would set a custom callback with
SetAbortOnUncaughtExceptionCallback that would be implemented as
following (the sample code has been simplified to remove what's not
relevant to this change):
bool ShouldAbortOnUncaughtException(Isolate* isolate) {
return !IsDomainActive();
}
Now when --abort-on-uncaught-exception is used, Isolate::Throw would
call that callback and determine that it should not abort if a domain
with an error handler is active. Instead, the isolate's message listener
would be called and the error would be handled by the domain's error
handler.
I believe this can also be useful for other embedders.
BUG=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1375933003
Cr-Commit-Position: refs/heads/master@{#31111}
Replacing it with SMI_ACCESSORS.
This change makes accesses to Smi fields in objects more regular (the
accessors now always consume/return an int rather than a Smi*), which
avoids a bunch of manual Smi::FromInt() and Smi::value() conversions,
and is a step on the way towards being able to generate objects-inl.h.
Review URL: https://codereview.chromium.org/1371893002
Cr-Commit-Position: refs/heads/master@{#30975}
(reason for revert/reland: patch incorrectly left --vector-stores flag
on, helpfully revealing some gcstress issues to look at, but they
don't need to block this CL).
Some pretty hacky code was used to carry out the tail-call
handler dispatch on ia32 vector stores due to a lack
of free registers. It really tanks performance. A better
approach is to use a virtual register on the isolate.
BUG=
TBR=jkummerow@chromium.org, vogelheim@chromium.org
Review URL: https://codereview.chromium.org/1346573002
Cr-Commit-Position: refs/heads/master@{#30737}
Some pretty hacky code was used to carry out the tail-call
handler dispatch on ia32 vector stores due to a lack
of free registers. It really tanks performance. A better
approach is to use a virtual register on the isolate.
BUG=
Review URL: https://codereview.chromium.org/1336313002
Cr-Commit-Position: refs/heads/master@{#30718}
This removes the DisallowAllocationFailure assertion scope which mostly
coincided with the AlwaysAllocateScope anyways. Access to the bitfield
in the Isolate was not synchronized and hence the AlwaysAllocateScope
was not thread-safe in debug mode, now it is.
R=mlippautz@chromium.org
Review URL: https://codereview.chromium.org/1319153006
Cr-Commit-Position: refs/heads/master@{#30637}
This switches Isolate::ComputeLocation to use baseline code when
computing message locations. This unifies locations between optimized
and non-optimized code by always going through the FrameSummary for
location computation.
R=bmeurer@chromium.org
TEST=message/regress/regress-4266
BUG=v8:4266
LOG=n
Review URL: https://codereview.chromium.org/1331603002
Cr-Commit-Position: refs/heads/master@{#30635}
This CL us a pure refactoring that makes an empty compilation unit
including just "isolate.h" or "contexts.h" but not "objects-inl.h"
compile without warnings or errors. This is needed to further reduce
the header dependency tangle.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1322883002
Cr-Commit-Position: refs/heads/master@{#30500}
We can use the script type to determine that instead. Script of type
TYPE_NATIVE are considered builtins, TYPE_NORMAL are not. The only exception
to this rule is the empty function, for which the script is TYPE_NATIVE
(observable by the debugger), but should be stringified to "function () {}"
instead of "function () { [native code] }". For this, I introduce a
hide_source flag on the script object.
We also use IsBuiltin and IsSubjectToDebugging interchangeably. For debugger,
we now use the latter, hiding the detail that only non-builtins are debuggable.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1292283004
Cr-Commit-Position: refs/heads/master@{#30285}
We currently have several ways to share symbols that are used in
both native scripts and the runtime. This change unifies this.
We do not use the symbols registry since we don't need the
registry any longer after bootstrapping, but the registry stays
alive afterwards.
R=mlippautz@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1293493004
Cr-Commit-Position: refs/heads/master@{#30280}
The interpreter needs to be initialized after the snapshot has been deserialized.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1290883004
Cr-Commit-Position: refs/heads/master@{#30190}
Moves the creation of the interpreter table early on during initialization
to ensure that even on nosnap builds it still gets allocated in the
first page.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1278413002
Cr-Commit-Position: refs/heads/master@{#30096}
This is a first step towards constraining down the heap interface to
just the heap.h file. Note that many includes still leak through that
file to the global "src" directory, but there now is a single place
controlling which declarations leak that way. Especially inclusion of
inline header files within "heap" has been limited drastically.
R=hpayer@chromium.org,mlippautz@chromium.org
Review URL: https://codereview.chromium.org/1281233003
Cr-Commit-Position: refs/heads/master@{#30092}
Per discussion on the bug, the DCHECK'd case actually occurs in normal
operation, outside of V8's control.
BUG=chromium:388244
LOG=n
Review URL: https://codereview.chromium.org/1255043002
Cr-Commit-Position: refs/heads/master@{#29877}
Adds basic support for generation of interpreter bytecode handler code
snippets. The InterpreterAssembler class exposes a set of low level,
interpreter specific operations which can be used to build a Turbofan
graph. The Interpreter class generates a bytecode handler snippet for
each bytecode by assembling operations using an InterpreterAssembler.
Currently only two simple bytecodes are supported: LoadLiteral0 and Return.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1239793002
Cr-Commit-Position: refs/heads/master@{#29814}
Until now, TF-generated code stubs piggy-backed off of the builtin
context. Since generation of code stubs is lazy, stubs generated at
different times in different native contexts would contain embedded
pointers different builtin contexts, leading to cross-context references
and memory leaks.
After this CL, all TF-generated code stubs are generated inside a
internal thinned-out, native context that lives solely for the
purpose of hosting generated code stubs.
Review URL: https://codereview.chromium.org/1213203007
Cr-Commit-Position: refs/heads/master@{#29593}
We now consistently ignore native and extension scripts for debugging. Only native scripts and extension scripts can disallow lazy compilation. So we can make sure that break points are only set to code that are compiled with debug break slots.
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1216193002
Cr-Commit-Position: refs/heads/master@{#29400}
Two changes:
- In ReportBootstrappingException, if all we have is a string, it seems
better to print that than nothing.
- In Factory::NewError, there's no use trying to call into the builtins if
compilation of the builtins is causing the exception (this currently
results in a cryptic segfault if we trigger, say, a ReferenceError when
executing builtins script during bootstrapping).
Review URL: https://codereview.chromium.org/1158013003
Cr-Commit-Position: refs/heads/master@{#28912}
Boolean "is_strong" parameters have begun to proliferate across areas where
strong mode semantics are different. This CL repurposes the existing
ObjectStrength enum as a replacement for them.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1144183004
Cr-Commit-Position: refs/heads/master@{#28839}
When compiling on a laptop I like to concatenate the small test files.
This makes a big difference to compile times. These changes make that
easier.
R=ulan@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1163803002
Cr-Commit-Position: refs/heads/master@{#28742}
* Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols.
* In the long run we should do all hidden properties this way and get rid of the
hidden magic 0-length string with the zero hash code. The advantages include
less complexity and being able to do things from JS in a natural way.
* Initially, the performance of weak set regressed, because it's a little harder
to do the lookup in C++. Instead of heroics in C++ to make things faster I
moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects.
* This also changes hash codes of Smis so that they are always Smis.
Performance figures are in the comments to the code review. Summary: Most of js-perf-test/Collections is neutral. Set and Map with object keys are 40-50% better. WeakMap is -5% and WeakSet is +9%. After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(.
In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this. Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately). With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win.
In a similar vein we could give the magic zero hash code to the hash code
symbol. Then when we look up the hash code we would sometimes see the table
with all the hidden properties. This dual use of the field for either the hash
code or the table with all hidden properties and the hash code is rather ugly,
and this CL gets rid of it. I'd be loath to bring it back. On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL.
One worry is that the benchmark results above are more monomorphic than real
world code, so may be overstating the performance benefits of moving to JS. I
think this is part of a general issue we have with handling polymorphic code in
JS and any solutions there will benefit this solution, which boils down to
regular property access. Any improvement there will lift all boats.
R=adamk@chromium.org, verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1149863005
Cr-Commit-Position: refs/heads/master@{#28622}
Alas, this involved quite a bit of copy-n-paste between the
architectures, but this is caused by the very convoluted
relationships, lifetimes and distribution of responsibilities. This
should really be cleaned up by moving code around and using STL maps,
but that's not really a priority right now.
Bonus: Fixed leaks in the ARM64 disassembler tests.
Review URL: https://codereview.chromium.org/1132943007
Cr-Commit-Position: refs/heads/master@{#28496}
The functions of strong classes are born non extensible. But, when
the class is created we need to add an own private symbol representing
the [[HomeObject]] slot in the spec.
Like for the hidden_string property, we allow adding private own
symbols to non extensible objects.
BUG=v8:4077
LOG=N
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1138603003
Cr-Commit-Position: refs/heads/master@{#28447}
When we preprocess stack traces, we turn code pointer and offset to
source position, and store it in place of code pointer as smi.
Preprocessing stack traces is currently disabled due to issue 4065.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1125723002
Cr-Commit-Position: refs/heads/master@{#28213}
If the array's map is the initial FastHoley array map, and the array prototype
chain is undisturbed and empty of elements, then keyed loads can convert the
load of a hole to undefined.
BUG=
Review URL: https://codereview.chromium.org/1100083002
Cr-Commit-Position: refs/heads/master@{#28056}
Reason for revert:
This was probably an infrastructure problem caused by the mac ninja/goma switch.
Original issue's description:
> Revert of Protect the emptiness of Array prototype elements with a PropertyCell. (patchset #7 id:120001 of https://codereview.chromium.org/1092043002/)
>
> 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
TBR=jkummerow@chromium.org,mvstanton@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4044
Review URL: https://codereview.chromium.org/1052253003
Cr-Commit-Position: refs/heads/master@{#28000}
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}
This fixes a race where
- mutator changes the fixed array length by trimming it,
- sweeper thread reads the length of the fixed array.
Also rename FROM_GC and FROM_MUTATOR to be more precise.
BUG=chromium:462908
LOG=NO
Review URL: https://codereview.chromium.org/1034163002
Cr-Commit-Position: refs/heads/master@{#27869}
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}
The motivation is that we prefer to avoid creating internal properties, and we have a usable field on maps ("transitions", which is not used for prototype maps).
This CL also ensures the invariant that prototype maps are never shared, even if they are in dictionary mode.
Review URL: https://codereview.chromium.org/1033653002
Cr-Commit-Position: refs/heads/master@{#27617}
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}
Error.stack contains function.name if its type is string.
Otherwise if function have inferred name then .stack contains it.
For functions from eval .stack property contains "eval".
LOG=N
BUG=chromium:17356
R=yurys@chromium.org
Review URL: https://codereview.chromium.org/919653002
Cr-Commit-Position: refs/heads/master@{#27186}
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 reduces the size of the StackHandler by yet another word. We no
longer need to keep track of the frame pointer, as the stack walk will
be able to recalculate it.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/991893003
Cr-Commit-Position: refs/heads/master@{#27115}
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}
This reduces the size of the StackHandler by one word. We no longer
need to keep track of the code object, as the stack walk finds it.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/985803002
Cr-Commit-Position: refs/heads/master@{#27103}
If function.name property has string type then stack frame will contain it otherwise DebugName from shared function info.
BUG=17356
LOG=Y
R=yurys@chromium.org
Review URL: https://codereview.chromium.org/917743002
Cr-Commit-Position: refs/heads/master@{#27025}
This extends the stack unwinding logic to respect optimized frames
and perform a lookup in the handler table to find handlers. It also
contains fixes to the API call stubs to allow a stack walk while
promoting scheduled exceptions.
R=jarin@chromium.org
TEST=cctest/test-run-jsexceptions
Review URL: https://codereview.chromium.org/969533004
Cr-Commit-Position: refs/heads/master@{#27016}
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}
This enables adding more language modes in the future.
For maximum flexibility, LanguageMode is a bitmask, so we're not restricted to
use a sequence of language modes which are progressively stricter, but we can
express the language mode as combination of features.
For now, LanguageMode can only be "sloppy" or "strict", and there are
STATIC_ASSERTS in places which need to change when more modes are added.
LanguageMode is a bit like the old LanguageMode when "extended" mode was still
around (see https://codereview.chromium.org/8417035 and
https://codereview.chromium.org/181543002 ) except that it's transmitted through
all the layers (there's no StrictModeFlag).
BUG=
Review URL: https://codereview.chromium.org/894683003
Cr-Commit-Position: refs/heads/master@{#26419}
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}
Along the way:
- Thread isolate parameter explicitly through code that used to
rely on getting it from the zone.
- Canonicalize the parameter position of isolate and zone for
affected code
- Change Hydrogen New<> instruction templates to automatically
pass isolate
R=mstarzinger@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/868883002
Cr-Commit-Position: refs/heads/master@{#26252}
(1) --prof-cpp: Collects ticks like --prof, but ignores code creation events to reduce distortion (so all JS ticks will be "unaccounted"). Useful for profiling C++ code.
(2) --timed-range flag for tick processor: Ignores ticks before the first and after the last call to Date.now(). Useful for focusing on the timed section of a test.
Review URL: https://codereview.chromium.org/802333002
Cr-Commit-Position: refs/heads/master@{#26168}
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
The callbacks are per isolate, so we shouldn't get the isolate implicitly
from TLS. Also, we shouldn't allow calls to these methods prior to
initializing the respective isolate (and silently ignore them).
Esp. add a per-isolate API to set the stats counter callbacks and
make it possible to set the stats counter callback after the isolate
was touched.
Embedders should use e.g. isolate->SetCounterFunction(callback) instead
of v8::V8::SetCounterFunction(callback).
BUG=none
R=svenpanne@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/365153002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22223 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This adds timestamps to allow profiling with code space reuse. Also a couple of updates to reflect the changes in the JIT perf interface + a move of the perf-related stuff into separate files.
Unfortunately, the change only works with the latest patch to the perf tool from a Linux perf tool contributor (Stephane Eranian).
BUG=
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/255803003
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22098 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a step in the direction of disentangling all uses of SetOwnPropertyIgnoreAttributes so we can provide a more specific implementation for those usecases, and reduce the capabilities of those clients, avoiding subtle bugs.
InitializeProperty only supports adding properties to extensible objects that do not contain the property yet. JSGlobalProxies cannot have properties themselves, so are not supported either.
BUG=
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/352813002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22095 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
