- 15 Oct, 2020 8 commits
-
-
Omer Katz authored
Cppgc exposes EphemeronPair that contains a WeakMember key and a Member value and can be used to denote ephemeron semantics in the standalone library. Tracing EphemeronPairs goes through TraceEphemeron that is exposed on the api for the blink usecase. Bug: chromium:1056170 Change-Id: I9fbaa284fa2034248cdf36ea8b0cd5be6a55f676 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467842 Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#70525}
-
Santiago Aboy Solanes authored
This gives Arm32/64 test parity with x64. Bug: v8:10833 Change-Id: I51c3a61c1529dd17782c60ca5aa6508c6e57ce1a Fixed: v8:10833 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467850 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70524}
-
Javad Amiri authored
Bug: v8:9533 Change-Id: I912bd5acd2cdb4c9d111711d17a01ba635b76660 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463006 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70523}
-
Georg Neis authored
This reverts commit 44708a5b. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33692 Original change's description: > [compiler, heap] Create LocalHeap outside of ExecuteJob > > Create LocalHeap directly in the Task or in GetOptimizedCodeNow and > pass its reference as argument to ExecuteJob. This allows us to create > LocalHeap differently for the main and background thread, e.g. by > passing an additional argument to the constructor in the future. > It will be required in the future anyways when the main thread will > have its own LocalHeap/LocalIsolate. > > Extending the scope of LocalHeap, also made > HandleBase::IsDereferenceAllowed more precise and uncovered two > potential issues: heap accesses in > OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode > with --code-comments. > > LocalHeap can now be created in the parked state. Also fixed a data > race with LocalHeap's destructor publishing write barrier entries > without holding the lock. > > Bug: v8:10315 > Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70521} TBR=ulan@chromium.org,neis@chromium.org,leszeks@chromium.org,solanes@chromium.org,dinfuehr@chromium.org Change-Id: I9dd1f8ca6237d5716b6d8938cef0ee3f642f3166 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10315 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474118Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70522}
-
Dominik Inführ authored
Create LocalHeap directly in the Task or in GetOptimizedCodeNow and pass its reference as argument to ExecuteJob. This allows us to create LocalHeap differently for the main and background thread, e.g. by passing an additional argument to the constructor in the future. It will be required in the future anyways when the main thread will have its own LocalHeap/LocalIsolate. Extending the scope of LocalHeap, also made HandleBase::IsDereferenceAllowed more precise and uncovered two potential issues: heap accesses in OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode with --code-comments. LocalHeap can now be created in the parked state. Also fixed a data race with LocalHeap's destructor publishing write barrier entries without holding the lock. Bug: v8:10315 Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
-
Ng Zhi An authored
These instructions will be used for prototyping Wasm SIMD's store lane later on, separated the implementation for assembler and disassembler into this patch to make things smaller. Curiously, movhps and movlhps seems to have the same encoding, 0f 16, so I'm not sure not sure how to differentiate them in the disassembler besides using the mod field, since movlhps only takes xmm registers, whereas movhps always take 1 operand. Bug: v8:10975 Change-Id: I8be9a31b1c9a5515038f9c8c55ef30d1ba063ea7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2471977Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#70520}
-
Zhao Jiazhong authored
dst may be the same register as src0/src1, so it shouldn't be overwritten if we still need src0 and src1's values. And the NaN was not properly canonicalized, this CL adds fmin/fmax instructions to canonicalize the result. Change-Id: Ia65829015eb6c4de160298719d694ca9490883b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465775Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Cr-Commit-Position: refs/heads/master@{#70519}
-
Ng Zhi An authored
LoadTransform is always a SIMD operation (it always results in a v128), so it should unconditionally set has_simd_. Bug: chromium:1137583 Change-Id: I8496e787c89edec734f4bbfd16dd8b5995fab98a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2472638Reviewed-by:
-
- 14 Oct, 2020 23 commits
-
-
Ng Zhi An authored
Make everything consistent, pinsr family was converted in https://crrev.com/c/2443494. Bug: v8:10933 Change-Id: I9d09bd477520ce71fccdcf4336135b54c058185c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470203Reviewed-by:
-
Ng Zhi An authored
We were already using it to define the SSE instructions. Bug: v8:10933 Change-Id: I8c70c027449ee8b0d00a06298087310ced11cafc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470200Reviewed-by:
-
Michael Lippautz authored
Bug: chromium:1056170 Change-Id: Ib03a09db010f3ad06701520fc39e7e83055dbb9e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467855 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#70515}
-
Z Nguyen-Huu authored
It is related to Reduce consecutive overflow addition with constants. Turned out that we needs to consider also effect use before relaxing it. This fixed the issue that fuzzer found in e93a369f. Bug: chromium:1137586 Change-Id: I32fee5ecc7a6ce40d6f739f9c6e2440a647a2222 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469597 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70514}
-
Milad Fa authored
kModeMask needs to match the previous declaration of mode_mask which was removed in this CL: https://crrev.com/c/2452689 Bug: v8:11007 Change-Id: I2435309b0147b05438902eef440816e3f82aff9b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2466053 Commit-Queue: Milad Fa <mfarazma@redhat.com> Reviewed-by:
-
Milad Fa authored
Due to a bug on AIX, some of the glibc FP functions do not preserve the sign bit when a negative input is passed by value and the output is rounded to 0: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97086 This CL forces the use of "-0.0" in such cases. Change-Id: If9935596e32e97720f3cb22f27975267ac1124d7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2468618Reviewed-by:
-
Ng Zhi An authored
The todo is "fixed", in that we found the root cause, and recent refactorings have given us more breathing space in the number of opcodes, and also a static_assert was added to give a clearer error message. Bug: v8:10930 Change-Id: Ied47bf6a61a2bc70949c45f9d00d714b313a5192 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469157Reviewed-by:
-
Martin Bidlingmaier authored
This CL enables the functionality that was added in d4febb6b by flipping the corresponding feature flag. Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:10765 Bug: v8:11021 Change-Id: Id061a274b016c71e6a4f7d7934a9c287d3124228 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470568 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by:
-
Zentaro Kavanagh authored
- -Wfinal-dtor-non-final-class warns on classes with final dtors but not final classes. - Error messages are better when the class is marked final. - Fix existing issues in code base and remove warning exemption Bug: chromium:999886 Test: no errors building Change-Id: Ied2a7a2ff890ecbaf0a4c84f5323f0c9d32def58 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467000Reviewed-by:
-
Clemens Backes authored
Instead of querying the platform for the number of available threads, and allocating exactly N+1 queues, do grow the number of queues dynamically. This allows for more than N+1 concurrent threads, which then allows us to contribute to compilation instead of waiting doing nothing. This will be added in a follow-up CL. Special care is being taken to not synchronize too much between threads. We take a shared mutex whenever stealing tasks, but not on the default path where we pick a unit from the task's own queue. R=thibaudm@chromium.org CC=etiennep@chromium.org Bug: v8:11005 Change-Id: I1f67f15fb22b95ef246c37eb80c03132d8a1d149 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467844 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#70508}
-
Dominik Inführ authored
Scope might still be in progress and needs to be closed when starting tear down. There will be no GC after starting tear down anymore. Bug: v8:11022, v8:10315 Change-Id: I50ea02b13b84ef4fbbc08985ca9e25e0b0ec856d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470572Reviewed-by:
-
Seth Brenith authored
This change adds test functions to check that the Torque-generated verifiers can catch a few basic kinds of errors and crash the process. Bug: v8:7793 Change-Id: If0d2b1e8834c3e602c2677253ad3a920566414bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469039Reviewed-by:
-
Victor Gomes authored
Change-Id: I468d64df5d1a06a395249d16c8974d3dec85fe7b Bug: chromium:1138197, v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470570 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Almothana Athamneh authored
Bug: v8:11018 Change-Id: I36fc948ebea7c5a648307f82e1940678068d2990 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470559 Commit-Queue: Almothana Athamneh <almuthanna@chromium.org> Reviewed-by:
Liviu Rau <liviurau@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#70504}
-
Vicky Kontoura authored
This CL adds a basic tiering strategy for the js-to-wasm wrappers. When applicable, calls to exported WebAssembly functions are initially handled through the generic js-to-wasm wrapper. If these calls through the generic wrapper reach a constant threshold, the specific (per-signature) wrapper is compiled synchronously for the function and the generic wrapper is replaced. Bug: v8:10982 Change-Id: I65e706daffb5cb6e723ce2f7b785f7ecb7b2fa7b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461243 Commit-Queue: Vicky Kontoura <vkont@google.com> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#70503}
-
Victor Gomes authored
Change-Id: I2f262f4545de9e421310094d0dfab2f6147869b5 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2466116Reviewed-by:
Junliang Yan <junyan@redhat.com> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70502}
-
Clemens Backes authored
With boolean validation, we don't keep the PC for stack values any more. This CL fixes the --trace-wasm-decoding logic to just not print the opcode which produced a value. The producer can also be found by looking back in the trace. This also makes the tracing output a lot more concise, hence easier to read. Also fix the TraceFailed method to not try to print buffer relative offsets if no PC is there. R=zhin@chromium.org Bug: v8:10969 Change-Id: I5a7a69ea5aa461a277401d87ee24635266517d3c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465837Reviewed-by:
-
Martin Bidlingmaier authored
We fall back from irregexp to the experimental engine if a backtrack limit is exceeded and the experimental engine can handle the regexp. The feature can be turned on with a boolean flag, and an uint-valued flag controls the default backtrack limit. For regexps that are constructed with an explicit backtrack limit (API, %NewRegExpWithBacktrackLimit), we choose the lower of the explicit and default backtrack limits. The default backtrack limit does not apply to regexps that can't be handled by the experimental engine, and for such regexps an explicitly specified backtrack limit is handled as before by returning null if we exceed it. Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:10765 Change-Id: I580df79bd847520985b6c2c2159bc427315c89d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436341 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by:
-
Victor Gomes authored
Change-Id: Icd094eaa12b957bc7a658807aaa565665a184c81 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470561 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Michael Lippautz authored
Bug: chromium:1056170 Change-Id: I65a2b38c85a93ac2822cb7d2b7ac4bd66540348a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2468996 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Victor Gomes authored
Change-Id: Ie8e2a87fa079b602f895c3c98053b7e7dfc61f45 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440098Reviewed-by:
-
Jakob Gruber authored
This is a reland of 16cd5995 Changes since the original CL: generic lowering support for ForInPrepare and ForInNext. Original change's description: > [nci] Prepare JSForInPrepare and JSForInNext for feedback input > > These two operators are still missing feedback collection in generic > lowering (reminder: all operations that collect FB in the interpreter > must also collect FB in generic lowering). > > This CL prepares for that by adding the feedback vector as an input, > and additionally adds node wrappers to improve useability. > > The actual collection logic will be added in a following CL. > > Bug: v8:8888 > Change-Id: I04627eedb2dc237dc4e417091c44d2a95bd98f5f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2454712 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70372} Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:8888 Change-Id: Idc294ffd2a24922edd08db6897d32d5724956995 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2459373 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/base/trace_event/common: https://chromium.googlesource.com/chromium/src/base/trace_event/common/+log/e0f2b84..ea3ab7b Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/18a5f87..4af5c07 Rolling v8/third_party/aemu-linux-x64: PL87Lj_q7GOEzYJ2eJIJAzMtQbuLWVnmjDQPqfu2O64C..7vSUW_nuKSjSwu_SJlXmDCOkdOAMe1nyjgN02vO04jEC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/cd2eebd..01898ca Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/b073999..6e970e5 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/7e5979b..d4827bf TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I26b4159ee973fab9af5d540d1fb269d19eed105e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469819Reviewed-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@{#70495}
-
- 13 Oct, 2020 9 commits
-
-
Ng Zhi An authored
The existing implementation gives different results for certain floating points values from std::min and std::max. This patch makes it the same, so it is less surprising. Took a quick look at some usages for Min and Max, they are all integral types, so this wouldn't change any behavior. Min and Max has been in the code base right from the initial import, and I'm not sure why we needed it, since it should simply be std::min/std::max. With C++14, std::min and std::max are constexpr, so this change is also fine. Change-Id: If8ec53bedff3ef336aa21b082f1a16ce716b8f87 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464146Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#70494}
-
Ng Zhi An authored
The only one that doesn't use a pinsr* is f32x4, which uses insertps, so that is kept as it is. Bug: v8:10933 Change-Id: I7442668812c674d4242949e13ef595978290bc8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2458787Reviewed-by:
-
Igor Sheludko authored
This is a reland of 3593ee83 The MSAN doesn't seem to be considering initializing stores via inline assembly as such (in a new cctest helper GetStackPointer()), so this reland attempt fixes the issue and ensures that the MSAN bot is happy. Original change's description: > Reland "[csa] Fix semantics of PopAndReturn" > > This is a reland of 5e5eaf79 > > This CL fixes the "function returns address of local variable" issue > which GCC was complaining about by using inline assembly instead of > address of a local for getting stack pointer approximation. > > Original change's description: > > [csa] Fix semantics of PopAndReturn > > > > This CL prohibits using PopAndReturn from the builtins that > > have calling convention with arguments on the stack. > > > > This CL also updates the PopAndReturn tests so that even off-by-one > > errors in the number of poped arguments are caught which was not the > > case before. > > > > Motivation: > > > > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for > > dropping ALL JS arguments that are currently located on the stack. > > Disallowing PopAndReturn in builtins with stack arguments simplifies > > semantics of this instruction because in case of presence of declared > > stack parameters it's impossible to distinguish the following cases: > > 1) stack parameter is included in JS arguments (and therefore it will > > be dropped as a part of 'pop' number of arguments), > > 2) stack parameter is NOT included in JS arguments (and therefore it > > should be dropped in ADDITION to the 'pop' number of arguments). > > > > This issue wasn't noticed before because builtins with stack parameters > > relied on adapter frames machinery to ensure that the expected > > parameters are present on the stack, but on the same time the adapter > > frame tearing down code was effectively recovering the stack pointer > > potentially broken by the CSA builtin. > > > > Once we get rid of the arguments adapter frames keeping stack pointer > > in a valid state becomes crucial. > > > > Bug: v8:5269, v8:10201 > > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819 > > Commit-Queue: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#70454} > > Tbr: tebbi@chromium.org > Bug: v8:5269 > Bug: v8:10201 > Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70483} Tbr: tebbi@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng Bug: v8:5269 Bug: v8:10201 Change-Id: Ib09af2d1260bb42ac26aabface14e6b83b3efec4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467847 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70492}
-
Santiago Aboy Solanes authored
As a drive-by, enable tests that are safe for Arm32/64 to run. Bug: v8:10833 Change-Id: I8fed5651399852f9ce8ba7d5acdb7ed27ca28e89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467841Reviewed-by:
-
Seth Brenith authored
This change updates verifier generation to: - Fix a bug I introduced in https://crrev.com/c/2047399 that caused values within struct-typed fields to not get verified - Support indexed fields with start offsets that are not known at compile time - Support indexed fields with complex length expressions Bug: v8:7793 Change-Id: I5ae8803fce59abae0989fcb094bd9692cd88e38e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461456 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
-
Dominik Inführ authored
Add histogram for time-to-collection. As a drive-by change also move CollectionBarrier into its own class and rename V8.TimeToSafepoint to V8.StopTheWorld such that the histogram name and the trace file entry now have the same name. Bug: v8:10315 Change-Id: I86e2a9592d10316d04bc8cab37ff548067aadf78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465840Reviewed-by:
-
Santiago Aboy Solanes authored
GetOwnElementFromHeap uses LookupIterator which requires heap allocation. Therefore, we cannot call it from the background thread with concurrent access. Bug: v8:7790, v8:11012 Change-Id: I29733db69a8935c7b7585c776ab1a2d7f1265e95 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465841 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
-
Victor Gomes authored
Change-Id: If9ab58bf671567f7a035a03b3e4e772ba302b522 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467843 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Michael Achenbach authored
Bug: chromium:1137528 Change-Id: If49ed0b92c0f2b64cf7d6c30529a3647dda4e84d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467849Reviewed-by:
-
