This is particularly useful to fuzzers that seek to provoke
optimization.
Bug: v8:9119
Change-Id: I729f72a0e22686fbd56793875175c230e0230823
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564196
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60794}
This reverts commit 21adacab88.
Reason for revert: Breaks Mac64 GC Stress Bot
Original change's description:
> Reserve two in-object properties slots for JSErrors
>
> The most common use-case for creating errors is "new Error('message')".
> The resulting JSError object has two properties. The message passed to
> the constructor and an accessor for the stack.
>
> This CL reserves two in-object property slots for these two, so no
> PropertyArray has to be created.
>
> Bug: v8:9116
> Change-Id: I84467453446f333bf65425807707ee6581894e61
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564195
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60791}
TBR=jgruber@chromium.org,bmeurer@chromium.org,szuend@chromium.org
Change-Id: I4667c4f49b3244d7809e8605b3858e246858a413
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9116
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564200
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60792}
The most common use-case for creating errors is "new Error('message')".
The resulting JSError object has two properties. The message passed to
the constructor and an accessor for the stack.
This CL reserves two in-object property slots for these two, so no
PropertyArray has to be created.
Bug: v8:9116
Change-Id: I84467453446f333bf65425807707ee6581894e61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564195
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60791}
This unifies the logic used for foreground compilation and background
compilation. The main thread used a separate
{FetchAndExecuteCompilationUnit} function so far, which implements the
same as the {BackgroundCompileTask}, but without compiling in batches.
This CL removes that method, and uses the same
{ExecuteCompilationUnits} method from both foreground and background
tasks.
R=mstarzinger@chromium.org
Bug: v8:8916
Change-Id: Id30edb766c46d860a5b0ef45386af7e9fd6a1cc3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564191
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60790}
This avoids accessing the page flags of all old generation PagedSpace pages when starting sweeping.
Bug: v8:9093
Change-Id: Ibdfb35f3e368107f8c364c9498312b01edce47d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554688
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60789}
It should work when Object.defineProperty is used to set a new value for seal object.
Add more test to cover this case as well.
Bug: chromium:951374
Change-Id: Idbbcc052b627587c71d5b5252340130d0fdfd595
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1562470
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60786}
Instead of a hack in the {AsyncCompileJob}, handle empty modules by
just calling the callbacks for "baseline finished" and "top tier
finished" immediately, at the point where compilation would be started
usually.
R=mstarzinger@chromium.org
Bug: v8:8916
Change-Id: Id7b32fe2508e5a8902c60865f7f7d675a7a02610
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564054
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60785}
The shared engine tests started flaking. They are broken since some
time, because the shared pointer to the {NativeModule} has temporary
additional users during compilation (in the {BackgroundCompileScope}).
This CL fixes the test by just removing the checks for use counts.
R=mstarzinger@chromium.org
Bug: v8:9117
Change-Id: Ia55ce66426f8d85c0ed8e4185aa6e507a6d327ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564056
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Auto-Submit: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60781}
This adds references to HeapObject fields to Torque.
The syntax is based on Rust (which is essentially C pointer syntax).
The type &T is a reference to T (which must be a scalar type for now).
We can create references from field access expressions, using the
addressof(&) operator:
&obj.fieldname
To read or assign a reference, we use the dereference(*) operator:
*someref = *otherref
This CL also uses references internally normal class field accesses,
but only if there is no overload for field accessor functions.
This allows to have overloaded field accessors for a subtype like
FastJSArray. However, there is a change in behavior in that an
operator ".fieldname" will stop reference creation and will therefore
also stop write access to a class field of the same name. That's why
this CL had to add a write overload ".length=" for FastJSArray.
References desugar to a pair of a tagged HeapObject pointer and an
untagged offset into this HeapObject. On the CSA-side, they are
represented by the C++ struct
struct TorqueReference {
TNode<HeapObject> object;
TNode<IntPtrT> offset;
};
Bug: v8:7793
Change-Id: Ica6468d47847bd68fb6b85f731cf8fbe142fa401
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557151
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60780}
The {code_table_} in {NativeModule} is protected by the
{allocation_mutex_}. The {code} and {code_table} accessors did not
acquire this lock though.
This CL removes the unsafe {code_table} accessor, renames {code} to
{GetCode} and protects it by a lock.
R=mstarzinger@chromium.org
Bug: v8:9112
Change-Id: Id2df68460b4c10291a49b4016b9574e02744e8b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561315
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60779}
The field type can always be generalized in-place, even for root maps.
There's no need to create defensive copies in this case. This happens
for example in the superWrapper in the Speedometer2/EmberJS-Debug test.
Bug: v8:8834, v8:9114
Change-Id: Ief05516d0e9d84850c52d2cf8815953ef77d5223
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1562131
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60778}
On x64, we allocate one big code region such that we can use near jumps
and near calls. The jump table did not make use of that design yet.
This CL changes that by emitting jump table slots as near jumps. This
also speeds up patching jump table slots significantly, since far jumps
populate the inline constant pool, which is unneeded overhead in this
case.
As a drive-by, this CL cleans up the API of near_call and near_jmp. The
current semantics is broken, and only works because this is only used
for WebAssembly calls which are patched anyway after code generation.
Also, x64 now uses the same path in test-jump-table-assembler.cc as
arm64 to ensure that all targets are within near-call-distance.
R=mstarzinger@chromium.org
Bug: v8:8916
Change-Id: Iffc34e248b72167307ffdab62dd2212c4ae86a32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561313
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60777}
Change-Id: Ic31b33ef4c290aee31be2d66295978908f568775
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563410
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#60775}
When clearing a DebugInfo, we need to check whether that function is
currently executing and, if so, update the on-stack BytecodeArray
pointer to refer to the original BytecodeArray. Otherwise, the original
BytecodeArray might get flushed, which can cause problems when
attempting to resume execution of the function.
Bug: v8:9067
Change-Id: Ief28a501294f5a34052e13f618fa084311eaa0b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1548573
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60774}
Some code - especially WebAssembly - does not make use of the code
target vector. Unconditionally reserving 100 entries adds unnecessary
overhead e.g. to jump table patching (~10%). This CL just removes this
reservation.
R=mstarzinger@chromium.org
Bug: v8:8916
Change-Id: I671820f3eb413fa2d03cef4bbf06adfc7a585266
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559868
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60772}
The current NumberEqual check ignores -0 when it is stored to
a constant unboxed double field containing 0.
Bug: v8:9113
Change-Id: I7eb59ca8af09ab7317da3c6ce9c9cedad81f6cae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561317
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60771}
This doesn't seem to provide any noticable performance wins, and just
adds more (generated) code. On a synthetic micro-benchmark for accessing
dictionary elements I was able to measure only a <1% difference for
loads and barely 1-2% for stores. That doesn't seem to be enough of a
reason to add four unrolled iterations of the lookup loop in all kinds
of places.
Bug: v8:5787, v8:8834
Change-Id: Iab8f71bf70a5518589ed4999a5be21d268ba1081
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563774
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60770}
This will allow to distinguish between the standard runner and the num fuzzer
on the infra side when generating flako command lines. The value could be
inferred, but it'd be more confusing.
Bug: v8:8971
Change-Id: I78f5104135d1c7fd7d98bceb4b17897e79421455
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564050
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60769}
... and ensure that runtime behaviour is in sync with the IC code.
Bug: chromium:950747, v8:9113
Change-Id: Ied66c9514cbe3a4d75fc71d4fc3b19ea1538f9b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561319
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60768}
Previously we'd need to eagerly compile upon access to function.length for a
lazy function. The preparser already computes function.length, however, so we
can store that information in the already available preparse data.
Change-Id: I19007c9db5839e8038291fb4433866303935f089
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564190
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60767}
MicrotasksScope has accidentally ignored the given MicrotaskQueue instance
when it's scoping out. That confused the embedder to start using the non
default MicrotaskQueue.
Change-Id: Id345605cf6520cd073429b08698de75f7681d93c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563836
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60765}
This adds a new flag --modify-field-representation-inplace (enabled by
default), which lets the runtime perform field representation changes
for Smi to Tagged or for HeapObject to Tagged in-place instead of
creating new maps and marking the previous map tree as deprecated.
That means we create (a lot) fewer Maps and DescriptorArrays in the
beginning and also need to self-heal fewer objects later (migrating
off the deprecated maps). In TurboFan we just take the "field owner
dependency" whenever we use the field representation, which is very
similar to what we already do for the field types. That means if we
change the representation of a field that we used in optimized code,
we will simply deoptimize that code and have TurboFan potentially
later optimize it again with the new field representation.
On the Speedometer2/ElmJS-TodoMVC test, this reduces the total execution
time from around 415ms to around 352ms, which corresponds to a **15%**
improvement. The overall Speedometer2 score improves from around 74.1
to around 78.3 (on local runs with content_shell), corresponding to a
**5.6%** improvement here. 🎉
On the CNN desktop browsing story, it seems that we reduce map space
utilization/fragmentation by about 4-5%. But since we allocate a lot
less (fewer Maps and DescriptorArrays) we also significantly change
the GC timing, which heavily influences the results here. So take this
with a grain of salt. 🤷♂️
Note: For Double fields, this doesn't change anything, meaning they
still create new maps and deprecate the previous map trees.
Bug: v8:8749, v8:8865, v8:9114
Change-Id: I694a53f87ae5caeb868fd98a21809b66d4297d35
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Doc: http://bit.ly/v8-in-place-field-representation-changes
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561132
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60764}
This is to investigate if higher timeouts mitigate the timeout problems.
If not it'd mean somethings actually hanging.
TBR=sergiyb@chromium.org
Bug: v8:9098
Change-Id: Idd9ae79e6f7bbede79b09498dd1acca429495308
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563970
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60762}
v8 currently detects ABI by checking OS and endianness,
but this is not sufficient to properly detect cases in
which the ELFv2 ABI is used on big-endian Linux systems.
Update these checks to use additionally use the _CALL_ELF
macro in order to properly handle such cases.
This issue was initially discovered by the Adélie Linux team.
Change-Id: Iefc0510963d93e59d6c62469a505c70c594bb14a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1555424
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#60759}
In file include/v8config.h we define:
ifdef V8_OS_WIN
...
if defined(_M_X64) || defined(__x86_64__)
define V8_OS_WIN_X64 true
endif
and V8_OS_WIN_X64 is supposed to be defined when targeting X64 on Windows only.
But this is wrong because V8_OS_WIN_X64 gets defined also on an ARM64 builds
when the host machine is X64. It should instead be:
ifdef V8_OS_WIN
...
if defined(V8_TARGET_ARCH_X64)
define V8_OS_WIN_X64 true
endif
Bug: v8:9090
Change-Id: I88e4c46bb6df1efa2070d4e1785081d71df96f0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554222
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60758}
This CL makes sure that Crashpad on Chromium will behave exactly like it did
before we added code to emit unwinding info, even when FLAG_win64_unwinding_info
is not set.
In particular, before merging the Chromium CL:
https://chromium-review.googlesource.com/c/chromium/src/+/1474703/
that modifies Crashpad to use the new function SetUnhandledExceptionCallback(),
we need to make sure that Isolate::Init() will call
win64_unwindinfo::RegisterNonABICompliantCodeRange() even when
FLAG_win64_unwinding_info is false.
In that case RegisterNonABICompliantCodeRange will only register unwind info to
invoke the Crashpad exception handler for unhandled exceptions.
Note that RegisterNonABICompliantCodeRange will be a no-op with the current
Crashpad code that never calls SetUnhandledExceptionCallback().
Bug: v8:8661
Change-Id: I63d845e9dca79ddd5978dfb43b626ace50078e80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554119
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60757}
When getting the starting address of a data segment, you can't use
`&vector[offset]` if offset is equal to the length of the vector. This
can happen when the length of the segment is 0.
The fix is to use Vector::SubVector instead.
Bug: v8:9106
Change-Id: Icf8968cc246c6d217d8061f76fb2631c2292433c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1560405
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60755}
The wasm engine is the same for all units, thus we should store (or
get) it in the compilation task, and not store it duplicated in each
compilation unit.
R=mstarzinger@chromium.org
Bug: v8:8916, v8:8343
Change-Id: Id4b062b5b8a52228b4d6051a67e025088a61d466
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559863
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60754}
If the runtime does not transition in keyed store IC miss handler,
avoid generating transitioning handler since this could make
the receiver map non-stable. (The optimizing compiler does not like
non-stable fast prototype maps.)
Bug: chromium:950328
Change-Id: I113880d2033518e3eb8fd11df1599e56a67d7fd0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559867
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60752}
This is a reland of Ie3ac389e1c082d1671efd4d74abc076ce943301b with a fix
for MSAN failures.
Interrupt budget was store in bytecode array and used to be shared
across all contexts. With lazy feedback allocation, using context
independent interrupt budget might lead to performance cliffs when
we have closures that do not share the same feedback (for ex: across
contexts). This would be a problem even earlier but it could be
more pronounced with feedback vector allocation, since the budgets
for optimization is much higher (144x) than the budget for feedback
allocation.
Bug: chromium:948835, v8:8394
Change-Id: I74f998c30e27caf3bd34510f4d7f57b65e6c7f0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561072
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60750}
This reverts commit 251d1623f3.
Reason for revert: Breaks ASAN debug builders for ClusterFuzz, see https://ci.chromium.org/p/v8/builders/ci/V8%20Clusterfuzz%20Linux64%20ASAN%20-%20debug%20builder/8115
Original change's description:
> Reland "[torque] Throw exception instead of aborting if something goes wrong"
>
> This is a reland of 3bd49f9b90
>
> The issue on the windows bot is apparently a compiler bug in MSVC related to
> move construction. The fix seems to be to change the order of the fields in
> "JsonParseResult" (go figure).
>
> Drive-by-change: Fix LS on windows by emitting correct line endings and
> enabling exceptions for the LS executable as well.
>
> Original change's description:
> > [torque] Throw exception instead of aborting if something goes wrong
> >
> > This CL enables exceptions for the Torque compiler and Torque language
> > server. Instead of aborting when something goes wrong during
> > compilation, a TorqueError is thrown, containing the error message
> > and a source position. The compiler executable still prints the error
> > and aborts, while the language server will pass this information
> > along to the client (not included in this CL).
> >
> > R=danno@chromium.org
> >
> > Bug: v8:8880
> > Change-Id: Iad83c46fb6a91c1babbc0ae7dbd94fbe4e7f1663
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526003
> > Reviewed-by: Daniel Clifford <danno@chromium.org>
> > Commit-Queue: Simon Zünd <szuend@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#60512}
>
> Bug: v8:8880
> Change-Id: I00e6591bbb4c516dd7540a7e27196853bc637f11
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545995
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60736}
TBR=danno@chromium.org,tebbi@chromium.org,szuend@chromium.org
Change-Id: I0b22db1652bd46fbb7167f75b710ed5e408ea8ac
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8880
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561311
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60747}
This CL moves frames.tq and arguments.tq to the front of the file
list when compiling Torque files.
Note that order independent compilation will most likely be
implemented in the near future, at which point this code becomes
obsolete.
R=tebbi@chromium.org
Bug: v8:8880
Change-Id: I7e32637925c28202f9b017a568bc06ae5bd595b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561210
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60746}
Make the tracing code and output more consistent and/or compact.
Also, restrict --trace-heap-broker to reports about missing data and
introduce a new flag --trace-heap-broker-verbose that prints everything.
Bug: v8:7790
Change-Id: I6e678fb97bf8631428594f77d8b5f0909ab2e281
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559864
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60745}
