- 19 May, 2021 35 commits
-
-
Jakob Kummerow authored
When adding new instances to the WeakArrayList of a script's instances, use Append() instead of AddToEnd() to allow possible compaction of the WAL. Also, check for interrupt requests every now and then, which allows incremental marking to get finalized when appropriate. Bug: v8:11774 Change-Id: I8be959a78d8ef370f65e8f9849f48e34c9691a13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905603 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#74681}
-
Junliang Yan authored
Change-Id: I1ada6628e8d17d313f6ee73fda40bb867e3e0ee4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2906013 Commit-Queue: Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Auto-Submit: Junliang Yan <junyan@redhat.com> Reviewed-by:
Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#74680}
-
Jakob Kummerow authored
Attempting to trace object stats ran into an UNREACHABLE because the FieldStatsCollector didn't override VisitMapPointer. Change-Id: I38f2739c204e462e5a35f2a7ca6e0f100161b240 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905604 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#74679}
-
Victor Gomes authored
This is a follow-up to https://chromium-review.googlesource.com/c/v8/v8/+/2833920 Bug: chromium:1209210, chromium:1198188 Change-Id: I43f18649434b06431dac6cae7946505fc4b5b398 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905607 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#74678}
-
Manos Koukoutos authored
This is a reland of 4a037f87 Changes compared to original change: None. This seems not to create problems after all. Original change's description: > [wasm][bug] Fix a couple of bugs in validation of unreachable code > > Changes: > - SetBlockType now instantiates the block's start merge with values of > the correct type in unreachable code. > - EnsureStackArguments now keeps the existing stack values and moves > them over the new bottom values. > - Drop stack size validation in Drop(). > - Add new tests in unreachable-validation.js. > > Change-Id: Ie68b3d9abb0a41d1623d4a123fb526e71941c4e7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2902733 > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74650} Change-Id: Id620f7fb6677b772b0dcfd38108256384db44439 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905598Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#74677}
-
Junliang Yan authored
Change-Id: I1449424536b721e54f95aeb2e3b68fb25d6a5ccf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2906033Reviewed-by:
-
Benedikt Meurer authored
When setting a breakpoint on a line (in the DevTools front-end), the front-end sends a columnNumber of 0 and the inspector automatically resolves the actual location (in bytecode execution order). In order to also support changing source code, the inspector memorizes a text hint, and uses that to adjust the location upon reload. This hint was however taken based on the original line and column numbers, rather than the resolved location, which causes trouble when syntactic order doesn't match execution order, as in case of `await o.m()`. In order to address that we now remember the textual hint based on the resolved location. Fixed: chromium:1081162 Also-By: kimanh@chromium.org Change-Id: I7d08373440693b7abc18c29c1a05929d771d3031 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905606 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#74675}
-
Milad Fa authored
Port 2a43f8c4 Original Commit Message: Inline the RememberedSetAction and SaveFPMode flags directly into the RecordWrite stubs: - Save two register for input arguments - Avoid branches in the RecordWrite stubs We end up with 2 stubs for the EphemeronKeyBarrier and 4 stubs for RecordWrite. Due to more inlined calls we have roughly 1KiB more builtins code for RecordWrite currently. We will address this in the future by splitting out common code into a separate stub. There is no additional code size overhead for EphemeronKeyBarrier. This saves 4 to 8 bytes on x64 per RecordWrite call and 2.5% sparkplug code size reduction on d3.min.js. R=cbruni@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: Iaab3d0aad9f90a942459ac63a641c52246a4afa1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2906012Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#74674}
-
Dominik Inführ authored
CollectionRequested was used exclusively on the main thread when a background thread requested a GC. The main thread never used SafepointRequested at any time. Now with the shared GC we might need to stop multiple isolates in a safepoint in the future. In such a situation we would need to use SafepointRequested also on the main thread. This CL prepares V8 for this situation by using SafepointRequested instead of CollectionRequested and friends on the main thread. The slow path of Safepoint(), Park() and Unpark() will check in the future whether the main thread needs to halt for a shared GC or needs to perform a local GC. At the moment, simply performing the local GC is still enough. Bug: v8:11708 Change-Id: I819b6f7db8251074a4adf8b554e0a1393c76f7da Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891834 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74673}
-
Omer Katz authored
Check that the marked bit of an object is set if assigned during a prefinalizer to a Member in a live object or a Persistent. Bug: v8:11749 Change-Id: I993c0d226a4157698591e1f7bc0c55e5c79239b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2897093 Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by:
-
Patrick Thier authored
Change ReturnFuzzSafe to only return undefined when --correctness-fuzzer-supressions is on, instead of --fuzzing. Bug: chromium:1200724, v8:11701 Change-Id: I21aa77db89fe26308881985055b023a5c03c2518 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905593 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Auto-Submit: Patrick Thier <pthier@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#74671}
-
Junliang Yan authored
Change-Id: Id1a468a51c0f37c99bb36b388aaa803ae6ed8516 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905193Reviewed-by:
-
Patrick Thier authored
We compile with Sparkplug when we allocate the feedback vector with lazy feedback vector allocation. --stress-concurrent-inlining implies --no-lazy-feedback-allocation, so it doesn't make sense to run baseline tests with this variant. Change-Id: I7fd4c2b11cf2a9bb29d6f78c5973aed80abab85e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2903118 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Auto-Submit: Patrick Thier <pthier@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74669}
-
Michael Lippautz authored
The barrier just re-added a black object to the worklist (making it gray) which results in double-accounting live bytes. Trace directly as the barrier is not widely used. Bug: chromium:1056170 Change-Id: I06a55c13f6e82652ad1939a12c4e23f3a3ebd3fd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904212 Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74668}
-
Clemens Backes authored
This adds another data pointer increase to fix an occurence of an unsupported instruction. R=jkummerow@chromium.org Bug: chromium:1206412 Change-Id: I311dbdc0cc33f7d8d0cfe952c1f085a61f3ec225 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880220 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Clemens Backes authored
If fuzzers pass a low --wasm-max-initial-code-space-reservation limit, we might run into a DCHECK/CHECK failure because the "overhead" per code space (for jump tables) is more than half of the reserved code space (DCHECK) or actually bigger than the reserved code space (CHECK). This CL fixes that by explicitly failing with an OOM message in that case. This should only happen if that testing flag is set. I do have a test case for this (reduced from the ClusterFuzz report) but it needs >20000 functions (to make the jump tables big enough to fail the checks), so it runs really slow (>90 seconds in debug). Since the failure only happens with a testing flag, I think it's acceptable to fix this without a regression test. R=ahaas@chromium.org Bug: chromium:1208259 Change-Id: I99e56a533efcdfa51d99eb5f64edead490398b3c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904206Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74666}
-
Marja Hölttä authored
Bug: v8:11111 Change-Id: I0bea83be43f9749b95caed146224d21b5128a478 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904207 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#74665}
-
Marja Hölttä authored
Bug: v8:11525 Change-Id: I1c8e2346ed1581dc6b44e8df203d1ad0bcd1639a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2883357 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
-
Michael Lippautz authored
Bug: chromium:1056170 Change-Id: I885ec134ad632473c4bdaab82c0fe86d7a9ae931 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904214 Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by:
-
Clemens Backes authored
The combination of pthread_rwlock_t and signals causes spurious deadlocks on Mac (see linked issue). This adds a cctest which tests this combination. This test is skipped on Mac, where it would deadlock. This test can be used to document and further investigate the issue, and test potential fixes. R=jkummerow@chromium.org Bug: v8:11399 Change-Id: I5d1fcdd84db253ec2d0637575239f212aae2ecb7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2856553Reviewed-by:
-
Camillo Bruni authored
Inline the RememberedSetAction and SaveFPMode flags directly into the RecordWrite stubs: - Save two register for input arguments - Avoid branches in the RecordWrite stubs We end up with 2 stubs for the EphemeronKeyBarrier and 4 stubs for RecordWrite. Due to more inlined calls we have roughly 1KiB more builtins code for RecordWrite currently. We will address this in the future by splitting out common code into a separate stub. There is no additional code size overhead for EphemeronKeyBarrier. This saves 4 to 8 bytes on x64 per RecordWrite call and 2.5% sparkplug code size reduction on d3.min.js. Bug: v8:11420 Change-Id: Ib7170265dd6dd4b3aaf8275083f096e76fae8251 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2902731Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#74661}
-
Junliang Yan authored
Change-Id: Iedb0bb641a83fd897c92baca4f58c7d689135e33 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904271Reviewed-by:
-
Manos Koukoutos authored
Recent changes in wasm-module-builder.js were not translated to the fuzzer JS output. After this CL, the fuzzer should generate .js files that output back the fuzzed module. Change-Id: I8bc33ab7f4f838a519c7aa47e425d8ac65b88d45 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904217 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74659}
-
Sathya Gunasekaran authored
This reverts commit 8f39a585. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc/17874/blamelist Original change's description: > [wasm-gc] Implement br_on_cast_fail > > Bug: v8:7748 > Change-Id: I7894ad51ccf8ac41a5081c272a583a4ff25c1835 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2900225 > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74652} Bug: v8:7748 Change-Id: I90ca2d789e943cd00c2344e2d333c9175fcedee5 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2903482 Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#74658}
-
Manos Koukoutos authored
This reverts commit 4a037f87. Reason for revert: Bot failures, including MSVC compilation. Original change's description: > [wasm][bug] Fix a couple of bugs in validation of unreachable code > > Changes: > - SetBlockType now instantiates the block's start merge with values of > the correct type in unreachable code. > - EnsureStackArguments now keeps the existing stack values and moves > them over the new bottom values. > - Drop stack size validation in Drop(). > - Add new tests in unreachable-validation.js. > > Change-Id: Ie68b3d9abb0a41d1623d4a123fb526e71941c4e7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2902733 > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74650} Change-Id: Icb16af9a8ed16e593fe345ab727b992d9c9b1500 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905597 Auto-Submit: Manos Koukoutos <manoskouk@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#74657}
-
Marja Hölttä authored
The logic is different for shared and non-shared memory, so it's cleaner to have different functions for them. Bug: v8:11111 Change-Id: I95d43b54c207b8059ea59d6d0f873623de946be3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2903152 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
-
Dominik Inführ authored
Our synchronization protocol for top and limit only guarantees that we read the new limit in case we read the new top. However, it could happen that we read the old top but the new limit. In the allocation slow path we reset both top and limit to 0 first and then reset it to the free list allocation boundaries. With --no-inline-new we are changing top/limit a lot, so it could happen that we read the old value for top (0) but a regular address for limit. In such cases large parts of the heap would be incorrectly considered pending. Handle these cases here by checking that top is non-zero. This is temporary fix, we believe that it is at least theoretically possible to read non-0 but non-consistent values for top/limit as well. This will be addressed in a subsequent CL. Bug: v8:11778 Change-Id: I6b581f2a6df3f24c16443717b0cde9a18c5f3f40 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2903155 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Jakob Gruber authored
The BytecodeArray itself was fetched by using a barrier so all reads from the constant pool are safe. Bug: v8:7790 Change-Id: If924d43a10c7aa20b69225fab8219e7bd988419c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2903149 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74654}
-
Jakob Gruber authored
Using kAssumeMemoryFence works around the fact that the graph stores handles (and not refs). The assumption is that any handle inserted into the graph is safe to read; but we don't preserve the reason why it is safe to read. Thus we must over-approximate here and assume the existence of a memory fence. Note this is only valid if all spots that insert handles into the graph ensure that the handle can safely be read. In the future, we should consider having the graph store ObjectRefs or ObjectData pointer instead, which would make new ref construction here unnecessary. Bug: v8:7790,chromium:1209798 Change-Id: Ic22340ea9f34a24be530a3c62c8309d25e108f3f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2902742Reviewed-by:
-
Manos Koukoutos authored
Bug: v8:7748 Change-Id: I7894ad51ccf8ac41a5081c272a583a4ff25c1835 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2900225 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
Jakob Gruber authored
Bug: v8:11771 Tbr: machenbach@chromium.org Change-Id: Ib0e64e84c930c791023d8743fe0b0373ab626071 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904216Reviewed-by:
-
Manos Koukoutos authored
Changes: - SetBlockType now instantiates the block's start merge with values of the correct type in unreachable code. - EnsureStackArguments now keeps the existing stack values and moves them over the new bottom values. - Drop stack size validation in Drop(). - Add new tests in unreachable-validation.js. Change-Id: Ie68b3d9abb0a41d1623d4a123fb526e71941c4e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2902733 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
Manos Koukoutos authored
We used to verify its index as if it was a function index. Bug: chromium:1210447 Change-Id: I5e015b1b11b22b6b7e7e13dac4945f8eb6f3d846 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2903153Reviewed-by:
-
Dan Elphick authored
Since debug-interface.h and isolate.h only uses v8_inspector::V8Inspector as a pointer type, this removes the #includes and forward declares the type. Bug: v8:11384 Change-Id: Ia361fc3a028a9abf5ee42ecb3b2575bc84a81e35 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2903159 Auto-Submit: Dan Elphick <delphick@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/30196c5..4036cf1 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/a68a003..c1e1d55 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/1fc595b..6b0a611 Rolling v8/third_party/zlib: https://chromium.googlesource.com/chromium/src/third_party/zlib/+log/298d9e6..5b8d433 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/701e2be..a38f01b Rolling v8/tools/luci-go: git_revision:bbac8f199026d706b08e53ca46d1a9560ae580d2..git_revision:22d464e2f8f3bd2bd33f69fe819326d63f881008 Rolling v8/tools/luci-go: git_revision:bbac8f199026d706b08e53ca46d1a9560ae580d2..git_revision:22d464e2f8f3bd2bd33f69fe819326d63f881008 Rolling v8/tools/luci-go: git_revision:bbac8f199026d706b08e53ca46d1a9560ae580d2..git_revision:22d464e2f8f3bd2bd33f69fe819326d63f881008 TBR=v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Id08b26af423f65f67a64289c03a5e2eba5c6bfa4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904925Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#74647}
-
- 18 May, 2021 5 commits
-
-
Michael Lippautz authored
Marking holds the process wide mutex for synchronizing CrossThread* references. In addition, marking may also create temporary copies of Member references for concurrent tracing (snapshot). Provide HeapRegistry with its own mutex to avoid a deadlock with Member checking during marking. Bug: chromium:1056170 Change-Id: I31d922ec1a476942e29d8d4fa7d864a015f428cc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904211 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Milad Fa authored
Change-Id: I8ecf009aa560144f572bd954a1aa8bde8732ffa1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904267Reviewed-by:
-
Marja Hölttä authored
Drive-by fix: The file name for WATCHLISTS in the OWNERS file rule was wrong, so fixing that too so that it's possible to modify WATCHLISTS without eng reviewers approval in the future. Change-Id: I0e24c5d459aab2bb346aca64125eabe0ceac8274 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2903154Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Patrick Thier <pthier@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#74644}
-
Paolo Severini authored
In order to support Fast API calls with overloads, store a FixedArray of c-function addresses and a FixedArray of the corresponding FunctionInfo*. For now keep using only the first function in the array. Bug: v8:11739 Change-Id: If23381aa9d04c5cd830043951da9c53836a36328 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876592Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#74643}
-
Milad Fa authored
Using `thread_local` on AIX causes the following error during linking: ``` ld: 0711-317 ERROR: Undefined symbol: TLS init function for ... ``` To avoid the issue we can use the __thread keyword. More on this gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100641 Bug: v8:11755 Change-Id: Ic9738e8dfb7110b550328c5d9929f4453e545b0b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2903586Reviewed-by:
-
