| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Ensure JSPromise::Resolve() obtains "then" method from the correct context As an optimization, Resolve() will use isolate->promise_then() to get the "then" method whenever resolution is a native promise object in *any* context. The Torque builtin ResolvePromise() mirrors this Resolve() method in nearly every way. However, Node issue https://github.com/nodejs/node/issues/59541 revealed a discrepancy. In Torque, ResolvePromise() only does the equivalent optimization if resolution is a native promise object in the *current* context. While all then native methods in all native contexts share the same behavior, of course, the distinction actually matters. The thenable job task is enqueued on the microtask queue of the native context associated with the then method, and the C++ version can in effect pick a different native context, and thus a different queue, than the Torque version. For instance, in current native context A, if the native Promise resolution comes from native context B, Resolve(promise, resolution) will enqueue the task on native context A, while ResolvePromise(promise, resolution) will enqueue the task on native context B. Indeed, for Resolve(), resolution is a native promise object in any native context, and by using isolate->promise_then() it fetches a then method from native context A (the current native context). While for ResolvePromise(), resolution is not a native promise object in the current native context A, therefore it skips the optimization, and will simply look up resolution["then"], fetching the native then method from context B. This change ensures Resolve(), when applying this optimization, obtains a "then" method from the creation context of resolution. Before this change, the test DetachGlobal_ResolveThenableNativeThen succeeds with builtin (ResolvePromise) but fails with runtime (JSPromise::Resolve), illustrating bug v8:441679231. Bug: v8:441679231 Change-Id: I43643c36420228a416c08d6f06c37273efd93082 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6920776 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#102517} | 9 个月前 | |
[heap] Add optional "may grow" hint for heap allocations This CL adds the capability to pass optional hints to heap allocations. In particular this CL adds a "may grow" hint but we can use this for other features in the future. The motivation behind "may grow" is the resizing of large objects that we now support using TryResizeLargeObject(). With out current "first fit" allocation strategy in the region allocation, we simply allocate a large object in the first free region large enough for the allocation. However, this might not work well with resizing because usually we start with a small allocation which we grow later if necessary. We can now run into situations were resizing often fails because we allocated in a small region initially with no room left for growing. The "may grow" hint should solve this by instead allocating in the largest free region instead which should enable us to grow the object to its final size successfully. Since we only grow the last allocation this should only fail if the the largest free region is not large enough for the final objects anyways and a GC needs to happen. In order to implement this, the allocation hint needs to be passed down all the way from the factory allocation method to RegionAllocator. This CL solves this by introducing a V8-internal AllocationHint class that we pass down from the factory method to the MemoryAllocator. In the MemoryAllocator we then need to pass the allocation hint through the V8 API-exposed v8::PageAllocator method. So we can't use our internal AllocationHint type for this. That's why this CL also adds a new v8::PageAllocator::AllocationHint class and a new method v8::PageAllocator::AllocatePages() on the API. This new method receives the allocation hint as an additional argument. The BoundedPageAllocator can then use the allocation hint to change the allocation strategy for RegionAllocator's AllocateRegion(). Bug: 409069381 Change-Id: I60ad4c6da56b2555d86a2f33b7d5f1640329d776 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6495193 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#100119} | 1 年前 | |
Avoid internal use of v8::Object::GetIsolate() ... such that we can deprecate it in a follow-up. The method is guaranteed to always return the "current isolate", so we should use that directly instead. Test sometimes use CcTest::isolate() or LocalContext::isolate() where it makes sense. R=leszeks@chromium.org Bug: 396607238 Change-Id: Iac924a78ac59be4029a75b1ff6b917160d1f7e06 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6564467 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#100391} | 1 年前 | |
[test] Move cctest/test-threads to unittests/execution/ ... threads-unittest. Bug: v8:12781 Change-Id: I1294d0bf9f47c158532a489657bc1e5349afce79 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3682882 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: 王澳 <wangao.james@bytedance.com> Cr-Commit-Position: refs/heads/main@{#80881} | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 4 年前 |