Previously the String constructor and the Symbol.prototype.toString
methods had to compute the descriptive string for a Symbol on the fly,
which can produce a lot of garbage when this happens a lot, i.e. when
the String representation of a Symbol is used often. Now instead of
doing this on-demand we can just do it upfront when creating the Symbol.
That way we also ensure that we won't throw an exception when accessing
the descriptive string of a Symbol, due to potential String length
overflow, but have the exception during Symbol creation upfront, which
is a lot less surprising behavior.
BUG=v8:6278,v8:6344,v8:6350
TBR=mlippautz@chromium.orgR=ishell@chromium.org
Review-Url: https://codereview.chromium.org/2900703002
Cr-Commit-Position: refs/heads/master@{#45479}
Generate the code (extra runtime calls) for --trace-ignition support at
compile time, based on a #define (similar to TRACE_MAPS). Then check for
--trace-ignition at run-time when deciding whether to actually print
anything. This should make --trace-ignition less painful to use.
Note that --trace-igition is disabled by default, even on debug builds.
It has to be enabled with the gn arg "v8_enable_trace_ignition=true"
As a drive-by, TRACE_MAPS is renamed to V8_TRACE_MAPS, for consistency,
and SFI unique index (needed both by --trace-ignition and --trace-maps)
is cleaned up to be behind another #define.
Change-Id: I8dd0c62d0e6b7ee9c75541d45eb729dc03acbee9
Reviewed-on: https://chromium-review.googlesource.com/506203
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45346}
Crankshaft flag and opt flag mostly serve the same purpose. Using
crankshaft to mean use optimizing compiler is a bit confusing.
This cl: https://chromium-review.googlesource.com/c/490206/ fixes
the tests to use opt instead of crankshaft flag.
One difference between --no-crankshaft and --no-opt would be that
--no-opt would mean no optimizations at all where as with --no-crankshaft
would mean we can force optimizations using %OptimizeFunctionOnNextCall.
Bug: v8:6325
Change-Id: If17393ac5b6af4ea6e9a98e092f0261c2e0899c5
Reviewed-on: https://chromium-review.googlesource.com/490307
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45298}
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
BUG=v8:6246,chromium:718891
TBR=yangguo@chromium.org,ulan@chromium.org
Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6
Reviewed-on: https://chromium-review.googlesource.com/500134
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45234}
This reverts commit 662aa425ba.
Reason for revert: Crashing on Canary
BUG=chromium:718891
Original change's description:
> Reland: [TypeFeedbackVector] Store optimized code in the vector
>
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
>
> Original patch by Michael Stanton <mvstanton@chromium.org>
>
> BUG=v8:6246
> TBR=yangguo@chromium.org,ulan@chromium.org
>
> Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
> Reviewed-on: https://chromium-review.googlesource.com/494487
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45084}
TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=v8:6246
Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82
Reviewed-on: https://chromium-review.googlesource.com/498633
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45174}
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
BUG=v8:6246
TBR=yangguo@chromium.org,ulan@chromium.org
Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
Reviewed-on: https://chromium-review.googlesource.com/494487
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45084}
CopyFixedArrayAndGrow can trigger GC, which can clean up
previous detached contexts, so storing the length of the
FixedArray across the allocation is unsafe.
BUG=v8:6282
Review-Url: https://codereview.chromium.org/2857633002
Cr-Commit-Position: refs/heads/master@{#45038}
This reverts commit c5ad9c6d8e.
Reason for revert: Fails on gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/12661
Original change's description:
> [TypeFeedbackVector] Store optimized code in the vector
>
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
>
> Original patch by Michael Stanton <mvstanton@chromium.org>
>
> BUG=v8:6246
>
> Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5
> Reviewed-on: https://chromium-review.googlesource.com/476891
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45022}
TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,mvstanton@chromium.org,jarin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6246
Change-Id: I9cd5735b03898cae6ae7adea0f19d32fceb31619
Reviewed-on: https://chromium-review.googlesource.com/493287
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45027}
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
BUG=v8:6246
Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5
Reviewed-on: https://chromium-review.googlesource.com/476891
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45022}
This patch adds a new interface called RootVisitor and changes the root
iteration functions to accept a RootVisitor instead of an ObjectVisitor.
Future CLs will change ObjectVisitor to provide the host object to all
visiting functions, which will bring it in sync with static visitors.
Having separate visitors for roots and objects removes ambiguity in
VisitPointers and reduces chances of forgetting to record slots.
This is intended as pure refactoring. All places that require behavior
change are marked with TODO and will addressed in future CLs.
BUG=chromium:709075
Review-Url: https://codereview.chromium.org/2801073006
Cr-Commit-Position: refs/heads/master@{#44852}
This patch implements the runtime semantics of dynamic import.
We create a new ASTNode so that we can pass the JSFunction closure() to
the runtime function from which we get the script_url.
d8 implements the embedder logic required to load and evaluate the modules.
The API is mostly implemented as specified.
BUG=8:5785
Review-Url: https://codereview.chromium.org/2703563002
Cr-Commit-Position: refs/heads/master@{#44551}
Force passing arguments on the stack for PushCodeObjectsAndDie by using
more function arguments.
Change-Id: I7a2e825f3423946a03f5dd988c640a37709f32e3
Reviewed-on: https://chromium-review.googlesource.com/472747
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44523}
We don't need to do any kind of translation for non-wasm frames. And we need this knowledge for lazy symbolization.
Capturing stack trace is ~7% faster.
BUG=v8:6189
R=dgozman@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2795103004
Cr-Commit-Position: refs/heads/master@{#44502}
Split TFS builtins into
* TFC: TF builtins with stub linkage that use a custom interface descriptor
(e.g. because of a non-standard return size or untagged arguments)
* TFS: the rest.
Automatically generate interface descriptors for TFS builtins to reduce
boilerplate involved in setting up stub calls. These are now as simple as
creating the TFS stub and using CSA::CallBuiltin, no extra work required.
BUG=v8:6116
Review-Url: https://codereview.chromium.org/2777203007
Cr-Commit-Position: refs/heads/master@{#44490}
and out of the main library. This saves about 5% of binary size
(800KB on x64, 373KB on android_arm).
Only the GN build is supported; the GYP build is maintained working
but does not support the feature.
Previously landed as 4782bc0df8 / r44412.
BUG=v8:6055
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_nosnap_rel;
Review-Url: https://codereview.chromium.org/2760233005
Cr-Commit-Position: refs/heads/master@{#44489}
InternalResolvePromise, InternalPromiseReject and
InternalPerformPromiseThen generate quite a lot of code.
This change adds 3 new TF stubs which inline calls to these builtins.
These stubs are invoked rather than inlining those operations listed
above directly. This is done for Async Iteration builtins, as well as
Async Function builtins. Promise builtins are left as they were, and
continue to inline these calls.
This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
release build.
BUG=v8:5855
R=gsathya@chromium.org, jgruber@chromium.org
Change-Id: I83e2f096782db685fe316dd071980cd8d696fe53
Reviewed-on: https://chromium-review.googlesource.com/469927
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44483}
This reverts commit 9461fe249e.
Reason for revert: Breaks a test in Node.js:
parallel/test-util-inspect
=== release test-util-inspect ===
Path: parallel/test-util-inspect
#
# Fatal error in , line 0
# unreachable code
#
==== C stack trace ===============================
Original change's description:
> [builtins] don't inline calls for common Promise ops in async builtins
>
> InternalResolvePromise, InternalPromiseReject and
> InternalPerformPromiseThen generate quite a lot of code.
>
> This change adds 3 new TF stubs which inline calls to these builtins.
> These stubs are invoked rather than inlining those operations listed
> above directly. This is done for Async Iteration builtins, as well as
> Async Function builtins. Promise builtins are left as they were, and
> continue to inline these calls.
>
> This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
> release build.
>
> BUG=v8:5855
> R=gsathya@chromium.org, jgruber@chromium.org
>
> Change-Id: I3349d0f0353a72270ae40b974312d64d1c8a9e46
> Reviewed-on: https://chromium-review.googlesource.com/461269
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Sathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44445}
TBR=mstarzinger@chromium.org,gsathya@chromium.org,caitp@igalia.com,jgruber@chromium.org,v8-reviews@googlegroups.com,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5855
Change-Id: Iabcdf8b025cc9b053a858f8e74389638ac000ba0
Reviewed-on: https://chromium-review.googlesource.com/469946
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44448}
InternalResolvePromise, InternalPromiseReject and
InternalPerformPromiseThen generate quite a lot of code.
This change adds 3 new TF stubs which inline calls to these builtins.
These stubs are invoked rather than inlining those operations listed
above directly. This is done for Async Iteration builtins, as well as
Async Function builtins. Promise builtins are left as they were, and
continue to inline these calls.
This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
release build.
BUG=v8:5855
R=gsathya@chromium.org, jgruber@chromium.org
Change-Id: I3349d0f0353a72270ae40b974312d64d1c8a9e46
Reviewed-on: https://chromium-review.googlesource.com/461269
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Sathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44445}
Doing so will increase the likelyhood of getting the interesting code objects
into the mindump.
Change-Id: I6c6d06bbfe7ab8649139b1146bda0f9b3d679064
Reviewed-on: https://chromium-review.googlesource.com/468967
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44444}
Reason for revert:
I think that this CL breaks chromium compilation on windows with clang (). All other CLs in the list looks trivial and don't change test/unittest/BUILD.gn.
[42456/47924] CXX obj/v8/test/unittests/unittests/value-serializer-unittest.obj
[42457/47924] LINK unittests.exe unittests.exe.pdb
FAILED: unittests.exe unittests.exe.pdb
E:/b/depot_tools/python276_bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./unittests.exe /PDB:./unittests.exe.pdb @./unittests.exe.rsp
bitmap-unittest.obj : error LNK2019: unresolved external symbol "public: void __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::Add(class v8::internal::AllocationObserver * const &,class v8::internal::FreeStoreAllocationPolicy)" (?Add@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAAXAEBQEAVAllocationObserver@23@VFreeStoreAllocationPolicy@23@@Z) referenced in function "public: virtual void __cdecl v8::internal::Space::AddAllocationObserver(class v8::internal::AllocationObserver *)" (?AddAllocationObserver@Space@internal@v8@@UEAAXPEAVAllocationObserver@23@@Z)
slot-set-unittest.obj : error LNK2001: unresolved external symbol "public: void __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::Add(class v8::internal::AllocationObserver * const &,class v8::internal::FreeStoreAllocationPolicy)" (?Add@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAAXAEBQEAVAllocationObserver@23@VFreeStoreAllocationPolicy@23@@Z)
bitmap-unittest.obj : error LNK2019: unresolved external symbol "public: bool __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::RemoveElement(class v8::internal::AllocationObserver * const &)" (?RemoveElement@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAA_NAEBQEAVAllocationObserver@23@@Z) referenced in function "public: virtual void __cdecl v8::internal::Space::RemoveAllocationObserver(class v8::internal::AllocationObserver *)" (?RemoveAllocationObserver@Space@internal@v8@@UEAAXPEAVAllocationObserver@23@@Z)
slot-set-unittest.obj : error LNK2001: unresolved external symbol "public: bool __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::RemoveElement(class v8::internal::AllocationObserver * const &)" (?RemoveElement@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAA_NAEBQEAVAllocationObserver@23@@Z)
./unittests.exe : fatal error LNK1120: 2 unresolved externals
Original issue's description:
> [snapshot] Move builtins generation into mksnapshot
>
> and out of the main library. This saves about 5% of binary size
> (800KB on x64, 373KB on android_arm).
>
> Only the GN build is supported; the GYP build is maintained working
> but does not support the feature.
>
> BUG=v8:6055
> CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_nosnap_rel;
>
> Review-Url: https://codereview.chromium.org/2760233005
> Cr-Commit-Position: refs/heads/master@{#44412}
> Committed: 4782bc0df8TBR=jgruber@chromium.org,rmcilroy@chromium.org,machenbach@chromium.org,jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6055
Review-Url: https://codereview.chromium.org/2803903002
Cr-Commit-Position: refs/heads/master@{#44422}
and out of the main library. This saves about 5% of binary size
(800KB on x64, 373KB on android_arm).
Only the GN build is supported; the GYP build is maintained working
but does not support the feature.
BUG=v8:6055
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_nosnap_rel;
Review-Url: https://codereview.chromium.org/2760233005
Cr-Commit-Position: refs/heads/master@{#44412}
Make sure that we call the destructors on all embedded object by
replacing the WasmInterpreterInternals::Delete method by an actual
destructor. This way, the compiler automatically calls destructors on
all embedded objects, in particular the IdentityMap in the CodeMap.
This change also requires to release managed objects *before*
tearing down the heap, because the wasm interpreter, referenced via
Managed<>, contains global handles. When those are destroyed, the
isolate still needs to be intact.
Drive-by: Fix include guard in managed.h.
R=ahaas@chromium.org, ulan@chromium.org, mvstanton@chromium.org
BUG=v8:5822
Change-Id: I9a067f037e013c84e4d697a1e913b27c683bb529
Reviewed-on: https://chromium-review.googlesource.com/466187
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44368}
JSObject is slow: creating strings for keys and storing values by these keys after takes significant amount of time.
With this CL console methods (most of them collect top stack frame to calculate source location) are ~33% faster.
V8Debugger::captureStackTrace is ~50% faster.
BUG=v8:6189
R=yangguo@chromium.orgTBR=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2789073002
Cr-Commit-Position: refs/heads/master@{#44344}
Add a limit to the number of nested call frames in the C++ wasm
interpreter.
Both the size of the value stack as well as the size of the block stack
are limited per call frame. Thus, a limit on only the call frame stack
is enough to limit the overall memory consumption of one interpreter
instance.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: If9f7e547cd1d003bc2ae3c7586ece6b3cf3be587
Reviewed-on: https://chromium-review.googlesource.com/463486
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44296}
V8 side mechanism for overriding the wasm js APIs.
We will use these to:
- implement the Chrome-side constraints on module size, and throw with more
actionable error messages, while preserving layering.
The old mechansms will be deleted once we update the Chrome side with
this new mechanism.
- implement Chrome-side .compile and .instantiate overrides accepting
Response objects.
We may want to evolve this mechanism into something more general, not
requiring V8 preparation, by replacing the v8-definition with embedder
provided definitions. We're currently exploring if we can expand
"Extras", for instance.
BUG=
Review-Url: https://codereview.chromium.org/2773063002
Cr-Commit-Position: refs/heads/master@{#44119}
Indisputable profit:
- correct break location in next task (see tests),
- stepOver with async await never lands in random code (see related test and issue),
- inspector doesn't store current stepping state in debugger agent and completely trust V8 - step to new inspector-V8 design (I will finish design doc soon).
- willExecuteScript and didExecuteScript instrumentation could be removed from code base - reduce probability of future errors.
- finally - less code,
- stepping implementation in V8 makes another step to follow our stepping strategy (stepOut should do stepInto and break when exit current frame) (another one one page design doc based on @aandrey comment is coming),
- knowledge about existing of context groups is still inspector-only.
Disputable part is related to super rare scenario when in single isolate we have more then one context group id with enabled debugger agent:
- if one agent request break in own context (stepping, pause, e.t.c.) then we ignore all breaks in another agent. From one hand it looks like good: user clicks stepInto and they don't expect that execution could be paused by another instance of DevTools in unobservable from current DevTools way (second DevTools will get paused notification and run nested message loop). From another hand we shouldn't ignore breakpoints or debugger statement never. In general, I think that proposed behavior is rathe feature then issue.
- and disadvantage, on attempt to break in non-target context group id we just call StepOut until reach target context group id, step out call could deoptimize code in non related to current debugger agent context. But break could happens only in case of debugger stmt or breakpoint - sound like minor issue. Ignoring break on exception sounds like real issue but by module of rareness of this case I think we can ignore this.
Implementation details:
- when debugger agent request break for any reason it passes target context group id to V8Debugger - last agent requesting break is preferred.
- when V8Debugger gets BreakProgramRequested notification from V8, it checks current context group id against target context group id, if they match then just process break as usual otherwise makes StepOut action,
- debug.cc at the end of microtask if last_scheduled_action is StepOut, schedules StepIn and will break on first instruction in next task.
BUG=chromium:654022
R=dgozman@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2748503002
Cr-Commit-Position: refs/heads/master@{#44034}
The old method always returned a Handle<Object>, requiring an explicit
cast in the caller. This CL makes it return Handle<T> if called with a
T* as parameter.
Also, remove now redundant casts from callers.
R=bmeurer@chromium.org
Change-Id: I13cfb2f2e812e8582a9a1d9d6c8a5a24f40d0e79
Reviewed-on: https://chromium-review.googlesource.com/458376
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44012}
This CL makes the interpreter reentrant by allowing different
activations to be live at the same time. The wasm interpreter keeps a
list of activations and stores the stack height at the start of each
activation. This information is used to unwind just one activation, or
show the right portion of the interpreter stack for each interpreter
entry frame.
The WasmDebugInfo object stores a mapping from frame pointer (of the
interpreter entry) to the activation id in order to identify the
activation based on the physical interpreter entry frame.
R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5822
Change-Id: Ibbf93f077f907213173a92e0a2f7f3556515e8eb
Reviewed-on: https://chromium-review.googlesource.com/453958
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43976}
If an exception is thrown and the wasm interpreter entry frame is
unwound, also the internal frames in the interpreter need to be unwound.
We did not do so before, leaving a corrupted internal state of the wasm
interpreter. Thus reusing it would fail.
This CL fixes this and adds a test which reenters a previously unwound
wasm interpreter. It checks that this works and the correct stack is
returned.
This test also requires support for calling an imported function which
throws, so this change is also included here.
R=ahaas@chromium.org, titzer@chromium.org
BUG=v8:5822
Change-Id: I12fb843f7a371a4e618b4ac63ed3299667a03a82
Reviewed-on: https://chromium-review.googlesource.com/453938
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43937}
This is a first step towards moving Turbofan code generation off the main thread.
Summary of the changes:
- AssemblerBase no longer has a pointer to the isolate. Instead, its
constructor receives the few things that it needs from the isolate (on most
architectures this is just the serializer_enabled flag).
- RelocInfo no longer has a pointer to the isolate. Instead, the functions
that need it take it as an argument. (There are currently still a few that
implicitly access the isolate through a HeapObject.)
- The MacroAssembler now explicitly holds a pointer to the isolate (before, it
used to get it from the Assembler).
- The jit_cookie also moved from AssemblerBase to the MacroAssemblers, since
it's not used at all in the Assemblers.
- A few architectures implemented parts of the Assembler with the help
of a Codepatcher that is based on MacroAssembler. Since the Assembler no
longer has the isolate, but the MacroAssembler still needs it, this doesn't
work anymore. Instead, these Assemblers now use a new PatchingAssembler.
BUG=v8:6048
Review-Url: https://codereview.chromium.org/2732273003
Cr-Commit-Position: refs/heads/master@{#43890}
Since TrapIf has been implemented on all platforms, there is no need
anymore for the old WasmTrapHelper code. This CL also removes
TrapIf-specific tests.
R=titzer@chromium.org, clemensh@chromium.org
Change-Id: Ic069598441b7bd63bde2e66f4e536abea5ecebe6
Reviewed-on: https://chromium-review.googlesource.com/452380
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43887}
Before adding stack unwinding of interpreted wasm frames, clean up the
respective method a bit.
Replace if-cascade by a switch, and inline the (previously public)
RemoveMaterializedObjectsOnUnwind method.
R=mstarzinger@chromium.org, jarin@chromium.org
BUG=v8:5822
Change-Id: Icf80c4adadc2f43551656ced8e92a67752d5c471
Reviewed-on: https://chromium-review.googlesource.com/453898
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43860}
In Isolate::CaptureSimpleStackTrace, we were ignoring interpreter entry
frames so far. This CLs changes this to gets the interpreted stack from
the wasm interpreter and add the frames to the FrameArray.
R=ahaas@chromium.org, titzer@chromium.org
BUG=v8:5822
Change-Id: I705909532ff28af412ff809da94522866eaa1c0d
Reviewed-on: https://chromium-review.googlesource.com/452378
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43772}
This is basically the minimum viable signal handler for Wasm bounds checks.
It includes the TLS check and the fine grained instructions checks. These
two checks provide most of the safety for the signal handler. Future CLs will
add code range and data range checks for more robustness.
The trap handling code and data structures are all in src/trap-handler, with
the code that actually runs in the signal handler confined to
src/trap-handler/signal-handler.cc.
This changes adds a new V8 API that the embedder should call from a signal
handler that will give V8 the chance to handle the fault first. For hosts that
do not want to implement their own signal handler, we include the option to
install a simple one. This simple handler is also used for the tests.
When a Wasm module is instantiated, information about each function is passed
to the trap handler, which is used to classify faults. These are removed during
the instance finalizer.
Several future enhancements are planned before turning this on by default.
Obviously, the additional checks will be added to MaybeHandleFault. We are
also planning to add a two-level CodeObjectData table that is grouped by
isolates to make cleanup easier and also reduce potential for contending on
a single data structure.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
Review-Url: https://codereview.chromium.org/2371833007
Cr-Original-Original-Commit-Position: refs/heads/master@{#43523}
Committed: a5af7fe9ee
Review-Url: https://codereview.chromium.org/2371833007
Cr-Original-Commit-Position: refs/heads/master@{#43755}
Committed: 338622d7ca
Review-Url: https://codereview.chromium.org/2371833007
Cr-Commit-Position: refs/heads/master@{#43759}
Reason for revert:
ASAN breakage, such as https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/19111/steps/Check/logs/grow-memory
Original issue's description:
> [wasm] Initial signal handler
>
> This is basically the minimum viable signal handler for Wasm bounds checks.
> It includes the TLS check and the fine grained instructions checks. These
> two checks provide most of the safety for the signal handler. Future CLs will
> add code range and data range checks for more robustness.
>
> The trap handling code and data structures are all in src/trap-handler, with
> the code that actually runs in the signal handler confined to
> src/trap-handler/signal-handler.cc.
>
> This changes adds a new V8 API that the embedder should call from a signal
> handler that will give V8 the chance to handle the fault first. For hosts that
> do not want to implement their own signal handler, we include the option to
> install a simple one. This simple handler is also used for the tests.
>
> When a Wasm module is instantiated, information about each function is passed
> to the trap handler, which is used to classify faults. These are removed during
> the instance finalizer.
>
> Several future enhancements are planned before turning this on by default.
> Obviously, the additional checks will be added to MaybeHandleFault. We are
> also planning to add a two-level CodeObjectData table that is grouped by
> isolates to make cleanup easier and also reduce potential for contending on
> a single data structure.
>
> BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
>
> Review-Url: https://codereview.chromium.org/2371833007
> Cr-Original-Commit-Position: refs/heads/master@{#43523}
> Committed: a5af7fe9ee
> Review-Url: https://codereview.chromium.org/2371833007
> Cr-Commit-Position: refs/heads/master@{#43755}
> Committed: 338622d7caTBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
Review-Url: https://codereview.chromium.org/2744383002
Cr-Commit-Position: refs/heads/master@{#43757}
This is basically the minimum viable signal handler for Wasm bounds checks.
It includes the TLS check and the fine grained instructions checks. These
two checks provide most of the safety for the signal handler. Future CLs will
add code range and data range checks for more robustness.
The trap handling code and data structures are all in src/trap-handler, with
the code that actually runs in the signal handler confined to
src/trap-handler/signal-handler.cc.
This changes adds a new V8 API that the embedder should call from a signal
handler that will give V8 the chance to handle the fault first. For hosts that
do not want to implement their own signal handler, we include the option to
install a simple one. This simple handler is also used for the tests.
When a Wasm module is instantiated, information about each function is passed
to the trap handler, which is used to classify faults. These are removed during
the instance finalizer.
Several future enhancements are planned before turning this on by default.
Obviously, the additional checks will be added to MaybeHandleFault. We are
also planning to add a two-level CodeObjectData table that is grouped by
isolates to make cleanup easier and also reduce potential for contending on
a single data structure.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
Review-Url: https://codereview.chromium.org/2371833007
Cr-Original-Commit-Position: refs/heads/master@{#43523}
Committed: a5af7fe9ee
Review-Url: https://codereview.chromium.org/2371833007
Cr-Commit-Position: refs/heads/master@{#43755}
This fixes the catch predictions for the following builtins --
AsyncFunctionAwaitCaught
AsyncFunctionAwaitUncaught
PromiseResolveClosure
ResolvePromise
PromiseResolve
Added tests for each.
Added whitelist for builtins behind a flag.
BUG=chromium:691875
Change-Id: I816cafdb69f0c9f1eefc440a0a44c36713d0b7dc
Reviewed-on: https://chromium-review.googlesource.com/450894
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43725}
Chrome no longer calls v8::Isolate::Dispose on shutdown, essentially preventing
the use of V8 stats within chrome/content_shell. This CL adds a basic hook to
the api that is then used to only print the stats.
Chrome change: https://codereview.chromium.org/2693353002
Change-Id: I1481c14afe611e9c08ae67c815201a45940daa57
Reviewed-on: https://chromium-review.googlesource.com/452338
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43706}
Reason for revert:
Breaks tree, i.e. https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/18928/steps/Check/logs/grow-memory
Original issue's description:
> [wasm] Initial signal handler
>
> This is basically the minimum viable signal handler for Wasm bounds checks.
> It includes the TLS check and the fine grained instructions checks. These
> two checks provide most of the safety for the signal handler. Future CLs will
> add code range and data range checks for more robustness.
>
> The trap handling code and data structures are all in src/trap-handler, with
> the code that actually runs in the signal handler confined to
> src/trap-handler/signal-handler.cc.
>
> This changes adds a new V8 API that the embedder should call from a signal
> handler that will give V8 the chance to handle the fault first. For hosts that
> do not want to implement their own signal handler, we include the option to
> install a simple one. This simple handler is also used for the tests.
>
> When a Wasm module is instantiated, information about each function is passed
> to the trap handler, which is used to classify faults. These are removed during
> the instance finalizer.
>
> Several future enhancements are planned before turning this on by default.
> Obviously, the additional checks will be added to MaybeHandleFault. We are
> also planning to add a two-level CodeObjectData table that is grouped by
> isolates to make cleanup easier and also reduce potential for contending on
> a single data structure.
>
> BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
>
> Review-Url: https://codereview.chromium.org/2371833007
> Cr-Commit-Position: refs/heads/master@{#43523}
> Committed: a5af7fe9eeTBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org,eholk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
Review-Url: https://codereview.chromium.org/2723133003
Cr-Commit-Position: refs/heads/master@{#43525}
This is basically the minimum viable signal handler for Wasm bounds checks.
It includes the TLS check and the fine grained instructions checks. These
two checks provide most of the safety for the signal handler. Future CLs will
add code range and data range checks for more robustness.
The trap handling code and data structures are all in src/trap-handler, with
the code that actually runs in the signal handler confined to
src/trap-handler/signal-handler.cc.
This changes adds a new V8 API that the embedder should call from a signal
handler that will give V8 the chance to handle the fault first. For hosts that
do not want to implement their own signal handler, we include the option to
install a simple one. This simple handler is also used for the tests.
When a Wasm module is instantiated, information about each function is passed
to the trap handler, which is used to classify faults. These are removed during
the instance finalizer.
Several future enhancements are planned before turning this on by default.
Obviously, the additional checks will be added to MaybeHandleFault. We are
also planning to add a two-level CodeObjectData table that is grouped by
isolates to make cleanup easier and also reduce potential for contending on
a single data structure.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
Review-Url: https://codereview.chromium.org/2371833007
Cr-Commit-Position: refs/heads/master@{#43523}
