[webkit-changes] [289601] trunk
Title: [289601] trunk Revision 289601 Author fpi...@apple.com Date 2022-02-10 19:58:39 -0800 (Thu, 10 Feb 2022) Log Message Unreviewed, add an alternate email address. * metadata/contributors.json: Modified Paths trunk/ChangeLog trunk/metadata/contributors.json Diff Modified: trunk/ChangeLog (289600 => 289601) --- trunk/ChangeLog 2022-02-11 03:58:02 UTC (rev 289600) +++ trunk/ChangeLog 2022-02-11 03:58:39 UTC (rev 289601) @@ -1,3 +1,9 @@ +2022-02-10 Filip Pizlo + +Unreviewed, add an alternate email address. + +* metadata/contributors.json: + 2022-02-10 Elliott Williams [Xcode] Perform a full build when analyzing Modified: trunk/metadata/contributors.json (289600 => 289601) --- trunk/metadata/contributors.json 2022-02-11 03:58:02 UTC (rev 289600) +++ trunk/metadata/contributors.json 2022-02-11 03:58:39 UTC (rev 289601) @@ -2453,7 +2453,8 @@ "Phil Pizlo" ], "emails" : [ - "fpi...@apple.com" + "fpi...@apple.com", + "pi...@mac.com" ], "expertise" : "_javascript_/ECMAScript", "name" : "Filip Pizlo", ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [289590] trunk/Source
Title: [289590] trunk/Source Revision 289590 Author fpi...@apple.com Date 2022-02-10 15:49:33 -0800 (Thu, 10 Feb 2022) Log Message [libpas] jit_heap should support the segregated heap https://bugs.webkit.org/show_bug.cgi?id=235497 Reviewed by Yusuke Suzuki. Source/bmalloc: One of the things that libpas provides is a fast implementation of executable memory allocation, which libpas calls "jit_heap". The initial implementation of this only used libpas's bitfit and large algorithms. Bitfit was used for smaller objects and large was used for larger objects. The libpas segregated heap was disabled in jit_heap. This made sense because: - Bitfit and large support the shrink() call, where we shrink an allocation in-place. Executable allocation supports this to aid branch compaction (we compact code after we copy it into its final resting place, which is after we allocate the memory - so after we finish compaction, we can only shrink the allocation in-place or not at all). - Segregated heaps have some virtual address space overheads, and memory overheads, that the bitfit and large heaps don't have. This happens because segreated heaps will dedicate each page to objects of exactly one size forever. However, segregated heaps are substantially faster than bitfit heaps. They are faster under serial allocation thanks to the fact that no locks need to be acquired for a typical allocation or deallocation. They are even more faster under parallel allocation thanks to thread-local caching. This patch enables segregated heaps for the smallest jit_heap allocations (<=2000 bytes). The cutoff threshold is runtime configurable, so it's possible to disable segregated heaps at runtime by setting the cutoff to 0. With the 2000 threshold, this appears to be a 0.3% Speedometer2 speed-up. While there is a theoretical possibility of memory overhead, I haven't seen it. If we are using jump islands then the virtual memory overhead of segregated heaps will just mean that we use jump islands more frequently, which would manifest as a performance regression -- but I've not seen any such regression. So, this disables the segregated heap if the JIT pool size is too small (see changes to ExecutableAllocator.cpp in JSC). * libpas/libpas.xcodeproj/project.pbxproj: * libpas/src/libpas/jit_heap.c: (jit_heap_shrink): * libpas/src/libpas/jit_heap_config.c: (jit_small_segregated_allocate_page): (jit_small_segregated_create_page_header): (jit_small_destroy_page_header): (jit_small_segregated_shared_page_directory_selector): (jit_small_bitfit_allocate_page): (jit_small_bitfit_create_page_header): (jit_medium_bitfit_create_page_header): (jit_medium_destroy_page_header): (jit_prepare_to_enumerate): (jit_small_bitfit_destroy_page_header): Deleted. (jit_medium_bitfit_destroy_page_header): Deleted. * libpas/src/libpas/jit_heap_config.h: (jit_small_page_header_for_boundary): (jit_small_boundary_for_page_header): (jit_medium_page_header_for_boundary): (jit_medium_boundary_for_page_header): (jit_heap_config_page_header): (jit_small_bitfit_page_header_for_boundary): Deleted. (jit_small_bitfit_boundary_for_page_header): Deleted. (jit_medium_bitfit_page_header_for_boundary): Deleted. (jit_medium_bitfit_boundary_for_page_header): Deleted. * libpas/src/libpas/jit_heap_config_root_data.h: * libpas/src/libpas/pas_bitfit_heap.c: (pas_bitfit_heap_select_variant): (pas_bitfit_heap_construct_and_insert_size_class): * libpas/src/libpas/pas_bitfit_heap.h: * libpas/src/libpas/pas_bitfit_page_config.h: (pas_bitfit_page_config_is_enabled): * libpas/src/libpas/pas_heap_config.h: (pas_heap_config_segregated_heap_min_align_shift): (pas_heap_config_segregated_heap_min_align): * libpas/src/libpas/pas_segregated_heap.c: (min_align_for_heap): (min_object_size_for_heap): (max_segregated_object_size_for_heap): (max_bitfit_object_size_for_heap): (max_object_size_for_heap): (pas_segregated_heap_ensure_allocator_index): (pas_segregated_heap_ensure_size_directory_for_size): (min_object_size_for_heap_config): Deleted. (max_segregated_object_size_for_heap_config): Deleted. (max_bitfit_object_size_for_heap_config): Deleted. (max_object_size_for_heap_config): Deleted. * libpas/src/libpas/pas_segregated_heap.h: (pas_segregated_heap_index_for_size): (pas_segregated_heap_size_for_index): * libpas/src/libpas/pas_segregated_page.c: (pas_segregated_page_construct): * libpas/src/libpas/pas_segregated_page_config.h: (pas_segregated_page_config_is_enabled): * libpas/src/libpas/pas_segregated_page_config_kind.def: * libpas/src/libpas/pas_segregated_page_config_kind_and_role.h: * libpas/src/libpas/pas_segregated_size_directory.c: (pas_segregated_size_directory_create): * libpas/src/test/IsoHeapChaosTests.cpp: (std::addAllTests): * libpas/src/test/JITHeapTests.cpp: (std::testAllocationSize): (addJITHeapTests): * libpas/src/test/TestHarness.cpp: (main): * libpas/src/test/ViewCacheTests.cpp: Added. (std::setupConfig): (std::testDisableViewCacheUsingBoundForNoViewCache): (std::
[webkit-changes] [289491] trunk/Source/bmalloc
Title: [289491] trunk/Source/bmalloc Revision 289491 Author fpi...@apple.com Date 2022-02-09 11:31:06 -0800 (Wed, 09 Feb 2022) Log Message [libpas] add documentation https://bugs.webkit.org/show_bug.cgi?id=236385 Rubber stamped by Mark Lam. * libpas/Documentation.md: Added. Modified Paths trunk/Source/bmalloc/ChangeLog Added Paths trunk/Source/bmalloc/libpas/Documentation.md Diff Modified: trunk/Source/bmalloc/ChangeLog (289490 => 289491) --- trunk/Source/bmalloc/ChangeLog 2022-02-09 18:56:42 UTC (rev 289490) +++ trunk/Source/bmalloc/ChangeLog 2022-02-09 19:31:06 UTC (rev 289491) @@ -1,3 +1,12 @@ +2022-02-09 Filip Pizlo + +[libpas] add documentation +https://bugs.webkit.org/show_bug.cgi?id=236385 + +Rubber stamped by Mark Lam. + +* libpas/Documentation.md: Added. + 2022-02-05 Yusuke Suzuki Thread suspend and resume should take a global lock to avoid deadlock Added: trunk/Source/bmalloc/libpas/Documentation.md (0 => 289491) --- trunk/Source/bmalloc/libpas/Documentation.md (rev 0) +++ trunk/Source/bmalloc/libpas/Documentation.md 2022-02-09 19:31:06 UTC (rev 289491) @@ -0,0 +1,1326 @@ +# All About Libpas, Phil's Super Fast Malloc + +Filip Pizlo, Apple Inc., February 2022 + +# License + +Copyright (c) 2022 Apple Inc. All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: + +1. Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in the + documentation and/or other materials provided with the distribution. + +THIS SOFTWARE IS PROVIDED BY APPLE INC. ``AS IS'' AND ANY +EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR +PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL APPLE INC. OR +CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, +EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, +PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR +PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY +OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +# Introduction + +This document describes how libpas works as of a361efa96ca4b2ff6bdfc28bc7eb1a678cde75be, so a bit ahead of +where WebKit was as of r289146. Libpas is a fast and memory-efficient memory allocation toolkit capable of +supporting many heaps at once, engineered with the hopes that someday it'll be used for comprehensive isoheaping +of all malloc/new callsites in C/C++ programs. + +Since WebKit r213753, we've been steadinly enabling libpas as a replacement for WebKit's bmalloc and +MetaAllocator. This has so far added up to a ~2% Speedometer2 speed-up and a ~8% memory improvement (on multiple +memory benchmarks). Half of the speed-up comes from replacing the MetaAllocator, which was _javascript_Core's old +way of managing executable memory. Now, JSC uses libpas's jit_heap to manage executable memory. The other half +of the speed-up comes from replacing everything that bmalloc provided -- the fastMalloc API, the Gigacage API, +and the IsoHeap<> API. All of the memory improvement comes from replacing bmalloc (the MetaAllocator was already +fairly memory-efficient). + +This document is structured as follows. First I describe the goals of libpas; these are the things that a +malloc-like API created out of libpas should be able to expose as fast and memory-efficient functions. Then I +describe the coding style. Next I tell all about the design. Finally I talk about how libpas is tested. + +# Goals of Libpas + +Libpas tries to be: + +- Fast. The goal is to beat bmalloc performance on single-threaded code. Bmalloc was previously the fastest + known malloc for WebKit. +- Scalable. Libpas is meant to scale well on multi-core devices. +- Memory-efficient. The goal is to beat bmalloc memory usage across the board. Part of the strategy for memory + efficiency is consistent use of first-fit allocation. +- External metadata. Libpas never puts information about a free object inside that object. The metadata is + always elsewhere. So, there's no way for a use-after-free to corrupt libpas's understanding of memory. +- Multiple heap configurations. Not all programs want the same time-memory trade-off. Some malloc users have + very bizarre requirements, like what _javascript_Core does with its ExecutableAllocator. The goal is to support + all kinds of special allocator needs simultaneously in one library. +- Boatloads of heaps. Libpas was written with the dream of obv
[webkit-changes] [288342] trunk/Source/bmalloc
Title: [288342] trunk/Source/bmalloc Revision 288342 Author fpi...@apple.com Date 2022-01-20 18:43:34 -0800 (Thu, 20 Jan 2022) Log Message [libpas] medium directory lookup should bail if begin_index is zero to catch races with expendable memory decommit (cherry pick 434465bfb8e0c285d6763cf6aa0e04982199f824) https://bugs.webkit.org/show_bug.cgi?id=235280 Reviewed by Yusuke Suzuki. I've been seeing crashes in pas_segregated_heap_ensure_allocator_index where the directory that is passed to the function doesn't match the size. The most likely reason why this is happening is that the medium directory lookup raced with expendable memory decommit and returned the wrong directory. To figure out how this happens, I added a bunch of tests to ExpendableMemoryTests. This change includes various small fixes (like removing assertions) that were found by doing such testing, and it also includes a test and a change that I think exactly catches what is going on: - Expendable memory is decommitted so that the medium lookup sees begin_index == 0, but end_index still has its original value. This will cause it to return a tuple that is for a too-large size class. - Some other thread rematerializes the expendable memory right after the medium lookup finishes, but before it loads the directory. - The medium lookup finally loads the directory from the tuple, and now sees a non-NULL directory, so it thinks that everything is fine. This race barely "works" since: - Any other field in the medium tuple being zero would cause the medium lookup to fail, which would then cause a slow path that rematerializes expendable memory under a lock. - Rematerialization of expendable memory adjusts the mutation count, so this race would only go undetected if the rematerialization happened after the medium lookup search but before when the medium lookup loads the directory. The solution is to just have the medium lookup fail if begin_index == 0. Begin_index can never legitimately be zero, because there's no way that a size class would want to be responsible for both index 0 (i.e. the zero-byte object) and objects big enough to require medium lookup. This adds new tests. While running those new tests, I found and fixed two other bugs: - Recomputation of the index_to_small_allocator_index table subtly mishandles the cached_index case. Previously, it was only special-casing it only when the directory was not participating in lookup tables at all, but actually it needs to special-case it anytime that the directory doesn't otherwise think that it should set the entry at cached_index. - Expendable memory commit/decommit was playing fast-and-loose with version numbers. This fixes it so that there is a global monotonically increasing version number. * libpas/src/libpas/bmalloc_heap.c: (bmalloc_flex_heap_ref_get_heap): (bmalloc_auxiliary_heap_ref_get_heap): (bmalloc_get_heap): * libpas/src/libpas/bmalloc_heap.h: * libpas/src/libpas/pas_expendable_memory.c: (pas_expendable_memory_state_version_next): (pas_expendable_memory_construct): (pas_expendable_memory_commit_if_necessary): (scavenge_impl): (pas_expendable_memory_scavenge): * libpas/src/libpas/pas_expendable_memory.h: * libpas/src/libpas/pas_scavenger.c: (handle_expendable_memory): (scavenger_thread_main): (pas_scavenger_decommit_expendable_memory): (pas_scavenger_fake_decommit_expendable_memory): * libpas/src/libpas/pas_scavenger.h: * libpas/src/libpas/pas_segregated_heap.c: (medium_directory_tuple_for_index_impl): (pas_segregated_heap_medium_directory_tuple_for_index): (pas_segregated_heap_medium_allocator_index_for_index): (recompute_size_lookup): (rematerialize_size_lookup_set_medium_directory_tuple): (pas_segregated_heap_ensure_allocator_index): (check_size_lookup_recomputation_set_medium_directory_tuple): (check_size_lookup_recomputation_dump_directory): (check_size_lookup_recomputation): (check_size_lookup_recomputation_if_appropriate): (pas_segregated_heap_ensure_size_directory_for_size): * libpas/src/libpas/pas_segregated_heap.h: * libpas/src/libpas/pas_segregated_size_directory.h: (pas_segregated_size_directory_get_tlc_allocator_index): * libpas/src/libpas/pas_try_allocate_primitive.h: (pas_try_allocate_primitive_impl_casual_case): (pas_try_allocate_primitive_impl_inline_only): * libpas/src/test/ExpendableMemoryTests.cpp: (std::testRage): (std::testRematerializeAfterSearchOfDecommitted): (std::testBasicSizeClass): (addExpendableMemoryTests): * libpas/src/test/TestHarness.cpp: (RuntimeConfigTestScope::RuntimeConfigTestScope): Modified Paths trunk/Source/bmalloc/ChangeLog trunk/Source/bmalloc/libpas/src/libpas/bmalloc_heap.c trunk/Source/bmalloc/libpas/src/libpas/bmalloc_heap.h trunk/Source/bmalloc/libpas/src/libpas/pas_expendable_memory.c trunk/Source/bmalloc/libpas/src/libpas/pas_expendable_memory.h trunk/Source/bmalloc/libpas/src/libpas/pas_scavenger.c trunk/Source/bmalloc/libpas/src/libpas/pas_scavenger.h trunk/Source/bmalloc/libpas/src/libpas/pas_
[webkit-changes] [287994] trunk/Source/bmalloc
Title: [287994] trunk/Source/bmalloc
Revision 287994
Author fpi...@apple.com
Date 2022-01-13 14:45:11 -0800 (Thu, 13 Jan 2022)
Log Message
[libpas] pas_segregated_page_lock_with_mode in try_lock mode should check that the page still uses the lock after the try_lock
https://bugs.webkit.org/show_bug.cgi?id=235203
Reviewed by Yusuke Suzuki.
The bug I was trying to find by assertions in bug 235190 is that lock_with_mode has an incorrect
implementation of the try_lock case. It forgets to check if the lock it acquired is the right one
after locking.
I don't know how to test this without writing a test that is very gross. It's a super subtle race
condition - one that would be hard to reliably trigger even if I used the race_test_hooks
functionality.
* libpas/src/libpas/pas_local_allocator.c:
(stop_impl):
* libpas/src/libpas/pas_segregated_page_inlines.h:
(pas_segregated_page_switch_lock_with_mode):
Modified Paths
trunk/Source/bmalloc/ChangeLog
trunk/Source/bmalloc/libpas/src/libpas/pas_local_allocator.c
trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_page_inlines.h
Diff
Modified: trunk/Source/bmalloc/ChangeLog (287993 => 287994)
--- trunk/Source/bmalloc/ChangeLog 2022-01-13 21:53:09 UTC (rev 287993)
+++ trunk/Source/bmalloc/ChangeLog 2022-01-13 22:45:11 UTC (rev 287994)
@@ -1,5 +1,25 @@
2022-01-13 Filip Pizlo
+[libpas] pas_segregated_page_lock_with_mode in try_lock mode should check that the page still uses the lock after the try_lock
+https://bugs.webkit.org/show_bug.cgi?id=235203
+
+Reviewed by Yusuke Suzuki.
+
+The bug I was trying to find by assertions in bug 235190 is that lock_with_mode has an incorrect
+implementation of the try_lock case. It forgets to check if the lock it acquired is the right one
+after locking.
+
+I don't know how to test this without writing a test that is very gross. It's a super subtle race
+condition - one that would be hard to reliably trigger even if I used the race_test_hooks
+functionality.
+
+* libpas/src/libpas/pas_local_allocator.c:
+(stop_impl):
+* libpas/src/libpas/pas_segregated_page_inlines.h:
+(pas_segregated_page_switch_lock_with_mode):
+
+2022-01-13 Filip Pizlo
+
[libpas] add assertions that we aren't switching to a NULL lock
https://bugs.webkit.org/show_bug.cgi?id=235190
Modified: trunk/Source/bmalloc/libpas/src/libpas/pas_local_allocator.c (287993 => 287994)
--- trunk/Source/bmalloc/libpas/src/libpas/pas_local_allocator.c 2022-01-13 21:53:09 UTC (rev 287993)
+++ trunk/Source/bmalloc/libpas/src/libpas/pas_local_allocator.c 2022-01-13 22:45:11 UTC (rev 287994)
@@ -181,8 +181,8 @@
if (!pas_segregated_page_switch_lock_with_mode(page, &held_lock, page_lock_mode, page_config))
return false;
-if (!pas_segregated_page_config_is_utility(page_config) && !held_lock)
-pas_panic("Should be holding a lock after pas_segregated_page_switch_lock_with_mode in stop_impl\n");
+if (!pas_segregated_page_config_is_utility(page_config))
+PAS_ASSERT(held_lock);
page_config.specialized_local_allocator_return_memory_to_page(
allocator, view, page, directory, heap_lock_hold_mode);
Modified: trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_page_inlines.h (287993 => 287994)
--- trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_page_inlines.h 2022-01-13 21:53:09 UTC (rev 287993)
+++ trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_page_inlines.h 2022-01-13 22:45:11 UTC (rev 287994)
@@ -240,9 +240,33 @@
switch (lock_mode) {
case pas_lock_lock_mode_try_lock: {
pas_lock* page_lock;
+pas_compiler_fence();
page_lock = page->lock_ptr;
PAS_TESTING_ASSERT(page_lock);
-return pas_lock_switch_with_mode(held_lock, page_lock, pas_lock_lock_mode_try_lock);
+if (*held_lock == page_lock) {
+pas_compiler_fence();
+return true;
+}
+pas_compiler_fence();
+if (*held_lock)
+pas_lock_unlock(*held_lock);
+pas_compiler_fence();
+for (;;) {
+pas_lock* new_page_lock;
+if (!pas_lock_try_lock(page_lock)) {
+*held_lock = NULL;
+pas_compiler_fence();
+return false;
+}
+new_page_lock = page->lock_ptr;
+if (page_lock == new_page_lock) {
+*held_lock = page_lock;
+pas_compiler_fence();
+return true;
+}
+pas_lock_unlock(page_lock);
+page_lock = new_page_lock;
+}
}
case pas_lock_lock_mode_lock: {
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [287991] trunk/Source/bmalloc
Title: [287991] trunk/Source/bmalloc
Revision 287991
Author fpi...@apple.com
Date 2022-01-13 13:12:09 -0800 (Thu, 13 Jan 2022)
Log Message
[libpas] add assertions that we aren't switching to a NULL lock
https://bugs.webkit.org/show_bug.cgi?id=235190
Reviewed by Yusuke Suzuki.
This adds a pas_panic call when pas_local_allocator_stop sees a NULL page->lock_ptr. That's one
possible explanation of a very rare crash I'm seeing where return_memory_to_page fails its assertion
that we are holding the page lock.
This also adds TESTING asserts in a bunch of other places. The PAS_TESTING_ASSERTS about this are in
places that are perf-sensitive, so we probably cannot assert in production. The hope behind those is
that it will help to catch this issue in test_pas.
* libpas/src/libpas/pas_local_allocator.c:
(stop_impl):
* libpas/src/libpas/pas_segregated_page.c:
(pas_segregated_page_switch_lock_and_rebias_while_ineligible_impl):
* libpas/src/libpas/pas_segregated_page_inlines.h:
(pas_segregated_page_lock_with_unbias_not_utility):
(pas_segregated_page_lock_with_unbias):
(pas_segregated_page_lock):
(pas_segregated_page_switch_lock_impl):
(pas_segregated_page_switch_lock_with_mode):
Modified Paths
trunk/Source/bmalloc/ChangeLog
trunk/Source/bmalloc/libpas/src/libpas/pas_local_allocator.c
trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_page.c
trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_page_inlines.h
Diff
Modified: trunk/Source/bmalloc/ChangeLog (287990 => 287991)
--- trunk/Source/bmalloc/ChangeLog 2022-01-13 21:11:10 UTC (rev 287990)
+++ trunk/Source/bmalloc/ChangeLog 2022-01-13 21:12:09 UTC (rev 287991)
@@ -1,3 +1,29 @@
+2022-01-13 Filip Pizlo
+
+[libpas] add assertions that we aren't switching to a NULL lock
+https://bugs.webkit.org/show_bug.cgi?id=235190
+
+Reviewed by Yusuke Suzuki.
+
+This adds a pas_panic call when pas_local_allocator_stop sees a NULL page->lock_ptr. That's one
+possible explanation of a very rare crash I'm seeing where return_memory_to_page fails its assertion
+that we are holding the page lock.
+
+This also adds TESTING asserts in a bunch of other places. The PAS_TESTING_ASSERTS about this are in
+places that are perf-sensitive, so we probably cannot assert in production. The hope behind those is
+that it will help to catch this issue in test_pas.
+
+* libpas/src/libpas/pas_local_allocator.c:
+(stop_impl):
+* libpas/src/libpas/pas_segregated_page.c:
+(pas_segregated_page_switch_lock_and_rebias_while_ineligible_impl):
+* libpas/src/libpas/pas_segregated_page_inlines.h:
+(pas_segregated_page_lock_with_unbias_not_utility):
+(pas_segregated_page_lock_with_unbias):
+(pas_segregated_page_lock):
+(pas_segregated_page_switch_lock_impl):
+(pas_segregated_page_switch_lock_with_mode):
+
2022-01-12 Filip Pizlo
[libpas] thread_local_cache should not be allocated in the compact heap (cherry pick 11afcedfb5968f6894379ff1a41dd449ba7745f6)
Modified: trunk/Source/bmalloc/libpas/src/libpas/pas_local_allocator.c (287990 => 287991)
--- trunk/Source/bmalloc/libpas/src/libpas/pas_local_allocator.c 2022-01-13 21:11:10 UTC (rev 287990)
+++ trunk/Source/bmalloc/libpas/src/libpas/pas_local_allocator.c 2022-01-13 21:12:09 UTC (rev 287991)
@@ -180,6 +180,9 @@
if (!pas_segregated_page_switch_lock_with_mode(page, &held_lock, page_lock_mode, page_config))
return false;
+
+if (!pas_segregated_page_config_is_utility(page_config) && !held_lock)
+pas_panic("Should be holding a lock after pas_segregated_page_switch_lock_with_mode in stop_impl\n");
page_config.specialized_local_allocator_return_memory_to_page(
allocator, view, page, directory, heap_lock_hold_mode);
Modified: trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_page.c (287990 => 287991)
--- trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_page.c 2022-01-13 21:11:10 UTC (rev 287990)
+++ trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_page.c 2022-01-13 21:12:09 UTC (rev 287991)
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2018-2021 Apple Inc. All rights reserved.
+ * Copyright (c) 2018-2022 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -125,6 +125,7 @@
bool got_right_lock;
page_lock = page->lock_ptr;
+PAS_TESTING_ASSERT(page_lock);
if (*held_lock == page_lock && *held_lock == &cache_node->page_lock) {
pas_compiler_fence();
Modified: trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_page_inlines.h (287990 => 287991)
--- trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_page_inlines.h 2022-01-13 21:11:10 UTC (rev 287990)
+++ trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_page_inlines.h 2022-01-13 21:12:
[webkit-changes] [287968] trunk/Source/bmalloc
Title: [287968] trunk/Source/bmalloc Revision 287968 Author fpi...@apple.com Date 2022-01-12 18:52:00 -0800 (Wed, 12 Jan 2022) Log Message [libpas] thread_local_cache should not be allocated in the compact heap (cherry pick 11afcedfb5968f6894379ff1a41dd449ba7745f6) https://bugs.webkit.org/show_bug.cgi?id=235096 Reviewed by Yusuke Suzuki. Thread local caches can get quite large because of how libpas uses them, we can allocate one per thread, and we reallocate them with exponential resizing, so there's a lot of wasted space and a decent amount of fragmentation. This shows up as occasional crashes trying to allocate a thread local cache out of the compact heap. This moves thread local caches out of the compact heap. They were only ever there because partial views sometimes need to point to the local_allocator's bitvector, but that's part of the thread local cache. So, that means that either the partial views' bits pointer cannot be a compact pointer, or the thread_local_cache needs to be in the compact heap. So, the thread_local_cache ended up in the compact heap to keep that pointer small. This change works around the problem: it's rare that the partial views' bits pointer points at the local_allocator's bits, and none of the fast path cases where we access that pointer will ever see it in that state. So, this makes the pointer either point to a utility-heap-allocated box that contains the full pointer, or it points at the actual array allocated in the compact heap. The utility heap is in the compact heap, so the compact pointer can point at either one. The implementation of this is encapsulated as pas_lenient_compact_ptr. It's a bit gross; storing to it only works when you're holding the heap lock, for example. This is perf-neutral on Speedometer. This is perf-neutral on JS2 cli with full JSC isoheaps (i.e. the patch from bug 231938). It's a 0.4% regression on RAMification with full JSC isoheaps, but I'm not going to worry about that because trunk doesn't have full JSC isoheaps, and JSC isoheaps requires some change like this to work reliably (currently it'll randomly run out of compact heap). * bmalloc.xcodeproj/project.pbxproj: * libpas/libpas.xcodeproj/project.pbxproj: * libpas/src/libpas/pas_enumerate_segregated_heaps.c: (enumerate_partial_view): * libpas/src/libpas/pas_full_alloc_bits_inlines.h: (pas_full_alloc_bits_create_for_partial_but_not_primordial): (pas_full_alloc_bits_create_for_partial): * libpas/src/libpas/pas_lenient_compact_ptr.h: Added. * libpas/src/libpas/pas_lenient_compact_ptr_inlines.h: Added. * libpas/src/libpas/pas_lenient_compact_unsigned_ptr.c: Added. * libpas/src/libpas/pas_lenient_compact_unsigned_ptr.h: Added. * libpas/src/libpas/pas_local_allocator.c: (pas_local_allocator_move): * libpas/src/libpas/pas_local_allocator_inlines.h: (pas_local_allocator_set_up_free_bits): (pas_local_allocator_start_allocating_in_primordial_partial_view): (pas_local_allocator_bless_primordial_partial_view_before_stopping): * libpas/src/libpas/pas_segregated_partial_view.c: (pas_segregated_partial_view_create): (compute_summary): * libpas/src/libpas/pas_segregated_partial_view.h: * libpas/src/libpas/pas_segregated_view_allocator_inlines.h: (pas_segregated_view_will_start_allocating): * libpas/src/libpas/pas_thread_local_cache.c: (deallocate): (allocate_cache): * libpas/src/test/LotsOfHeapsAndThreads.cpp: Added. (std::testLotsOfHeapsAndThreads): (addLotsOfHeapsAndThreadsTests): * libpas/src/test/TestHarness.cpp: (main): Modified Paths trunk/Source/bmalloc/ChangeLog trunk/Source/bmalloc/bmalloc.xcodeproj/project.pbxproj trunk/Source/bmalloc/libpas/libpas.xcodeproj/project.pbxproj trunk/Source/bmalloc/libpas/src/libpas/pas_enumerate_segregated_heaps.c trunk/Source/bmalloc/libpas/src/libpas/pas_full_alloc_bits_inlines.h trunk/Source/bmalloc/libpas/src/libpas/pas_local_allocator.c trunk/Source/bmalloc/libpas/src/libpas/pas_local_allocator_inlines.h trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_partial_view.c trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_partial_view.h trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_view_allocator_inlines.h trunk/Source/bmalloc/libpas/src/libpas/pas_thread_local_cache.c trunk/Source/bmalloc/libpas/src/test/TestHarness.cpp Added Paths trunk/Source/bmalloc/libpas/src/libpas/pas_lenient_compact_ptr.h trunk/Source/bmalloc/libpas/src/libpas/pas_lenient_compact_ptr_inlines.h trunk/Source/bmalloc/libpas/src/libpas/pas_lenient_compact_unsigned_ptr.c trunk/Source/bmalloc/libpas/src/libpas/pas_lenient_compact_unsigned_ptr.h trunk/Source/bmalloc/libpas/src/test/LotsOfHeapsAndThreads.cpp Diff Modified: trunk/Source/bmalloc/ChangeLog (287967 => 287968) --- trunk/Source/bmalloc/ChangeLog 2022-01-13 02:17:09 UTC (rev 287967) +++ trunk/Source/bmalloc/ChangeLog 2022-01-13 02:52:00 UTC (rev 287968) @@ -1,3 +1,66 @@ +2022-01-12 Filip Pizlo + +[libpas] thread_local_cache should not be allocated in the compact heap (cherry pick 11afce
[webkit-changes] [286587] trunk/Source/bmalloc
Title: [286587] trunk/Source/bmalloc Revision 286587 Author fpi...@apple.com Date 2021-12-06 21:52:22 -0800 (Mon, 06 Dec 2021) Log Message [libpas] Clean up what the machine code looks like under LTO https://bugs.webkit.org/show_bug.cgi?id=233909 Reviewed by Yusuke Suzuki. During the very painful perf burndown of libpas that got it to be a progression (rather than a regression) versus bmalloc, I found that certain key fast paths - like fastMalloc and fastFree - perform better when they do not have a stack frame. For this to happen, they must only make tail calls. Sadly, LTO was inlining a slow path into fastFree (i.e. pas_deallocate), and this slow path had an assertion, and the call to pas_assertion_failed was not a tail call. This fixes the problem comprehensively: - We now compile pas_assertion_failed as a breakpoint, just like WebKit would do. This is better for code size and maybe it could sometimes be better for performance. - The slow path that was getting inlined is now marked PAS_NEVER_INLINE. - Inspecting the machine code, I found a couple other slow paths that were being inlined in a bunch of places, and also marked them NEVER_INLINE. If my past experiences are right, this could be a tiny speed-up on malloc-heavy workloads. * libpas/src/libpas/pas_lock.c: (pas_lock_lock_slow): * libpas/src/libpas/pas_lock.h: * libpas/src/libpas/pas_monotonic_time.c: (get_timebase_info_slow): (get_timebase_info): * libpas/src/libpas/pas_thread_local_cache.c: (pas_thread_local_cache_append_deallocation_slow): * libpas/src/libpas/pas_thread_local_cache.h: * libpas/src/libpas/pas_utils.c: * libpas/src/libpas/pas_utils.h: (pas_assertion_failed): (pas_assertion_failed_noreturn_silencer): Modified Paths trunk/Source/bmalloc/ChangeLog trunk/Source/bmalloc/libpas/src/libpas/pas_lock.c trunk/Source/bmalloc/libpas/src/libpas/pas_lock.h trunk/Source/bmalloc/libpas/src/libpas/pas_monotonic_time.c trunk/Source/bmalloc/libpas/src/libpas/pas_thread_local_cache.c trunk/Source/bmalloc/libpas/src/libpas/pas_thread_local_cache.h trunk/Source/bmalloc/libpas/src/libpas/pas_utils.c trunk/Source/bmalloc/libpas/src/libpas/pas_utils.h Diff Modified: trunk/Source/bmalloc/ChangeLog (286586 => 286587) --- trunk/Source/bmalloc/ChangeLog 2021-12-07 04:12:27 UTC (rev 286586) +++ trunk/Source/bmalloc/ChangeLog 2021-12-07 05:52:22 UTC (rev 286587) @@ -1,3 +1,43 @@ +2021-12-06 Filip Pizlo + +[libpas] Clean up what the machine code looks like under LTO +https://bugs.webkit.org/show_bug.cgi?id=233909 + +Reviewed by Yusuke Suzuki. + +During the very painful perf burndown of libpas that got it to be a progression (rather than a +regression) versus bmalloc, I found that certain key fast paths - like fastMalloc and fastFree - perform +better when they do not have a stack frame. For this to happen, they must only make tail calls. + +Sadly, LTO was inlining a slow path into fastFree (i.e. pas_deallocate), and this slow path had an +assertion, and the call to pas_assertion_failed was not a tail call. + +This fixes the problem comprehensively: + +- We now compile pas_assertion_failed as a breakpoint, just like WebKit would do. This is better for + code size and maybe it could sometimes be better for performance. + +- The slow path that was getting inlined is now marked PAS_NEVER_INLINE. + +- Inspecting the machine code, I found a couple other slow paths that were being inlined in a bunch of + places, and also marked them NEVER_INLINE. + +If my past experiences are right, this could be a tiny speed-up on malloc-heavy workloads. + +* libpas/src/libpas/pas_lock.c: +(pas_lock_lock_slow): +* libpas/src/libpas/pas_lock.h: +* libpas/src/libpas/pas_monotonic_time.c: +(get_timebase_info_slow): +(get_timebase_info): +* libpas/src/libpas/pas_thread_local_cache.c: +(pas_thread_local_cache_append_deallocation_slow): +* libpas/src/libpas/pas_thread_local_cache.h: +* libpas/src/libpas/pas_utils.c: +* libpas/src/libpas/pas_utils.h: +(pas_assertion_failed): +(pas_assertion_failed_noreturn_silencer): + 2021-12-06 Yusuke Suzuki [libpas] Set pthread_setspecific with marker in TLS destructor to detect TLS is destroyed Modified: trunk/Source/bmalloc/libpas/src/libpas/pas_lock.c (286586 => 286587) --- trunk/Source/bmalloc/libpas/src/libpas/pas_lock.c 2021-12-07 04:12:27 UTC (rev 286586) +++ trunk/Source/bmalloc/libpas/src/libpas/pas_lock.c 2021-12-07 05:52:22 UTC (rev 286587) @@ -1,5 +1,5 @@ /* - * Copyright (c) 2020 Apple Inc. All rights reserved. + * Copyright (c) 2020-2021 Apple Inc. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions @@ -31,7 +31,7 @@ #if PAS_USE_SPINLOCKS -void pas_
[webkit-changes] [286516] trunk/Source/bmalloc
Title: [286516] trunk/Source/bmalloc
Revision 286516
Author fpi...@apple.com
Date 2021-12-03 14:48:23 -0800 (Fri, 03 Dec 2021)
Log Message
[libpas] Bitfit allocator has a wrong assertion when a page's max_free is enough for the size of an allocation, not enough for that allocation's size class, and the object of that size is not aligned to the currently requested alignment
https://bugs.webkit.org/show_bug.cgi?id=233831
Reviewed by Yusuke Suzuki.
What a combination of conditions:
- We just failed bitfit allocation in a page, which gives us some max_free (aka largest_available), and the allocation had nontrivial alignment.
- The max_free is smaller than the size class.
- The max_free is larger than the requested size.
- The max_free object is not aligned to the requested alignment.
The code handles this fine, but has a wrong assertion about it.
This change fixes the assertion and adds a test that deterministically reproduced the issue.
* libpas/libpas.xcodeproj/project.pbxproj:
* libpas/src/libpas/pas_bitfit_allocator.c:
(pas_bitfit_allocator_finish_failing):
* libpas/src/libpas/pas_bitfit_allocator_inlines.h:
(pas_bitfit_allocator_try_allocate):
* libpas/src/test/BitfitTests.cpp: Added.
(std::getBitfitSizeClasses):
(std::assertSizeClasses):
(std::testAllocateAlignedSmallerThanSizeClassAndSmallerThanLargestAvailable):
(addBitfitTests):
* libpas/src/test/TestHarness.cpp:
(main):
Modified Paths
trunk/Source/bmalloc/ChangeLog
trunk/Source/bmalloc/libpas/libpas.xcodeproj/project.pbxproj
trunk/Source/bmalloc/libpas/src/libpas/pas_bitfit_allocator.c
trunk/Source/bmalloc/libpas/src/libpas/pas_bitfit_allocator_inlines.h
trunk/Source/bmalloc/libpas/src/test/TestHarness.cpp
Added Paths
trunk/Source/bmalloc/libpas/src/test/BitfitTests.cpp
Diff
Modified: trunk/Source/bmalloc/ChangeLog (286515 => 286516)
--- trunk/Source/bmalloc/ChangeLog 2021-12-03 21:58:02 UTC (rev 286515)
+++ trunk/Source/bmalloc/ChangeLog 2021-12-03 22:48:23 UTC (rev 286516)
@@ -1,3 +1,34 @@
+2021-12-03 Filip Pizlo
+
+[libpas] Bitfit allocator has a wrong assertion when a page's max_free is enough for the size of an allocation, not enough for that allocation's size class, and the object of that size is not aligned to the currently requested alignment
+https://bugs.webkit.org/show_bug.cgi?id=233831
+
+Reviewed by Yusuke Suzuki.
+
+What a combination of conditions:
+
+- We just failed bitfit allocation in a page, which gives us some max_free (aka largest_available), and the allocation had nontrivial alignment.
+- The max_free is smaller than the size class.
+- The max_free is larger than the requested size.
+- The max_free object is not aligned to the requested alignment.
+
+The code handles this fine, but has a wrong assertion about it.
+
+This change fixes the assertion and adds a test that deterministically reproduced the issue.
+
+* libpas/libpas.xcodeproj/project.pbxproj:
+* libpas/src/libpas/pas_bitfit_allocator.c:
+(pas_bitfit_allocator_finish_failing):
+* libpas/src/libpas/pas_bitfit_allocator_inlines.h:
+(pas_bitfit_allocator_try_allocate):
+* libpas/src/test/BitfitTests.cpp: Added.
+(std::getBitfitSizeClasses):
+(std::assertSizeClasses):
+(std::testAllocateAlignedSmallerThanSizeClassAndSmallerThanLargestAvailable):
+(addBitfitTests):
+* libpas/src/test/TestHarness.cpp:
+(main):
+
2021-12-02 Filip Pizlo
[libpas] Update to 96f9f4c28dc119695311c7c6bd81ed1f3f4e260c (allow more specialization of partial versus exclusive allocation)
Modified: trunk/Source/bmalloc/libpas/libpas.xcodeproj/project.pbxproj (286515 => 286516)
--- trunk/Source/bmalloc/libpas/libpas.xcodeproj/project.pbxproj 2021-12-03 21:58:02 UTC (rev 286515)
+++ trunk/Source/bmalloc/libpas/libpas.xcodeproj/project.pbxproj 2021-12-03 22:48:23 UTC (rev 286516)
@@ -568,6 +568,7 @@
2C48132D273F4159006CAB55 /* ExpendableMemoryTests.cpp in Sources */ = {isa = PBXBuildFile; fileRef = 2C48132C273F4159006CAB55 /* ExpendableMemoryTests.cpp */; };
2C85DC4127128F0F00367905 /* pas_try_allocate_intrinsic.h in Headers */ = {isa = PBXBuildFile; fileRef = 2C85DC4027128F0F00367905 /* pas_try_allocate_intrinsic.h */; };
2C91E5502718DA9A00D67FF9 /* pas_size_lookup_mode.h in Headers */ = {isa = PBXBuildFile; fileRef = 2C91E54F2718DA9A00D67FF9 /* pas_size_lookup_mode.h */; };
+ 2CE2AE35275A953E00D02BBC /* BitfitTests.cpp in Sources */ = {isa = PBXBuildFile; fileRef = 2CE2AE34275A953E00D02BBC /* BitfitTests.cpp */; };
/* End PBXBuildFile section */
/* Begin PBXContainerItemProxy section */
@@ -1252,6 +1253,7 @@
2C48132C273F4159006CAB55 /* ExpendableMemoryTests.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; path = ExpendableMemoryTests.cpp; sourceTree = ""; };
2C85DC4027128F0F00367905 /* pas_tr
[webkit-changes] [284456] trunk/Source/WTF
Title: [284456] trunk/Source/WTF
Revision 284456
Author fpi...@apple.com
Date 2021-10-19 09:00:19 -0700 (Tue, 19 Oct 2021)
Log Message
StringBuffer should really know that strings might be 8-bit
https://bugs.webkit.org/show_bug.cgi?id=231937
Reviewed by Yusuke Suzuki.
We somehow forgot to change this to use CharType instead of UChar.
* wtf/text/StringBuffer.h:
(WTF::StringBuffer::resize):
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/text/StringBuffer.h
Diff
Modified: trunk/Source/WTF/ChangeLog (284455 => 284456)
--- trunk/Source/WTF/ChangeLog 2021-10-19 15:38:03 UTC (rev 284455)
+++ trunk/Source/WTF/ChangeLog 2021-10-19 16:00:19 UTC (rev 284456)
@@ -1,3 +1,15 @@
+2021-10-18 Filip Pizlo
+
+StringBuffer should really know that strings might be 8-bit
+https://bugs.webkit.org/show_bug.cgi?id=231937
+
+Reviewed by Yusuke Suzuki.
+
+We somehow forgot to change this to use CharType instead of UChar.
+
+* wtf/text/StringBuffer.h:
+(WTF::StringBuffer::resize):
+
2021-10-19 Cameron McCormack
Ensure CanvasRenderingContext2D.drawImage(video) uses the right color space
Modified: trunk/Source/WTF/wtf/text/StringBuffer.h (284455 => 284456)
--- trunk/Source/WTF/wtf/text/StringBuffer.h 2021-10-19 15:38:03 UTC (rev 284455)
+++ trunk/Source/WTF/wtf/text/StringBuffer.h 2021-10-19 16:00:19 UTC (rev 284456)
@@ -63,11 +63,8 @@
void resize(unsigned newLength)
{
-if (newLength > m_length) {
-if (newLength > std::numeric_limits::max() / sizeof(UChar))
-CRASH();
-m_data = static_cast(StringBufferMalloc::realloc(m_data, newLength * sizeof(UChar)));
-}
+if (newLength > m_length)
+m_data = static_cast(StringBufferMalloc::realloc(m_data, Checked(newLength) * sizeof(CharType)));
m_length = newLength;
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [283371] trunk/Source/bmalloc
Title: [283371] trunk/Source/bmalloc Revision 283371 Author fpi...@apple.com Date 2021-10-01 09:19:16 -0700 (Fri, 01 Oct 2021) Log Message [libpas] Change the names of libpas heap runtime configs to something simpler (intrinsic, primitive, typed, and flex) and add comments describing what they are (update to 32abc1fd5489e01aa1c504ae4654967047d3f072) https://bugs.webkit.org/show_bug.cgi?id=231040 Reviewed by Saam Barati. At some point a long time ago, libpas had sensible names for heap runtime configs: primitive and typed. Then I added the "objc" category, not realizing that I was really adding support for flexible array members. And then I added "intrinsic_primitive", but wow, what a mouthful. This changes the heap names to: intrinsic: singleton heaps for primitive data, like the normal fastMalloc heap primitive: isoheaps for primitive data typed: isoheaps for fixed-size types flex: isoheaps for types with flexible array members Also adds comments explaining the exact behaviors of these heaps. Also exposes isoheaped array allocation through the bmalloc_heap API. That's not yet exposed via the IsoHeap API, but the idea is that it will be -- just need to figure out a clean way to do it. * bmalloc.xcodeproj/project.pbxproj: * bmalloc/bmalloc.cpp: (bmalloc::api::enableMiniMode): * libpas/common.sh: * libpas/src/chaos/Chaos.cpp: (main): * libpas/src/libpas/bmalloc_heap.c: (bmalloc_try_iso_allocate_array): (bmalloc_iso_allocate_array): (bmalloc_try_iso_allocate_array_with_alignment): (bmalloc_iso_allocate_array_with_alignment): * libpas/src/libpas/bmalloc_heap.h: * libpas/src/libpas/bmalloc_heap_config.c: * libpas/src/libpas/bmalloc_heap_inlines.h: (bmalloc_try_reallocate_inline): (bmalloc_reallocate_inline): (bmalloc_try_iso_allocate_array_inline): (bmalloc_try_iso_allocate_array_with_alignment_inline): (bmalloc_iso_allocate_array_inline): (bmalloc_iso_allocate_array_with_alignment_inline): * libpas/src/libpas/hotbit_heap.c: * libpas/src/libpas/hotbit_heap_config.c: * libpas/src/libpas/hotbit_heap_inlines.h: (hotbit_try_reallocate_inline): * libpas/src/libpas/iso_heap.c: (iso_try_allocate_for_flex): (iso_try_allocate_for_objc): Deleted. * libpas/src/libpas/iso_heap.h: * libpas/src/libpas/iso_heap_config.c: * libpas/src/libpas/iso_heap_inlines.h: (iso_try_reallocate_common_primitive_inline): (iso_reallocate_common_primitive_inline): (iso_try_allocate_for_flex_inline): (iso_try_allocate_for_objc_inline): Deleted. * libpas/src/libpas/iso_heap_innards.h: * libpas/src/libpas/iso_test_heap.c: * libpas/src/libpas/iso_test_heap_config.c: * libpas/src/libpas/jit_heap.c: * libpas/src/libpas/minalign32_heap.c: * libpas/src/libpas/minalign32_heap_config.c: * libpas/src/libpas/pagesize64k_heap.c: * libpas/src/libpas/pagesize64k_heap_config.c: * libpas/src/libpas/pas_heap_config_utils.h: * libpas/src/libpas/pas_heap_config_utils_inlines.h: * libpas/src/libpas/pas_internal_config.h: * libpas/src/libpas/pas_large_heap.c: (pas_large_heap_construct): * libpas/src/libpas/pas_try_allocate.h: * libpas/src/libpas/pas_try_allocate_array.h: * libpas/src/libpas/pas_try_allocate_intrinsic.h: Added. (pas_try_allocate_intrinsic_impl_medium_slow_case): (pas_try_allocate_intrinsic_impl_inline_only): * libpas/src/libpas/pas_try_allocate_intrinsic_primitive.h: Removed. * libpas/src/libpas/pas_try_allocate_primitive.h: * libpas/src/libpas/pas_try_reallocate.h: (pas_try_reallocate_intrinsic_allocate_callback): (pas_try_reallocate_intrinsic): (pas_try_reallocate_intrinsic_primitive_allocate_callback): Deleted. (pas_try_reallocate_intrinsic_primitive): Deleted. * libpas/src/libpas/thingy_heap.c: (thingy_try_reallocate_primitive): * libpas/src/libpas/thingy_heap_config.c: * libpas/src/test/IsoHeapChaosTests.cpp: (addIsoHeapChaosTests): * libpas/src/test/TestHarness.cpp: Modified Paths trunk/Source/bmalloc/ChangeLog trunk/Source/bmalloc/bmalloc/bmalloc.cpp trunk/Source/bmalloc/bmalloc.xcodeproj/project.pbxproj trunk/Source/bmalloc/libpas/common.sh trunk/Source/bmalloc/libpas/src/chaos/Chaos.cpp trunk/Source/bmalloc/libpas/src/libpas/bmalloc_heap.c trunk/Source/bmalloc/libpas/src/libpas/bmalloc_heap.h trunk/Source/bmalloc/libpas/src/libpas/bmalloc_heap_config.c trunk/Source/bmalloc/libpas/src/libpas/bmalloc_heap_inlines.h trunk/Source/bmalloc/libpas/src/libpas/hotbit_heap.c trunk/Source/bmalloc/libpas/src/libpas/hotbit_heap_config.c trunk/Source/bmalloc/libpas/src/libpas/hotbit_heap_inlines.h trunk/Source/bmalloc/libpas/src/libpas/iso_heap.c trunk/Source/bmalloc/libpas/src/libpas/iso_heap.h trunk/Source/bmalloc/libpas/src/libpas/iso_heap_config.c trunk/Source/bmalloc/libpas/src/libpas/iso_heap_inlines.h trunk/Source/bmalloc/libpas/src/libpas/iso_heap_innards.h trunk/Source/bmalloc/libpas/src/libpas/iso_test_heap.c trunk/Source/bmalloc/libpas/src/libpas/iso_test_heap_config.c trunk/Source/bmalloc/libpas/src/libpas/jit_heap.c trunk/Source/bmalloc/libpas/src/libpas/minalign32_heap.c trunk/Source/bmalloc/libpas/src/libpas/minalign32_h
[webkit-changes] [283178] trunk/Source/bmalloc
Title: [283178] trunk/Source/bmalloc Revision 283178 Author fpi...@apple.com Date 2021-09-28 09:59:52 -0700 (Tue, 28 Sep 2021) Log Message [libpas] Fix coalescing of the large sharing pool and make it easy to introspect it (update to e4d20851ee9ff00f2962b349a9ff8465695a83d7) https://bugs.webkit.org/show_bug.cgi?id=230867 Reviewed by Yusuke Suzuki. This adds the ability to enable the libpas status reporter, adds a large sharing pool dump to the status report, and fixes a large sharing pool coalescing bug found by doing that. Previously we weren't coalescing things that are not free+committed. Also updates the export script that I use to keep the libpas git repo in sync with what's in WK. The large sharing pool is the mechanism by which libpas can find memory that can be decommitted across isolated large heaps, even if those large heaps share pages with one another. The main data structure is a red-black tree of nodes that represent memory ranges. If there are two adjacent ranges of memory that are both fully live and committed or both decommitted, then we want those to be represented using a single node. That wasn't quite working right. Even the libpas test for this was testing the wrong thing. This fixes the behavior and the test. It's perf-neutral since large heaps usually have a small number of objects in them anyway. The new status reporting functionality can be enabled with the WebKitPasStatusReporter environment variable. This takes an integer that tells the amount of data in the report. Here are the recognized values: 1 - just report number of heaps 2 - something in between 1 and 3 3 - report everything that the status reporter can report right now (per-page data for segregated/bitfit heaps, lots of details for large heaps) If the status reporter ever reported per-object information, it would be at level 4 or higher. It's safe to pass or whatever if you just want the maximum report that libpas supports. TL;DR for now you usually want WebKitPasStatusReporter=3. * bmalloc/Environment.cpp: (bmalloc::Environment::Environment): * libpas/export.rb: Added. * libpas/export.sh: Removed. * libpas/src/libpas/pas_bitfit_directory.c: (pas_bitfit_directory_construct): I needed to rationalize how we initialize disabled directories to make status reporting work. (pas_bitfit_directory_get_first_free_view): * libpas/src/libpas/pas_large_sharing_pool.c: (states_match): * libpas/src/libpas/pas_status_reporter.c: (pas_status_reporter_dump_bitfit_directory): (dump_large_sharing_pool_node_callback): (pas_status_reporter_dump_large_sharing_pool): (pas_status_reporter_dump_everything): * libpas/src/libpas/pas_status_reporter.h: * libpas/src/test/LargeSharingPoolDump.cpp: * libpas/src/test/LargeSharingPoolDump.h: * libpas/src/test/LargeSharingPoolTests.cpp: (std::Range::Range): (std::Range::operator== const): (std::Range::operator!= const): (std::operator<<): (std::assertState): (std::testGoodCoalesceEpochUpdate): (addLargeSharingPoolTests): (std::testBadCoalesceEpochUpdate): Deleted. Modified Paths trunk/Source/bmalloc/ChangeLog trunk/Source/bmalloc/bmalloc/Environment.cpp trunk/Source/bmalloc/libpas/src/libpas/pas_bitfit_directory.c trunk/Source/bmalloc/libpas/src/libpas/pas_large_sharing_pool.c trunk/Source/bmalloc/libpas/src/libpas/pas_status_reporter.c trunk/Source/bmalloc/libpas/src/libpas/pas_status_reporter.h trunk/Source/bmalloc/libpas/src/test/LargeSharingPoolDump.cpp trunk/Source/bmalloc/libpas/src/test/LargeSharingPoolDump.h trunk/Source/bmalloc/libpas/src/test/LargeSharingPoolTests.cpp Added Paths trunk/Source/bmalloc/libpas/export.rb Removed Paths trunk/Source/bmalloc/libpas/export.sh Diff Modified: trunk/Source/bmalloc/ChangeLog (283177 => 283178) --- trunk/Source/bmalloc/ChangeLog 2021-09-28 16:55:51 UTC (rev 283177) +++ trunk/Source/bmalloc/ChangeLog 2021-09-28 16:59:52 UTC (rev 283178) @@ -1,3 +1,64 @@ +2021-09-27 Filip Pizlo + +[libpas] Fix coalescing of the large sharing pool and make it easy to introspect it (update to e4d20851ee9ff00f2962b349a9ff8465695a83d7) +https://bugs.webkit.org/show_bug.cgi?id=230867 + +Reviewed by Yusuke Suzuki. + +This adds the ability to enable the libpas status reporter, adds a large sharing pool dump to +the status report, and fixes a large sharing pool coalescing bug found by doing that. Previously +we weren't coalescing things that are not free+committed. + +Also updates the export script that I use to keep the libpas git repo in sync with what's in WK. + +The large sharing pool is the mechanism by which libpas can find memory that can be decommitted +across isolated large heaps, even if those large heaps share pages with one another. The main +data structure is a red-black tree of nodes that represent memory ranges. If there are two +adjacent ranges of memory that are both fully live and committed or both decommitted, then we +want thos
[webkit-changes] [282899] trunk/Source/bmalloc
Title: [282899] trunk/Source/bmalloc Revision 282899 Author fpi...@apple.com Date 2021-09-22 17:52:25 -0700 (Wed, 22 Sep 2021) Log Message [libpas] fix DebugHeap https://bugs.webkit.org/show_bug.cgi?id=230658 Reviewed by Yusuke Suzuki. The previous DebugHeap integration with libpas assumed we didn't have a jit_heap. Now that we have a jit_heap, we need to be able to do DebugHeap from the bmalloc_heap while we still use jit_heap. This was tricky, since previously, libpas could just follow bmalloc and say that if TLC is not initialized, then we go slow, and the slow path checks for DebugHeap. Now, we might have a TLC. This means having to push down the debug heap checks into other slow paths. * bmalloc/DebugHeap.cpp: (pas_debug_heap_is_enabled): (pas_debug_heap_malloc): (pas_debug_heap_memalign): (pas_debug_heap_realloc): (pas_debug_heap_free): * libpas/src/libpas/bmalloc_heap_config.c: (bmalloc_heap_config_activate): * libpas/src/libpas/jit_heap.c: (jit_heap_add_fresh_memory): (jit_heap_try_allocate): * libpas/src/libpas/jit_heap_config.c: * libpas/src/libpas/pas_deallocate.c: (pas_try_deallocate_slow_no_cache): * libpas/src/libpas/pas_deallocate.h: (pas_try_deallocate_not_small): * libpas/src/libpas/pas_debug_heap.h: (pas_debug_heap_is_enabled): (pas_debug_heap_allocate): * libpas/src/libpas/pas_local_allocator_inlines.h: (pas_local_allocator_try_allocate_small_segregated_slow_impl): (pas_local_allocator_try_allocate_slow_impl): (pas_local_allocator_try_allocate): * libpas/src/libpas/pas_thread_local_cache.c: (allocate_cache): (pas_thread_local_cache_get_local_allocator_if_can_set_cache_slow): * libpas/src/libpas/pas_try_allocate.h: (pas_try_allocate_impl): * libpas/src/libpas/pas_try_allocate_common.h: (pas_try_allocate_common_impl_slow): * libpas/src/libpas/pas_try_allocate_intrinsic_primitive.h: (pas_try_allocate_intrinsic_primitive_impl_medium_slow_case): (pas_try_allocate_intrinsic_primitive_impl_inline_only): * libpas/src/libpas/pas_try_reallocate.h: (pas_try_reallocate): Modified Paths trunk/Source/bmalloc/ChangeLog trunk/Source/bmalloc/bmalloc/DebugHeap.cpp trunk/Source/bmalloc/libpas/src/libpas/bmalloc_heap_config.c trunk/Source/bmalloc/libpas/src/libpas/jit_heap.c trunk/Source/bmalloc/libpas/src/libpas/jit_heap_config.c trunk/Source/bmalloc/libpas/src/libpas/pas_deallocate.c trunk/Source/bmalloc/libpas/src/libpas/pas_deallocate.h trunk/Source/bmalloc/libpas/src/libpas/pas_debug_heap.h trunk/Source/bmalloc/libpas/src/libpas/pas_local_allocator_inlines.h trunk/Source/bmalloc/libpas/src/libpas/pas_thread_local_cache.c trunk/Source/bmalloc/libpas/src/libpas/pas_try_allocate.h trunk/Source/bmalloc/libpas/src/libpas/pas_try_allocate_common.h trunk/Source/bmalloc/libpas/src/libpas/pas_try_allocate_intrinsic_primitive.h trunk/Source/bmalloc/libpas/src/libpas/pas_try_reallocate.h Diff Modified: trunk/Source/bmalloc/ChangeLog (282898 => 282899) --- trunk/Source/bmalloc/ChangeLog 2021-09-23 00:40:13 UTC (rev 282898) +++ trunk/Source/bmalloc/ChangeLog 2021-09-23 00:52:25 UTC (rev 282899) @@ -1,3 +1,54 @@ +2021-09-22 Filip Pizlo + +[libpas] fix DebugHeap +https://bugs.webkit.org/show_bug.cgi?id=230658 + +Reviewed by Yusuke Suzuki. + +The previous DebugHeap integration with libpas assumed we didn't have a jit_heap. Now that +we have a jit_heap, we need to be able to do DebugHeap from the bmalloc_heap while we still +use jit_heap. + +This was tricky, since previously, libpas could just follow bmalloc and say that if TLC is +not initialized, then we go slow, and the slow path checks for DebugHeap. Now, we might have +a TLC. This means having to push down the debug heap checks into other slow paths. + +* bmalloc/DebugHeap.cpp: +(pas_debug_heap_is_enabled): +(pas_debug_heap_malloc): +(pas_debug_heap_memalign): +(pas_debug_heap_realloc): +(pas_debug_heap_free): +* libpas/src/libpas/bmalloc_heap_config.c: +(bmalloc_heap_config_activate): +* libpas/src/libpas/jit_heap.c: +(jit_heap_add_fresh_memory): +(jit_heap_try_allocate): +* libpas/src/libpas/jit_heap_config.c: +* libpas/src/libpas/pas_deallocate.c: +(pas_try_deallocate_slow_no_cache): +* libpas/src/libpas/pas_deallocate.h: +(pas_try_deallocate_not_small): +* libpas/src/libpas/pas_debug_heap.h: +(pas_debug_heap_is_enabled): +(pas_debug_heap_allocate): +* libpas/src/libpas/pas_local_allocator_inlines.h: +(pas_local_allocator_try_allocate_small_segregated_slow_impl): +(pas_local_allocator_try_allocate_slow_impl): +(pas_local_allocator_try_allocate): +* libpas/src/libpas/pas_thread_local_cache.c: +(allocate_cache): +(pas_thread_local_cache_get_local_allocator_if_can_set_cache_slow): +* libpas/src/libpas/pas_try_allocate.h: +(pas_try_allocate_impl): +
[webkit-changes] [282561] trunk/Source/bmalloc
Title: [282561] trunk/Source/bmalloc
Revision 282561
Author fpi...@apple.com
Date 2021-09-16 11:07:01 -0700 (Thu, 16 Sep 2021)
Log Message
Stub out the footprint() API when libpas is in use
https://bugs.webkit.org/show_bug.cgi?id=230362
Reviewed by Yusuke Suzuki.
The Gigacage's footprint API is called from some test-only code in JSC, evidently to no
meaningful effect. It's possible for libpas to support such an API but it currently
doesn't. So, stub it out. To my knowledge we don't actually use this API for anything
other than tests, and even tests seem to use it only in the sense that they expect to be
able to call it without crashing.
* bmalloc/Gigacage.cpp:
(Gigacage::footprint):
Modified Paths
trunk/Source/bmalloc/ChangeLog
trunk/Source/bmalloc/bmalloc/Gigacage.cpp
Diff
Modified: trunk/Source/bmalloc/ChangeLog (282560 => 282561)
--- trunk/Source/bmalloc/ChangeLog 2021-09-16 17:32:46 UTC (rev 282560)
+++ trunk/Source/bmalloc/ChangeLog 2021-09-16 18:07:01 UTC (rev 282561)
@@ -1,3 +1,19 @@
+2021-09-16 Filip Pizlo
+
+Stub out the footprint() API when libpas is in use
+https://bugs.webkit.org/show_bug.cgi?id=230362
+
+Reviewed by Yusuke Suzuki.
+
+The Gigacage's footprint API is called from some test-only code in JSC, evidently to no
+meaningful effect. It's possible for libpas to support such an API but it currently
+doesn't. So, stub it out. To my knowledge we don't actually use this API for anything
+other than tests, and even tests seem to use it only in the sense that they expect to be
+able to call it without crashing.
+
+* bmalloc/Gigacage.cpp:
+(Gigacage::footprint):
+
2021-09-09 Filip Pizlo
[libpas] Update to 38b9b0b92ccc9628627c742523de6200acc08211 and fully enable on AS
Modified: trunk/Source/bmalloc/bmalloc/Gigacage.cpp (282560 => 282561)
--- trunk/Source/bmalloc/bmalloc/Gigacage.cpp 2021-09-16 17:32:46 UTC (rev 282560)
+++ trunk/Source/bmalloc/bmalloc/Gigacage.cpp 2021-09-16 18:07:01 UTC (rev 282561)
@@ -323,7 +323,12 @@
size_t footprint(Kind kind)
{
+#if BUSE(LIBPAS)
+BUNUSED(kind);
+return 0;
+#else
return PerProcess>::get()->at(heapKind(kind)).footprint();
+#endif
}
} // namespace Gigacage
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [280668] trunk/Source/bmalloc
Title: [280668] trunk/Source/bmalloc
Revision 280668
Author fpi...@apple.com
Date 2021-08-04 15:53:54 -0700 (Wed, 04 Aug 2021)
Log Message
[libpas] medium size class lookup needs to correctly fence the counting lock read path
https://bugs.webkit.org/show_bug.cgi?id=228799
Reviewed by Tadeu Zagallo.
The medium size class lookup does a binary search on a data structure that may mutate; we
catch that using a counting lock. But the algorithm wasn't fencing the tail end; it's supposed
to reread the count at the end but that read was not fenced.
This adds the fencing using pas_depend. I confirmed that the disassembly does the right thing.
It adds very little code.
Also rebased a test. Libpas tests are very specific about memory usage in some cases, and so
sometimes you will encounter a test run that requires limits to be adjusted. This happens
because some tests can sometimes create very complex heap layouts that really do use more
memory than we asserted, but the assertion had always worked because the test never ran with
the "wrong" kind of layout. This fixes a one-off test failure I saw when debugging this fix.
* libpas/src/libpas/pas_mutation_count.h:
(pas_mutation_count_matches_with_dependency):
(pas_mutation_count_matches): Deleted.
* libpas/src/libpas/pas_segregated_heap.c:
(medium_directory_tuple_for_index_impl):
(medium_directory_tuple_for_index_with_lock):
(pas_segregated_heap_medium_directory_tuple_for_index):
* libpas/src/test/ThingyAndUtilityHeapAllocationTests.cpp:
(std::addLargeHeapTests):
Modified Paths
trunk/Source/bmalloc/ChangeLog
trunk/Source/bmalloc/libpas/src/libpas/pas_mutation_count.h
trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_heap.c
trunk/Source/bmalloc/libpas/src/test/ThingyAndUtilityHeapAllocationTests.cpp
Diff
Modified: trunk/Source/bmalloc/ChangeLog (280667 => 280668)
--- trunk/Source/bmalloc/ChangeLog 2021-08-04 22:24:44 UTC (rev 280667)
+++ trunk/Source/bmalloc/ChangeLog 2021-08-04 22:53:54 UTC (rev 280668)
@@ -1,3 +1,33 @@
+2021-08-04 Filip Pizlo
+
+[libpas] medium size class lookup needs to correctly fence the counting lock read path
+https://bugs.webkit.org/show_bug.cgi?id=228799
+
+Reviewed by Tadeu Zagallo.
+
+The medium size class lookup does a binary search on a data structure that may mutate; we
+catch that using a counting lock. But the algorithm wasn't fencing the tail end; it's supposed
+to reread the count at the end but that read was not fenced.
+
+This adds the fencing using pas_depend. I confirmed that the disassembly does the right thing.
+It adds very little code.
+
+Also rebased a test. Libpas tests are very specific about memory usage in some cases, and so
+sometimes you will encounter a test run that requires limits to be adjusted. This happens
+because some tests can sometimes create very complex heap layouts that really do use more
+memory than we asserted, but the assertion had always worked because the test never ran with
+the "wrong" kind of layout. This fixes a one-off test failure I saw when debugging this fix.
+
+* libpas/src/libpas/pas_mutation_count.h:
+(pas_mutation_count_matches_with_dependency):
+(pas_mutation_count_matches): Deleted.
+* libpas/src/libpas/pas_segregated_heap.c:
+(medium_directory_tuple_for_index_impl):
+(medium_directory_tuple_for_index_with_lock):
+(pas_segregated_heap_medium_directory_tuple_for_index):
+* libpas/src/test/ThingyAndUtilityHeapAllocationTests.cpp:
+(std::addLargeHeapTests):
+
2021-08-03 Filip Pizlo
pas_segmented_vector's iterate functions should handle memory ordering correctly
Modified: trunk/Source/bmalloc/libpas/src/libpas/pas_mutation_count.h (280667 => 280668)
--- trunk/Source/bmalloc/libpas/src/libpas/pas_mutation_count.h 2021-08-04 22:24:44 UTC (rev 280667)
+++ trunk/Source/bmalloc/libpas/src/libpas/pas_mutation_count.h 2021-08-04 22:53:54 UTC (rev 280668)
@@ -66,11 +66,12 @@
return saved_mutation_count.count & PAS_MUTATION_COUNT_MUTATING_BIT;
}
-static inline bool pas_mutation_count_matches(pas_mutation_count* mutation_count,
- pas_mutation_count saved_mutation_count)
+static inline bool pas_mutation_count_matches_with_dependency(pas_mutation_count* mutation_count,
+ pas_mutation_count saved_mutation_count,
+ uintptr_t dependency)
{
pas_compiler_fence();
-return mutation_count->count == saved_mutation_count.count;
+return mutation_count[pas_depend(dependency)].count == saved_mutation_count.count;
}
static inline unsigned pas_mutation_count_depend(pas_mutation_count saved_mutation_count)
Modified: trunk/Source/bmalloc/libpas/src/libpas/pas_segregated_heap.c (280667 => 280668)
--- trunk/Sourc
[webkit-changes] [280605] trunk/Source/bmalloc
Title: [280605] trunk/Source/bmalloc
Revision 280605
Author fpi...@apple.com
Date 2021-08-03 12:15:21 -0700 (Tue, 03 Aug 2021)
Log Message
pas_segmented_vector's iterate functions should handle memory ordering correctly
https://bugs.webkit.org/show_bug.cgi?id=228746
Reviewed by Mark Lam.
Also fixed a missing store-store fence in bitfit_directory's use of a segmented vector.
* libpas/src/libpas/pas_bitfit_directory.c:
(pas_bitfit_directory_get_first_free_view):
* libpas/src/libpas/pas_segmented_vector.h:
Modified Paths
trunk/Source/bmalloc/ChangeLog
trunk/Source/bmalloc/libpas/src/libpas/pas_bitfit_directory.c
trunk/Source/bmalloc/libpas/src/libpas/pas_segmented_vector.h
Diff
Modified: trunk/Source/bmalloc/ChangeLog (280604 => 280605)
--- trunk/Source/bmalloc/ChangeLog 2021-08-03 19:00:33 UTC (rev 280604)
+++ trunk/Source/bmalloc/ChangeLog 2021-08-03 19:15:21 UTC (rev 280605)
@@ -1,3 +1,16 @@
+2021-08-03 Filip Pizlo
+
+pas_segmented_vector's iterate functions should handle memory ordering correctly
+https://bugs.webkit.org/show_bug.cgi?id=228746
+
+Reviewed by Mark Lam.
+
+Also fixed a missing store-store fence in bitfit_directory's use of a segmented vector.
+
+* libpas/src/libpas/pas_bitfit_directory.c:
+(pas_bitfit_directory_get_first_free_view):
+* libpas/src/libpas/pas_segmented_vector.h:
+
2021-07-14 Michael Saboff
[BMalloc] Lazily allocate physical pages
Modified: trunk/Source/bmalloc/libpas/src/libpas/pas_bitfit_directory.c (280604 => 280605)
--- trunk/Source/bmalloc/libpas/src/libpas/pas_bitfit_directory.c 2021-08-03 19:00:33 UTC (rev 280604)
+++ trunk/Source/bmalloc/libpas/src/libpas/pas_bitfit_directory.c 2021-08-03 19:15:21 UTC (rev 280605)
@@ -220,6 +220,7 @@
PAS_ASSERT((unsigned)found_index.index == found_index.index);
view = pas_bitfit_view_create(global_directory,
(unsigned)found_index.index);
+pas_store_store_fence();
pas_compact_atomic_bitfit_view_ptr_store(
pas_bitfit_directory_get_view_ptr(directory, found_index.index), view);
}
Modified: trunk/Source/bmalloc/libpas/src/libpas/pas_segmented_vector.h (280604 => 280605)
--- trunk/Source/bmalloc/libpas/src/libpas/pas_segmented_vector.h 2021-08-03 19:00:33 UTC (rev 280604)
+++ trunk/Source/bmalloc/libpas/src/libpas/pas_segmented_vector.h 2021-08-03 19:15:21 UTC (rev 280605)
@@ -163,7 +163,7 @@
segment_index = start_index % (segment_size); \
\
size = vector->size; \
-spine = name##_spine_ptr_load(&vector->spine); \
+spine = name##_spine_ptr_load(&vector[pas_depend(size)].spine); \
\
for (; spine_index * segment_size < size; spine_index++) { \
type* segment; \
@@ -255,7 +255,7 @@
spine_index = start_index / (segment_size); \
segment_index = start_index % (segment_size); \
\
-spine = name##_spine_ptr_load(&vector->spine); \
+spine = name##_spine_ptr_load(&vector[pas_depend(size)].spine); \
\
spine_index++; \
\
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [278942] trunk/Source/JavaScriptCore
Title: [278942] trunk/Source/_javascript_Core
Revision 278942
Author fpi...@apple.com
Date 2021-06-16 11:08:37 -0700 (Wed, 16 Jun 2021)
Log Message
RegisterSet should be smaller
https://bugs.webkit.org/show_bug.cgi?id=227078
Reviewed by Geoff Garen.
Previously, every RegisterSet would have an extra 64-bit word in it just to hold state
relevant to hashtable keys.
But RegisterSet is almost never used as a hashtable key.
This patch moves the hashtable key support into a subclass, HashableRegisterSet. That class
ends up only being used in one place.
On ARM64, this makes RegisterSet use 64 bits instead of 128 bits.
On X86_64, this makes RegisterSet use 32 bits instead of 64 bits.
* _javascript_Core.xcodeproj/project.pbxproj:
* ftl/FTLSlowPathCallKey.h:
(JSC::FTL::SlowPathCallKey::SlowPathCallKey):
* jit/HashableRegisterSet.h: Added.
(JSC::HashableRegisterSet::HashableRegisterSet):
(JSC::HashableRegisterSet::isEmptyValue const):
(JSC::HashableRegisterSet::isDeletedValue const):
(JSC::RegisterSetHash::hash):
(JSC::RegisterSetHash::equal):
* jit/RegisterSet.h:
(): Deleted.
(JSC::RegisterSet::isEmptyValue const): Deleted.
(JSC::RegisterSet::isDeletedValue const): Deleted.
(JSC::RegisterSetHash::hash): Deleted.
(JSC::RegisterSetHash::equal): Deleted.
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj
trunk/Source/_javascript_Core/ftl/FTLSlowPathCallKey.h
trunk/Source/_javascript_Core/jit/RegisterSet.h
Added Paths
trunk/Source/_javascript_Core/jit/HashableRegisterSet.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (278941 => 278942)
--- trunk/Source/_javascript_Core/ChangeLog 2021-06-16 18:00:28 UTC (rev 278941)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-06-16 18:08:37 UTC (rev 278942)
@@ -1,3 +1,38 @@
+2021-06-16 Filip Pizlo
+
+RegisterSet should be smaller
+https://bugs.webkit.org/show_bug.cgi?id=227078
+
+Reviewed by Geoff Garen.
+
+Previously, every RegisterSet would have an extra 64-bit word in it just to hold state
+relevant to hashtable keys.
+
+But RegisterSet is almost never used as a hashtable key.
+
+This patch moves the hashtable key support into a subclass, HashableRegisterSet. That class
+ends up only being used in one place.
+
+On ARM64, this makes RegisterSet use 64 bits instead of 128 bits.
+
+On X86_64, this makes RegisterSet use 32 bits instead of 64 bits.
+
+* _javascript_Core.xcodeproj/project.pbxproj:
+* ftl/FTLSlowPathCallKey.h:
+(JSC::FTL::SlowPathCallKey::SlowPathCallKey):
+* jit/HashableRegisterSet.h: Added.
+(JSC::HashableRegisterSet::HashableRegisterSet):
+(JSC::HashableRegisterSet::isEmptyValue const):
+(JSC::HashableRegisterSet::isDeletedValue const):
+(JSC::RegisterSetHash::hash):
+(JSC::RegisterSetHash::equal):
+* jit/RegisterSet.h:
+(): Deleted.
+(JSC::RegisterSet::isEmptyValue const): Deleted.
+(JSC::RegisterSet::isDeletedValue const): Deleted.
+(JSC::RegisterSetHash::hash): Deleted.
+(JSC::RegisterSetHash::equal): Deleted.
+
2021-06-16 Tadeu Zagallo
AssemblyHelpers should save/restore callee save FPRs
Modified: trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj (278941 => 278942)
--- trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj 2021-06-16 18:00:28 UTC (rev 278941)
+++ trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj 2021-06-16 18:08:37 UTC (rev 278942)
@@ -518,6 +518,7 @@
0FB4FB751BC843140025CA5A /* FTLLazySlowPathCall.h in Headers */ = {isa = PBXBuildFile; fileRef = 0FB4FB721BC843140025CA5A /* FTLLazySlowPathCall.h */; };
0FB5467714F59B5C002C2989 /* LazyOperandValueProfile.h in Headers */ = {isa = PBXBuildFile; fileRef = 0FB5467614F59AD1002C2989 /* LazyOperandValueProfile.h */; settings = {ATTRIBUTES = (Private, ); }; };
0FB5467B14F5C7E1002C2989 /* MethodOfGettingAValueProfile.h in Headers */ = {isa = PBXBuildFile; fileRef = 0FB5467A14F5C7D4002C2989 /* MethodOfGettingAValueProfile.h */; settings = {ATTRIBUTES = (Private, ); }; };
+ 0FB57069267A642E0080FA8B /* HashableRegisterSet.h in Headers */ = {isa = PBXBuildFile; fileRef = 0FB57068267A642E0080FA8B /* HashableRegisterSet.h */; };
0FB7F39515ED8E4600F167B2 /* ArrayConventions.h in Headers */ = {isa = PBXBuildFile; fileRef = 0FB7F38915ED8E3800F167B2 /* ArrayConventions.h */; settings = {ATTRIBUTES = (Private, ); }; };
0FB7F39615ED8E4600F167B2 /* ArrayStorage.h in Headers */ = {isa = PBXBuildFile; fileRef = 0FB7F38A15ED8E3800F167B2 /* ArrayStorage.h */; settings = {ATTRIBUTES = (Private, ); }; };
0FB7F39715ED8E4600F167B2 /* Butterfly.h in Headers */ = {isa = PBXBuildFile; fileRef = 0FB7F38B15ED8E3800F167B2 /* Butterfly.h */; settings = {ATTRIBUTES = (Private, ); }; };
@@ -2957,6 +2958,7 @@
0FB5467814F5C4
[webkit-changes] [278476] trunk/Source/JavaScriptCore
Title: [278476] trunk/Source/_javascript_Core
Revision 278476
Author fpi...@apple.com
Date 2021-06-04 11:14:46 -0700 (Fri, 04 Jun 2021)
Log Message
Don't emit the NotDouble checks if we're already NotDouble.
Rubber stamped by Saam Barati.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculateNotDouble):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::speculateNotDouble):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (278475 => 278476)
--- trunk/Source/_javascript_Core/ChangeLog 2021-06-04 18:02:04 UTC (rev 278475)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-06-04 18:14:46 UTC (rev 278476)
@@ -1,3 +1,14 @@
+2021-06-04 Filip Pizlo
+
+Don't emit the NotDouble checks if we're already NotDouble.
+
+Rubber stamped by Saam Barati.
+
+* dfg/DFGSpeculativeJIT.cpp:
+(JSC::DFG::SpeculativeJIT::speculateNotDouble):
+* ftl/FTLLowerDFGToB3.cpp:
+(JSC::FTL::DFG::LowerDFGToB3::speculateNotDouble):
+
2021-06-04 Mark Lam
Placate exception checker validation in objectPrototypeHasOwnProperty.
Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp (278475 => 278476)
--- trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp 2021-06-04 18:02:04 UTC (rev 278475)
+++ trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp 2021-06-04 18:14:46 UTC (rev 278476)
@@ -11434,6 +11434,9 @@
void SpeculativeJIT::speculateNotDouble(Edge edge)
{
+if (!needsTypeCheck(edge, ~SpecFullDouble))
+return;
+
JSValueOperand operand(this, edge, ManualOperandSpeculation);
GPRTemporary temp(this);
JSValueRegs regs = operand.jsValueRegs();
Modified: trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp (278475 => 278476)
--- trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp 2021-06-04 18:02:04 UTC (rev 278475)
+++ trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp 2021-06-04 18:14:46 UTC (rev 278476)
@@ -18453,6 +18453,9 @@
void speculateNotDouble(Edge edge)
{
+if (!m_interpreter.needsTypeCheck(edge))
+return;
+
LValue value = lowJSValue(edge, ManualOperandSpeculation);
LBasicBlock isNotInt32 = m_out.newBlock();
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [278465] trunk
Title: [278465] trunk
Revision 278465
Author fpi...@apple.com
Date 2021-06-04 09:32:57 -0700 (Fri, 04 Jun 2021)
Log Message
DFG should speculate on CompareStrictEq(@x, @x)
https://bugs.webkit.org/show_bug.cgi?id=226621
Reviewed by Mark Lam.
JSTests:
* microbenchmarks/untyped-stricteq-self.js: Added.
(foo):
* stress/untyped-stricteq-self-fail.js: Added.
(bar):
(foo):
Source/_javascript_Core:
Introduces a NotDouble: speculation. We use it to speculate on CompareStrictEq(@x, @x).
* bytecode/SpeculatedType.h:
(JSC::isNotDoubleSpeculation):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue):
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateNotDouble):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculateNotDouble):
(JSC::DFG::SpeculativeJIT::speculate):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
(JSC::DFG::checkMayCrashIfInputIsEmpty):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::speculate):
(JSC::FTL::DFG::LowerDFGToB3::speculateNotDouble):
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/SpeculatedType.h
trunk/Source/_javascript_Core/dfg/DFGFixupPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGNode.h
trunk/Source/_javascript_Core/dfg/DFGSafeToExecute.h
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.h
trunk/Source/_javascript_Core/dfg/DFGUseKind.cpp
trunk/Source/_javascript_Core/dfg/DFGUseKind.h
trunk/Source/_javascript_Core/ftl/FTLCapabilities.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
Added Paths
trunk/JSTests/microbenchmarks/untyped-stricteq-self.js
trunk/JSTests/stress/untyped-stricteq-self-fail.js
Diff
Modified: trunk/JSTests/ChangeLog (278464 => 278465)
--- trunk/JSTests/ChangeLog 2021-06-04 16:08:45 UTC (rev 278464)
+++ trunk/JSTests/ChangeLog 2021-06-04 16:32:57 UTC (rev 278465)
@@ -1,3 +1,16 @@
+2021-06-03 Filip Pizlo
+
+DFG should speculate on CompareStrictEq(@x, @x)
+https://bugs.webkit.org/show_bug.cgi?id=226621
+
+Reviewed by Mark Lam.
+
+* microbenchmarks/untyped-stricteq-self.js: Added.
+(foo):
+* stress/untyped-stricteq-self-fail.js: Added.
+(bar):
+(foo):
+
2021-06-04 Keith Miller
Fix tests that fail under executable allocation fuzzing
Added: trunk/JSTests/microbenchmarks/untyped-stricteq-self.js (0 => 278465)
--- trunk/JSTests/microbenchmarks/untyped-stricteq-self.js (rev 0)
+++ trunk/JSTests/microbenchmarks/untyped-stricteq-self.js 2021-06-04 16:32:57 UTC (rev 278465)
@@ -0,0 +1,17 @@
+function foo(x) {
+var y;
+if (x===x)
+y = 42;
+else
+y = bar();
+return y + 1;
+}
+
+var result = 0;
+var array = ["foo", 42, true, null, {}, [], foo];
+for (var i = 0; i < 1000; ++i)
+result += foo(array[i % array.length]);
+
+if (result != (42 + 1) * 1000)
+throw "Error";
+
Added: trunk/JSTests/stress/untyped-stricteq-self-fail.js (0 => 278465)
--- trunk/JSTests/stress/untyped-stricteq-self-fail.js (rev 0)
+++ trunk/JSTests/stress/untyped-stricteq-self-fail.js 2021-06-04 16:32:57 UTC (rev 278465)
@@ -0,0 +1,24 @@
+function bar() { return 10; }
+
+function foo(x) {
+var y;
+if (x===x)
+y = 42;
+else
+y = bar();
+return y + 1;
+}
+
+noInline(foo);
+
+var result = 0;
+var array = ["foo", 42, true, null, {}, [], foo];
+for (var i = 0; i < 100; ++i)
+result += foo(array[i % array.length]);
+
+if (result != (42 + 1) * 100)
+throw "Error";
+
+var resultAtEnd = foo(0.0 / 0.0);
+if (resultAtEnd != 11)
+throw "Error at end";
Modified: trunk/Source/_javascript_Core/ChangeLog (278464 => 278465)
--- trunk/Source/_javascript_Core/ChangeLog 2021-06-04 16:08:45 UTC (rev 278464)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-06-04 16:32:57 UTC (rev 278465)
@@ -1,3 +1,35 @@
+2021-06-03 Filip Pizlo
+
+DFG should speculate on CompareStrictEq(@x, @x)
+https://bugs.webkit.org/show_bug.cgi?id=226621
+
+Reviewed by Mark Lam.
+
+Introduces a NotDouble: speculation. We use it to speculate on CompareStrictEq(@x, @x).
+
+* bytecode/SpeculatedType.h:
+(JSC::isNotDoubleSpeculation):
+* dfg/DFGFixupPhase.cpp:
+(JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue):
+* dfg/DFGNode.h:
+(JSC::DFG::Node::shouldSpeculateNotDouble):
+* dfg/DFGSafeToExecute.h:
+(JSC::DFG::SafeToExecuteEdge::operator()):
+* dfg/DFGSpeculativeJIT.cpp:
+(JSC::DFG::SpeculativeJIT::speculateNotDouble):
+(JSC::DFG::SpeculativeJIT::speculate):
+* dfg/DFGSpeculativeJIT.h:
+* dfg/DFG
[webkit-changes] [278424] trunk/Source/JavaScriptCore
Title: [278424] trunk/Source/_javascript_Core
Revision 278424
Author fpi...@apple.com
Date 2021-06-03 15:27:32 -0700 (Thu, 03 Jun 2021)
Log Message
DFG should eliminate obvious store barriers
https://bugs.webkit.org/show_bug.cgi?id=226604
Reviewed by Mark Lam.
This has a couple changes:
- PutByOffset doesn't GC! So let's not say that it does.
- The store barrier clustering phase is no longer called the store barrier fencing phase in
dumps.
Small Speedometer2 speed-up. Definite speed-up for Elm.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGStoreBarrierClusteringPhase.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGDoesGC.cpp
trunk/Source/_javascript_Core/dfg/DFGStoreBarrierClusteringPhase.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (278423 => 278424)
--- trunk/Source/_javascript_Core/ChangeLog 2021-06-03 22:27:13 UTC (rev 278423)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-06-03 22:27:32 UTC (rev 278424)
@@ -1,3 +1,23 @@
+2021-06-03 Filip Pizlo
+
+DFG should eliminate obvious store barriers
+https://bugs.webkit.org/show_bug.cgi?id=226604
+
+Reviewed by Mark Lam.
+
+This has a couple changes:
+
+- PutByOffset doesn't GC! So let's not say that it does.
+
+- The store barrier clustering phase is no longer called the store barrier fencing phase in
+ dumps.
+
+Small Speedometer2 speed-up. Definite speed-up for Elm.
+
+* dfg/DFGDoesGC.cpp:
+(JSC::DFG::doesGC):
+* dfg/DFGStoreBarrierClusteringPhase.cpp:
+
2021-06-03 Patrick Angle
Web Inspector: [Cocoa] `RemoteInspector` won't connect to a new relay if it hasn't yet failed to communicate with a previously connected relay
Modified: trunk/Source/_javascript_Core/dfg/DFGDoesGC.cpp (278423 => 278424)
--- trunk/Source/_javascript_Core/dfg/DFGDoesGC.cpp 2021-06-03 22:27:13 UTC (rev 278423)
+++ trunk/Source/_javascript_Core/dfg/DFGDoesGC.cpp 2021-06-03 22:27:32 UTC (rev 278424)
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2014-2020 Apple Inc. All rights reserved.
+ * Copyright (C) 2014-2021 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -258,6 +258,7 @@
case DataViewGetInt:
case DataViewGetFloat:
case DataViewSet:
+case PutByOffset:
return false;
#if ASSERT_ENABLED
@@ -320,7 +321,6 @@
case PutByIdDirect:
case PutByIdFlush:
case PutByIdWithThis:
-case PutByOffset:
case PutByValWithThis:
case PutDynamicVar:
case PutGetterById:
Modified: trunk/Source/_javascript_Core/dfg/DFGStoreBarrierClusteringPhase.cpp (278423 => 278424)
--- trunk/Source/_javascript_Core/dfg/DFGStoreBarrierClusteringPhase.cpp 2021-06-03 22:27:13 UTC (rev 278423)
+++ trunk/Source/_javascript_Core/dfg/DFGStoreBarrierClusteringPhase.cpp 2021-06-03 22:27:32 UTC (rev 278424)
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2016 Apple Inc. All rights reserved.
+ * Copyright (C) 2016-2021 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -40,10 +40,12 @@
namespace {
+constexpr bool verbose = false;
+
class StoreBarrierClusteringPhase : public Phase {
public:
StoreBarrierClusteringPhase(Graph& graph)
-: Phase(graph, "store barrier fencing")
+: Phase(graph, "store barrier clustering")
, m_insertionSet(graph)
{
}
@@ -98,6 +100,11 @@
// would be weird because it would create a new root for OSR availability analysis. I
// don't have evidence that it would be worth it.
if (doesGC(m_graph, node) || mayExit(m_graph, node) != DoesNotExit) {
+if (verbose) {
+dataLog("Possible GC point at ", node, "\n");
+dataLog("doesGC = ", doesGC(m_graph, node), "\n");
+dataLog("mayExit = ", mayExit(m_graph, node), "\n");
+}
futureGC = true;
continue;
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [277326] trunk/Source/JavaScriptCore
Title: [277326] trunk/Source/_javascript_Core Revision 277326 Author fpi...@apple.com Date 2021-05-11 08:52:17 -0700 (Tue, 11 May 2021) Log Message Tune number of threads for AS https://bugs.webkit.org/show_bug.cgi?id=225635 Reviewed by Mark Lam. Using 4 GC markers (which really means 3 parallel GC worker threads -- the mutator thread is the 4th), 2 DFG threads, and 2 FTL threads seems to be more optimal than going off ncpu. ~1% JetStream2 speed-up, ~1% Speedometer2 speed-up. * runtime/Options.cpp: (JSC::overrideDefaults): Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/runtime/Options.cpp Diff Modified: trunk/Source/_javascript_Core/ChangeLog (277325 => 277326) --- trunk/Source/_javascript_Core/ChangeLog 2021-05-11 15:33:13 UTC (rev 277325) +++ trunk/Source/_javascript_Core/ChangeLog 2021-05-11 15:52:17 UTC (rev 277326) @@ -1,3 +1,18 @@ +2021-05-10 Filip Pizlo + +Tune number of threads for AS +https://bugs.webkit.org/show_bug.cgi?id=225635 + +Reviewed by Mark Lam. + +Using 4 GC markers (which really means 3 parallel GC worker threads -- the mutator thread is +the 4th), 2 DFG threads, and 2 FTL threads seems to be more optimal than going off ncpu. + +~1% JetStream2 speed-up, ~1% Speedometer2 speed-up. + +* runtime/Options.cpp: +(JSC::overrideDefaults): + 2021-05-10 Mark Lam Removed unused CallRecord::bytecodeIndex field. Modified: trunk/Source/_javascript_Core/runtime/Options.cpp (277325 => 277326) --- trunk/Source/_javascript_Core/runtime/Options.cpp 2021-05-11 15:33:13 UTC (rev 277325) +++ trunk/Source/_javascript_Core/runtime/Options.cpp 2021-05-11 15:52:17 UTC (rev 277326) @@ -352,6 +352,12 @@ Options::gcIncrementScale() = 0; } +#if PLATFORM(MAC) && CPU(ARM64) +Options::numberOfGCMarkers() = 4; +Options::numberOfDFGCompilerThreads() = 2; +Options::numberOfFTLCompilerThreads() = 2; +#endif + #if USE(BMALLOC_MEMORY_FOOTPRINT_API) // On iOS and conditionally Linux, we control heap growth using process memory footprint. Therefore these values can be agressive. Options::smallHeapRAMFraction() = 0.8; ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [277133] trunk/Source/WTF
Title: [277133] trunk/Source/WTF
Revision 277133
Author fpi...@apple.com
Date 2021-05-06 15:30:16 -0700 (Thu, 06 May 2021)
Log Message
Remove old and unused memory barrier abstractions
https://bugs.webkit.org/show_bug.cgi?id=225487
Reviewed by Mark Lam.
We don't use memoryBarrierBlahBlah anymore.
* wtf/Atomics.h:
(WTF::memoryBarrierAfterLock): Deleted.
(WTF::memoryBarrierBeforeUnlock): Deleted.
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/Atomics.h
Diff
Modified: trunk/Source/WTF/ChangeLog (277132 => 277133)
--- trunk/Source/WTF/ChangeLog 2021-05-06 21:59:48 UTC (rev 277132)
+++ trunk/Source/WTF/ChangeLog 2021-05-06 22:30:16 UTC (rev 277133)
@@ -1,5 +1,18 @@
2021-05-06 Filip Pizlo
+Remove old and unused memory barrier abstractions
+https://bugs.webkit.org/show_bug.cgi?id=225487
+
+Reviewed by Mark Lam.
+
+We don't use memoryBarrierBlahBlah anymore.
+
+* wtf/Atomics.h:
+(WTF::memoryBarrierAfterLock): Deleted.
+(WTF::memoryBarrierBeforeUnlock): Deleted.
+
+2021-05-06 Filip Pizlo
+
Reduce use of dmb ish on ARM64
https://bugs.webkit.org/show_bug.cgi?id=225465
Modified: trunk/Source/WTF/wtf/Atomics.h (277132 => 277133)
--- trunk/Source/WTF/wtf/Atomics.h 2021-05-06 21:59:48 UTC (rev 277132)
+++ trunk/Source/WTF/wtf/Atomics.h 2021-05-06 22:30:16 UTC (rev 277133)
@@ -274,8 +274,6 @@
inline void loadStoreFence() { arm_dmb(); }
inline void storeLoadFence() { arm_dmb(); }
inline void storeStoreFence() { arm_dmb_st(); }
-inline void memoryBarrierAfterLock() { arm_dmb(); }
-inline void memoryBarrierBeforeUnlock() { arm_dmb(); }
inline void crossModifyingCodeFence() { arm_isb(); }
#elif CPU(X86) || CPU(X86_64)
@@ -312,8 +310,6 @@
inline void loadStoreFence() { compilerFence(); }
inline void storeLoadFence() { x86_ortop(); }
inline void storeStoreFence() { compilerFence(); }
-inline void memoryBarrierAfterLock() { compilerFence(); }
-inline void memoryBarrierBeforeUnlock() { compilerFence(); }
inline void crossModifyingCodeFence() { x86_cpuid(); }
#else
@@ -322,8 +318,6 @@
inline void loadStoreFence() { std::atomic_thread_fence(std::memory_order_seq_cst); }
inline void storeLoadFence() { std::atomic_thread_fence(std::memory_order_seq_cst); }
inline void storeStoreFence() { std::atomic_thread_fence(std::memory_order_seq_cst); }
-inline void memoryBarrierAfterLock() { std::atomic_thread_fence(std::memory_order_seq_cst); }
-inline void memoryBarrierBeforeUnlock() { std::atomic_thread_fence(std::memory_order_seq_cst); }
inline void crossModifyingCodeFence() { std::atomic_thread_fence(std::memory_order_seq_cst); } // Probably not strong enough.
#endif
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [277118] trunk/Source/JavaScriptCore
Title: [277118] trunk/Source/_javascript_Core
Revision 277118
Author fpi...@apple.com
Date 2021-05-06 13:55:29 -0700 (Thu, 06 May 2021)
Log Message
Make some things easier to dataLog in wasm
https://bugs.webkit.org/show_bug.cgi?id=225472
Reviewed by Yusuke Suzuki.
* wasm/WasmMemoryMode.cpp:
(WTF::printInternal):
* wasm/WasmMemoryMode.h:
* wasm/WasmWorklist.cpp:
(JSC::Wasm::Worklist::dump const):
* wasm/WasmWorklist.h:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/wasm/WasmMemoryMode.cpp
trunk/Source/_javascript_Core/wasm/WasmMemoryMode.h
trunk/Source/_javascript_Core/wasm/WasmWorklist.cpp
trunk/Source/_javascript_Core/wasm/WasmWorklist.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (277117 => 277118)
--- trunk/Source/_javascript_Core/ChangeLog 2021-05-06 20:54:16 UTC (rev 277117)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-05-06 20:55:29 UTC (rev 277118)
@@ -1,5 +1,19 @@
2021-05-06 Filip Pizlo
+Make some things easier to dataLog in wasm
+https://bugs.webkit.org/show_bug.cgi?id=225472
+
+Reviewed by Yusuke Suzuki.
+
+* wasm/WasmMemoryMode.cpp:
+(WTF::printInternal):
+* wasm/WasmMemoryMode.h:
+* wasm/WasmWorklist.cpp:
+(JSC::Wasm::Worklist::dump const):
+* wasm/WasmWorklist.h:
+
+2021-05-06 Filip Pizlo
+
Reduce use of dmb ish on ARM64
https://bugs.webkit.org/show_bug.cgi?id=225465
Modified: trunk/Source/_javascript_Core/wasm/WasmMemoryMode.cpp (277117 => 277118)
--- trunk/Source/_javascript_Core/wasm/WasmMemoryMode.cpp 2021-05-06 20:54:16 UTC (rev 277117)
+++ trunk/Source/_javascript_Core/wasm/WasmMemoryMode.cpp 2021-05-06 20:55:29 UTC (rev 277118)
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2016-2017 Apple Inc. All rights reserved.
+ * Copyright (C) 2016-2021 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -29,6 +29,7 @@
#if ENABLE(WEBASSEMBLY)
#include
+#include
namespace JSC { namespace Wasm {
@@ -54,4 +55,18 @@
} } // namespace JSC::Wasm
+namespace WTF {
+
+void printInternal(PrintStream& out, JSC::Wasm::MemoryMode mode)
+{
+out.print(JSC::Wasm::makeString(mode));
+}
+
+void printInternal(PrintStream& out, JSC::Wasm::MemorySharingMode mode)
+{
+out.print(JSC::Wasm::makeString(mode));
+}
+
+} // namespace WTF
+
#endif // ENABLE(WEBASSEMBLY)
Modified: trunk/Source/_javascript_Core/wasm/WasmMemoryMode.h (277117 => 277118)
--- trunk/Source/_javascript_Core/wasm/WasmMemoryMode.h 2021-05-06 20:54:16 UTC (rev 277117)
+++ trunk/Source/_javascript_Core/wasm/WasmMemoryMode.h 2021-05-06 20:55:29 UTC (rev 277118)
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2017 Apple Inc. All rights reserved.
+ * Copyright (C) 2017-2021 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -49,4 +49,12 @@
} } // namespace JSC::Wasm
+namespace WTF {
+
+class PrintStream;
+void printInternal(PrintStream&, JSC::Wasm::MemoryMode);
+void printInternal(PrintStream&, JSC::Wasm::MemorySharingMode);
+
+} // namespace WTF
+
#endif // ENABLE(WEBASSEMBLY)
Modified: trunk/Source/_javascript_Core/wasm/WasmWorklist.cpp (277117 => 277118)
--- trunk/Source/_javascript_Core/wasm/WasmWorklist.cpp 2021-05-06 20:54:16 UTC (rev 277117)
+++ trunk/Source/_javascript_Core/wasm/WasmWorklist.cpp 2021-05-06 20:55:29 UTC (rev 277118)
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2017-2019 Apple Inc. All rights reserved.
+ * Copyright (C) 2017-2021 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -49,6 +49,11 @@
RELEASE_ASSERT_NOT_REACHED();
}
+void Worklist::dump(PrintStream& out) const
+{
+out.print("Queue Size = ", m_queue.size());
+}
+
// The Thread class is designed to prevent threads from blocking when there is still work
// in the queue. Wasm's Plans have some phases, Validiation, Preparation, and Completion,
// that can only be done by one thread, and another phase, Compilation, that can be done
Modified: trunk/Source/_javascript_Core/wasm/WasmWorklist.h (277117 => 277118)
--- trunk/Source/_javascript_Core/wasm/WasmWorklist.h 2021-05-06 20:54:16 UTC (rev 277117)
+++ trunk/Source/_javascript_Core/wasm/WasmWorklist.h 2021-05-06 20:55:29 UTC (rev 277118)
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2017 Apple Inc. All rights reserved.
+ * Copyright (C) 2017-2021 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -30,6 +30,7 @@
#include
#include
+#include
#include
#include
@@ -59,6 +60,8 @@
};
const char* priorityString(P
[webkit-changes] [277117] trunk/Source
Title: [277117] trunk/Source Revision 277117 Author fpi...@apple.com Date 2021-05-06 13:54:16 -0700 (Thu, 06 May 2021) Log Message Reduce use of dmb ish on ARM64 https://bugs.webkit.org/show_bug.cgi?id=225465 Reviewed by Keith Miller. Source/_javascript_Core: We use loadLoadFence a lot, often in situations like: Foo* ptr = loadStuff; loadLoadFence(); use ptr On ARM64, we don't need a dmb ish here. This introduces a dependentLoadLoadFence() for these cases; it's just a compiler fence on ARM64 and Intel. We also used loadLoadFence in some places where I couldn't think of any good reason for the fence other than paranoia. I got rid of those. * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFromCallLinkInfo): * bytecode/CodeBlock.h: (JSC::CodeBlock::jitType const): * bytecode/ObjectAllocationProfile.h: (JSC::ObjectAllocationProfileBase::structure): (JSC::ObjectAllocationProfileWithPrototype::prototype): * bytecode/Watchpoint.h: (JSC::WatchpointSet::state const): (JSC::InlineWatchpointSet::state const): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::handlePutByVal): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnString): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt): * runtime/GetterSetter.h: * runtime/InferredValue.h: (JSC::InferredValue::state const): * runtime/Structure.h: (JSC::Structure::tryRareData): * runtime/StructureInlines.h: (JSC::Structure::propertyReplacementWatchpointSet): Source/WTF: * wtf/Atomics.h: (WTF::dependentLoadLoadFence): Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/bytecode/CallLinkStatus.cpp trunk/Source/_javascript_Core/bytecode/CodeBlock.h trunk/Source/_javascript_Core/bytecode/ObjectAllocationProfile.h trunk/Source/_javascript_Core/bytecode/Watchpoint.h trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp trunk/Source/_javascript_Core/runtime/GetterSetter.h trunk/Source/_javascript_Core/runtime/InferredValue.h trunk/Source/_javascript_Core/runtime/Structure.h trunk/Source/_javascript_Core/runtime/StructureInlines.h trunk/Source/WTF/ChangeLog trunk/Source/WTF/wtf/Atomics.h Diff Modified: trunk/Source/_javascript_Core/ChangeLog (277116 => 277117) --- trunk/Source/_javascript_Core/ChangeLog 2021-05-06 20:49:28 UTC (rev 277116) +++ trunk/Source/_javascript_Core/ChangeLog 2021-05-06 20:54:16 UTC (rev 277117) @@ -1,5 +1,49 @@ 2021-05-06 Filip Pizlo +Reduce use of dmb ish on ARM64 +https://bugs.webkit.org/show_bug.cgi?id=225465 + +Reviewed by Keith Miller. + +We use loadLoadFence a lot, often in situations like: + +Foo* ptr = loadStuff; +loadLoadFence(); +use ptr + +On ARM64, we don't need a dmb ish here. This introduces a dependentLoadLoadFence() for these +cases; it's just a compiler fence on ARM64 and Intel. + +We also used loadLoadFence in some places where I couldn't think of any good reason for the +fence other than paranoia. I got rid of those. + +* bytecode/CallLinkStatus.cpp: +(JSC::CallLinkStatus::computeFromCallLinkInfo): +* bytecode/CodeBlock.h: +(JSC::CodeBlock::jitType const): +* bytecode/ObjectAllocationProfile.h: +(JSC::ObjectAllocationProfileBase::structure): +(JSC::ObjectAllocationProfileWithPrototype::prototype): +* bytecode/Watchpoint.h: +(JSC::WatchpointSet::state const): +(JSC::InlineWatchpointSet::state const): +* dfg/DFGByteCodeParser.cpp: +(JSC::DFG::ByteCodeParser::parseBlock): +(JSC::DFG::ByteCodeParser::handlePutByVal): +* dfg/DFGSpeculativeJIT.cpp: +(JSC::DFG::SpeculativeJIT::compileGetByValOnString): +* ftl/FTLLowerDFGToB3.cpp: +(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt): +* runtime/GetterSetter.h: +* runtime/InferredValue.h: +(JSC::InferredValue::state const): +* runtime/Structure.h: +(JSC::Structure::tryRareData): +* runtime/StructureInlines.h: +(JSC::Structure::propertyReplacementWatchpointSet): + +2021-05-06 Filip Pizlo + It should be possible to --logJIT=true https://bugs.webkit.org/show_bug.cgi?id=225464 Modified: trunk/Source/_javascript_Core/bytecode/CallLinkStatus.cpp (277116 => 277117) --- trunk/Source/_javascript_Core/bytecode/CallLinkStatus.cpp 2021-05-06 20:49:28 UTC (rev 277116) +++ trunk/Source/_javascript_Core/bytecode/CallLinkStatus.cpp 2021-05-06 20:54:16 UTC (rev 277117) @@ -193,7 +193,7 @@ // never mutated after the PolymorphicCallStubRoutine is instantiated. We have some conservative // fencing in place to make sure that we see the variants list after construction. if
[webkit-changes] [277110] trunk/Source/JavaScriptCore
Title: [277110] trunk/Source/_javascript_Core
Revision 277110
Author fpi...@apple.com
Date 2021-05-06 12:41:15 -0700 (Thu, 06 May 2021)
Log Message
It should be possible to --logJIT=true
https://bugs.webkit.org/show_bug.cgi?id=225464
Reviewed by Mark Lam.
This makes it easy to just log when JITing happens. It's like --dumpDisassembly=true but
without the disassembly.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::finalizeCodeWithDisassemblyImpl):
* assembler/LinkBuffer.h:
* runtime/Options.cpp:
(JSC::Options::recomputeDependentOptions):
* runtime/OptionsList.h:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/assembler/LinkBuffer.cpp
trunk/Source/_javascript_Core/assembler/LinkBuffer.h
trunk/Source/_javascript_Core/runtime/Options.cpp
trunk/Source/_javascript_Core/runtime/OptionsList.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (277109 => 277110)
--- trunk/Source/_javascript_Core/ChangeLog 2021-05-06 19:29:01 UTC (rev 277109)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-05-06 19:41:15 UTC (rev 277110)
@@ -1,3 +1,20 @@
+2021-05-06 Filip Pizlo
+
+It should be possible to --logJIT=true
+https://bugs.webkit.org/show_bug.cgi?id=225464
+
+Reviewed by Mark Lam.
+
+This makes it easy to just log when JITing happens. It's like --dumpDisassembly=true but
+without the disassembly.
+
+* assembler/LinkBuffer.cpp:
+(JSC::LinkBuffer::finalizeCodeWithDisassemblyImpl):
+* assembler/LinkBuffer.h:
+* runtime/Options.cpp:
+(JSC::Options::recomputeDependentOptions):
+* runtime/OptionsList.h:
+
2021-05-06 Mark Lam
Forbid further execution in jsc shell if execution is terminated.
Modified: trunk/Source/_javascript_Core/assembler/LinkBuffer.cpp (277109 => 277110)
--- trunk/Source/_javascript_Core/assembler/LinkBuffer.cpp 2021-05-06 19:29:01 UTC (rev 277109)
+++ trunk/Source/_javascript_Core/assembler/LinkBuffer.cpp 2021-05-06 19:41:15 UTC (rev 277110)
@@ -90,9 +90,8 @@
}
#endif
-if (!dumpDisassembly || m_alreadyDisassembled)
-return result;
-
+bool justDumpingHeader = !dumpDisassembly || m_alreadyDisassembled;
+
StringPrintStream out;
out.printf("Generated JIT code for ");
va_list argList;
@@ -102,10 +101,16 @@
out.printf(":\n");
uint8_t* executableAddress = result.code().untaggedExecutableAddress();
-out.printf("Code at [%p, %p):\n", executableAddress, executableAddress + result.size());
+out.printf("Code at [%p, %p)%s\n", executableAddress, executableAddress + result.size(), justDumpingHeader ? "." : ":");
CString header = out.toCString();
+if (justDumpingHeader) {
+if (Options::logJIT())
+dataLog(header);
+return result;
+}
+
if (Options::asyncDisassembly()) {
CodeRef codeRefForDisassembly = result.retagged();
disassembleAsynchronously(header, WTFMove(codeRefForDisassembly), m_size, "");
Modified: trunk/Source/_javascript_Core/assembler/LinkBuffer.h (277109 => 277110)
--- trunk/Source/_javascript_Core/assembler/LinkBuffer.h 2021-05-06 19:29:01 UTC (rev 277109)
+++ trunk/Source/_javascript_Core/assembler/LinkBuffer.h 2021-05-06 19:41:15 UTC (rev 277110)
@@ -378,16 +378,16 @@
};
#if OS(LINUX)
-#define FINALIZE_CODE_IF(condition, linkBufferReference, resultPtrTag, ...) \
-(UNLIKELY((condition)) \
-? (linkBufferReference).finalizeCodeWithDisassembly(true, __VA_ARGS__) \
+#define FINALIZE_CODE_IF(condition, linkBufferReference, resultPtrTag, ...) \
+(UNLIKELY((condition) || JSC::Options::logJIT()) \
+? (linkBufferReference).finalizeCodeWithDisassembly((condition), __VA_ARGS__) \
: (UNLIKELY(JSC::Options::logJITCodeForPerf()) \
? (linkBufferReference).finalizeCodeWithDisassembly(false, __VA_ARGS__) \
: (linkBufferReference).finalizeCodeWithoutDisassembly()))
#else
-#define FINALIZE_CODE_IF(condition, linkBufferReference, resultPtrTag, ...) \
-(UNLIKELY((condition)) \
-? (linkBufferReference).finalizeCodeWithDisassembly(true, __VA_ARGS__) \
+#define FINALIZE_CODE_IF(condition, linkBufferReference, resultPtrTag, ...) \
+(UNLIKELY((condition) || JSC::Options::logJIT()) \
+? (linkBufferReference).finalizeCodeWithDisassembly((condition), __VA_ARGS__) \
: (linkBufferReference).finalizeCodeWithoutDisassembly())
#endif
Modified: trunk/Source/_javascript_Core/runtime/Options.cpp (277109 => 277110)
--- trunk/Source/_javascript_Core/runtime/Options.cpp 2021-05-06 19:29:01 UTC (rev 277109)
+++ trunk/Source/_javascript_Core/runtime/Options.cpp 2021-05-06 19:41:15 UTC (rev 277110)
@@ -451,7 +451,8 @@
if (!Options::useWebAssembly())
Options::useFastTLSForWasmContext() = false;
-if (Options::dumpDisas
[webkit-changes] [277105] trunk/Tools
Title: [277105] trunk/Tools
Revision 277105
Author fpi...@apple.com
Date 2021-05-06 11:58:21 -0700 (Thu, 06 May 2021)
Log Message
Make it easy to pass __XPC variables to run-benchmark
https://bugs.webkit.org/show_bug.cgi?id=225473
Reviewed by Stephanie Lewis.
* Scripts/webkitpy/benchmark_runner/browser_driver/osx_safari_driver.py:
(OSXSafariDriver.launch_url):
* Scripts/webkitpy/benchmark_runner/run_benchmark.py:
(config_argument_parser):
Modified Paths
trunk/Tools/ChangeLog
trunk/Tools/Scripts/webkitpy/benchmark_runner/browser_driver/osx_safari_driver.py
trunk/Tools/Scripts/webkitpy/benchmark_runner/run_benchmark.py
Diff
Modified: trunk/Tools/ChangeLog (277104 => 277105)
--- trunk/Tools/ChangeLog 2021-05-06 18:40:03 UTC (rev 277104)
+++ trunk/Tools/ChangeLog 2021-05-06 18:58:21 UTC (rev 277105)
@@ -1,3 +1,15 @@
+2021-05-06 Filip Pizlo
+
+Make it easy to pass __XPC variables to run-benchmark
+https://bugs.webkit.org/show_bug.cgi?id=225473
+
+Reviewed by Stephanie Lewis.
+
+* Scripts/webkitpy/benchmark_runner/browser_driver/osx_safari_driver.py:
+(OSXSafariDriver.launch_url):
+* Scripts/webkitpy/benchmark_runner/run_benchmark.py:
+(config_argument_parser):
+
2021-05-06 Aakash Jain
EWS bubbles should show current status after pressing 'Retry failed builds' button
Modified: trunk/Tools/Scripts/webkitpy/benchmark_runner/browser_driver/osx_safari_driver.py (277104 => 277105)
--- trunk/Tools/Scripts/webkitpy/benchmark_runner/browser_driver/osx_safari_driver.py 2021-05-06 18:40:03 UTC (rev 277104)
+++ trunk/Tools/Scripts/webkitpy/benchmark_runner/browser_driver/osx_safari_driver.py 2021-05-06 18:58:21 UTC (rev 277105)
@@ -2,6 +2,7 @@
import logging
import os
+import re
import subprocess
import time
@@ -26,6 +27,9 @@
def launch_url(self, url, options, browser_build_path, browser_path):
args = ['/Applications/Safari.app/Contents/MacOS/Safari']
env = {}
+for key, value in os.environ.items():
+if re.match(r"^__XPC_", key):
+env[key] = value
if browser_build_path:
browser_build_absolute_path = os.path.abspath(browser_build_path)
safari_app_in_build_path = os.path.join(browser_build_absolute_path, 'Safari.app/Contents/MacOS/Safari')
@@ -37,8 +41,10 @@
args = [safari_app_in_build_path]
if contains_frameworks:
-env = {'DYLD_FRAMEWORK_PATH': browser_build_absolute_path, 'DYLD_LIBRARY_PATH': browser_build_absolute_path,
-'__XPC_DYLD_FRAMEWORK_PATH': browser_build_absolute_path, '__XPC_DYLD_LIBRARY_PATH': browser_build_absolute_path}
+env['DYLD_FRAMEWORK_PATH'] = browser_build_absolute_path
+env['DYLD_LIBRARY_PATH'] = browser_build_absolute_path
+env['__XPC_DYLD_FRAMEWORK_PATH'] = browser_build_absolute_path
+env['__XPC_DYLD_LIBRARY_PATH'] = browser_build_absolute_path
elif not has_safari_app:
raise Exception('Could not find any framework "{}"'.format(browser_build_path))
Modified: trunk/Tools/Scripts/webkitpy/benchmark_runner/run_benchmark.py (277104 => 277105)
--- trunk/Tools/Scripts/webkitpy/benchmark_runner/run_benchmark.py 2021-05-06 18:40:03 UTC (rev 277104)
+++ trunk/Tools/Scripts/webkitpy/benchmark_runner/run_benchmark.py 2021-05-06 18:58:21 UTC (rev 277105)
@@ -32,7 +32,7 @@
def config_argument_parser():
-parser = argparse.ArgumentParser(description='Run browser based performance benchmarks. To run a single benchmark in the recommended way, use run-benchmark --plan. To see the vailable benchmarks, use run-benchmark --list-plans.')
+parser = argparse.ArgumentParser(description='Run browser based performance benchmarks. To run a single benchmark in the recommended way, use run-benchmark --plan. To see the vailable benchmarks, use run-benchmark --list-plans. This script passes through the __XPC variables in its environment to the Safari process.')
mutual_group = parser.add_mutually_exclusive_group(required=True)
mutual_group.add_argument('--plan', help='Run a specific benchmark plan (e.g. speedometer, jetstream).')
mutual_group.add_argument('--list-plans', action='', help='List all available benchmark plans.')
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [276858] trunk/Source/JavaScriptCore
Title: [276858] trunk/Source/_javascript_Core
Revision 276858
Author fpi...@apple.com
Date 2021-04-30 15:48:43 -0700 (Fri, 30 Apr 2021)
Log Message
Make small JIT pool tests pass on AS
https://bugs.webkit.org/show_bug.cgi?id=225256
Reviewed by Mark Lam.
If we ask for a JIT pool that is smaller than the smallest possible "region" (thing with jump
island) that we can create -- i.e. smaller than a jump region, then assume that the user is
asking us to create a pool that has that much usable space plus a jump region.
I think that this makes the option easier to use when you're testing ridiculously small JIT
pools, which we happen to do in our test suite.
Also remove some dead options I didn't mean to commit.
* jit/ExecutableAllocator.cpp:
(JSC::initializeJITPageReservation):
* runtime/OptionsList.h:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/jit/ExecutableAllocator.cpp
trunk/Source/_javascript_Core/runtime/OptionsList.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (276857 => 276858)
--- trunk/Source/_javascript_Core/ChangeLog 2021-04-30 22:25:33 UTC (rev 276857)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-04-30 22:48:43 UTC (rev 276858)
@@ -1,5 +1,25 @@
2021-04-30 Filip Pizlo
+Make small JIT pool tests pass on AS
+https://bugs.webkit.org/show_bug.cgi?id=225256
+
+Reviewed by Mark Lam.
+
+If we ask for a JIT pool that is smaller than the smallest possible "region" (thing with jump
+island) that we can create -- i.e. smaller than a jump region, then assume that the user is
+asking us to create a pool that has that much usable space plus a jump region.
+
+I think that this makes the option easier to use when you're testing ridiculously small JIT
+pools, which we happen to do in our test suite.
+
+Also remove some dead options I didn't mean to commit.
+
+* jit/ExecutableAllocator.cpp:
+(JSC::initializeJITPageReservation):
+* runtime/OptionsList.h:
+
+2021-04-30 Filip Pizlo
+
Make the JIT pool smaller on AS
https://bugs.webkit.org/show_bug.cgi?id=225249
Modified: trunk/Source/_javascript_Core/jit/ExecutableAllocator.cpp (276857 => 276858)
--- trunk/Source/_javascript_Core/jit/ExecutableAllocator.cpp 2021-04-30 22:25:33 UTC (rev 276857)
+++ trunk/Source/_javascript_Core/jit/ExecutableAllocator.cpp 2021-04-30 22:48:43 UTC (rev 276858)
@@ -332,9 +332,20 @@
reservation.size = fixedExecutableMemoryPoolSize;
-if (Options::jitMemoryReservationSize())
+if (Options::jitMemoryReservationSize()) {
reservation.size = Options::jitMemoryReservationSize();
+#if ENABLE(JUMP_ISLANDS)
+// If asked for a reservation smaller than island size, assume that we want that size allocation
+// plus an island. The alternative would be to turn off jump islands, but since we only use
+// this for testing, this is probably the easier way to do it.
+//
+// The main reason for this is that some JSC stress tests run with a 50KB pool. This hack means
+// we don't have to change anything about those tests.
+if (reservation.size < islandRegionSize)
+reservation.size += islandRegionSize;
+#endif // ENABLE(JUMP_ISLANDS)
+}
reservation.size = std::max(roundUpToMultipleOf(pageSize(), reservation.size), pageSize() * 2);
auto tryCreatePageReservation = [] (size_t reservationSize) {
Modified: trunk/Source/_javascript_Core/runtime/OptionsList.h (276857 => 276858)
--- trunk/Source/_javascript_Core/runtime/OptionsList.h 2021-04-30 22:25:33 UTC (rev 276857)
+++ trunk/Source/_javascript_Core/runtime/OptionsList.h 2021-04-30 22:48:43 UTC (rev 276858)
@@ -532,8 +532,6 @@
v(Bool, useErrorCause, true, Normal, "Allow a cause to be provided when constructing an Error, _NativeError_, or AggregateError.") \
v(Bool, useSharedArrayBuffer, false, Normal, nullptr) \
v(Bool, useTopLevelAwait, true, Normal, "allow the await keyword at the top level of a module.") \
-v(Bool, dumpLinking, false, Normal, nullptr) \
-v(Bool, verifySame4GBLink, false, Normal, nullptr) \
v(Bool, verboseExecutablePoolAllocation, false, Normal, nullptr) \
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [276855] trunk/Source/JavaScriptCore
Title: [276855] trunk/Source/_javascript_Core
Revision 276855
Author fpi...@apple.com
Date 2021-04-30 14:50:21 -0700 (Fri, 30 Apr 2021)
Log Message
Make the JIT pool smaller on AS
https://bugs.webkit.org/show_bug.cgi?id=225249
Reviewed by Saam Barati.
This adds three related features:
- Makes it easy to dump where the JIT pool was allocated.
- Makes it possible to override the JIT pool size with Options even with jump islands.
- Changes the default JIT pool size on AS to 512MB.
Estimated 2% speed-up on JetStream2, 1.5% speed-up on Speedometer2.
* jit/ExecutableAllocator.cpp:
(JSC::initializeJITPageReservation):
* runtime/OptionsList.h:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/jit/ExecutableAllocator.cpp
trunk/Source/_javascript_Core/runtime/OptionsList.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (276854 => 276855)
--- trunk/Source/_javascript_Core/ChangeLog 2021-04-30 21:49:41 UTC (rev 276854)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-04-30 21:50:21 UTC (rev 276855)
@@ -1,3 +1,24 @@
+2021-04-30 Filip Pizlo
+
+Make the JIT pool smaller on AS
+https://bugs.webkit.org/show_bug.cgi?id=225249
+
+Reviewed by Saam Barati.
+
+This adds three related features:
+
+- Makes it easy to dump where the JIT pool was allocated.
+
+- Makes it possible to override the JIT pool size with Options even with jump islands.
+
+- Changes the default JIT pool size on AS to 512MB.
+
+Estimated 2% speed-up on JetStream2, 1.5% speed-up on Speedometer2.
+
+* jit/ExecutableAllocator.cpp:
+(JSC::initializeJITPageReservation):
+* runtime/OptionsList.h:
+
2021-04-29 Saam Barati
Inlining property accesses inside constant folding should check Options::useAccessInlining
Modified: trunk/Source/_javascript_Core/jit/ExecutableAllocator.cpp (276854 => 276855)
--- trunk/Source/_javascript_Core/jit/ExecutableAllocator.cpp 2021-04-30 21:49:41 UTC (rev 276854)
+++ trunk/Source/_javascript_Core/jit/ExecutableAllocator.cpp 2021-04-30 21:50:21 UTC (rev 276855)
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2008-2020 Apple Inc. All rights reserved.
+ * Copyright (C) 2008-2021 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -95,12 +95,12 @@
static constexpr size_t fixedExecutableMemoryPoolSize = 16 * MB;
#elif CPU(ARM64)
#if ENABLE(JUMP_ISLANDS)
-static constexpr size_t fixedExecutableMemoryPoolSize = 1 * GB;
+static constexpr size_t fixedExecutableMemoryPoolSize = 512 * MB;
// These sizes guarantee that any jump within an island can jump forwards or backwards
// to the adjacent island in a single instruction.
static constexpr size_t regionSize = 112 * MB;
static constexpr size_t islandRegionSize = 16 * MB;
-static constexpr size_t numberOfRegions = fixedExecutableMemoryPoolSize / regionSize;
+static constexpr size_t maxNumberOfRegions = fixedExecutableMemoryPoolSize / regionSize;
static constexpr size_t islandSizeInBytes = 4;
static constexpr size_t maxIslandsPerRegion = islandRegionSize / islandSizeInBytes;
#else
@@ -331,12 +331,10 @@
return reservation;
reservation.size = fixedExecutableMemoryPoolSize;
-#if !ENABLE(JUMP_ISLANDS)
-// FIXME: Consider making jump islands work with Options::jitMemoryReservationSize
-// https://bugs.webkit.org/show_bug.cgi?id=209037
+
if (Options::jitMemoryReservationSize())
reservation.size = Options::jitMemoryReservationSize();
-#endif
+
reservation.size = std::max(roundUpToMultipleOf(pageSize(), reservation.size), pageSize() * 2);
auto tryCreatePageReservation = [] (size_t reservationSize) {
@@ -351,6 +349,10 @@
};
reservation.pageReservation = tryCreatePageReservation(reservation.size);
+
+if (Options::verboseExecutablePoolAllocation())
+dataLog(getpid(), ": Got executable pool reservation at ", RawPointer(reservation.pageReservation.base()), "...", RawPointer(bitwise_cast(reservation.pageReservation.base()) + reservation.pageReservation.size()), ", while I'm at ", RawPointer(bitwise_cast(initializeJITPageReservation)), "\n");
+
if (reservation.pageReservation) {
ASSERT(reservation.pageReservation.size() == reservation.size);
reservation.base = reservation.pageReservation.base();
@@ -397,7 +399,8 @@
public:
FixedVMPoolExecutableAllocator()
#if ENABLE(JUMP_ISLANDS)
-: m_allocators(constructFixedSizeArrayWithArguments(*this))
+: m_allocators(constructFixedSizeArrayWithArguments(*this))
+, m_numAllocators(maxNumberOfRegions)
#else
: m_allocator(*this)
#endif
@@ -408,13 +411,17 @@
#if ENABLE(JUMP_ISLANDS)
uintptr_t start = bitwise_cast(memoryStart());
uintptr_t reservationEnd = bitwise_cast(memoryEnd());
-for (size_t i =
[webkit-changes] [276686] trunk/Source/JavaScriptCore
Title: [276686] trunk/Source/_javascript_Core
Revision 276686
Author fpi...@apple.com
Date 2021-04-27 18:01:15 -0700 (Tue, 27 Apr 2021)
Log Message
Get the bytecode profiler working again
https://bugs.webkit.org/show_bug.cgi?id=225129
Reviewed by Saam Barati.
The bytecode profiler was broken because it was trying to look at unset labels. This patch
improves our label discipline a bit so we don't try to look at unset labels.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::linkOSRExits):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGJITCompiler.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (276685 => 276686)
--- trunk/Source/_javascript_Core/ChangeLog 2021-04-28 00:54:42 UTC (rev 276685)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-04-28 01:01:15 UTC (rev 276686)
@@ -1,3 +1,18 @@
+2021-04-27 Filip Pizlo
+
+Get the bytecode profiler working again
+https://bugs.webkit.org/show_bug.cgi?id=225129
+
+Reviewed by Saam Barati.
+
+The bytecode profiler was broken because it was trying to look at unset labels. This patch
+improves our label discipline a bit so we don't try to look at unset labels.
+
+* dfg/DFGJITCompiler.cpp:
+(JSC::DFG::JITCompiler::linkOSRExits):
+* dfg/DFGSpeculativeJIT.cpp:
+(JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
+
2021-04-27 Mark Lam
Move ExceptionExpectation into its own .h file.
Modified: trunk/Source/_javascript_Core/dfg/DFGJITCompiler.cpp (276685 => 276686)
--- trunk/Source/_javascript_Core/dfg/DFGJITCompiler.cpp 2021-04-28 00:54:42 UTC (rev 276685)
+++ trunk/Source/_javascript_Core/dfg/DFGJITCompiler.cpp 2021-04-28 01:01:15 UTC (rev 276686)
@@ -71,11 +71,17 @@
for (unsigned i = 0; i < m_osrExit.size(); ++i) {
OSRExitCompilationInfo& info = m_exitCompilationInfo[i];
Vector labels;
+
+auto appendLabel = [&] (Label label) {
+RELEASE_ASSERT(label.isSet());
+labels.append(label);
+};
+
if (!info.m_failureJumps.empty()) {
for (unsigned j = 0; j < info.m_failureJumps.jumps().size(); ++j)
-labels.append(info.m_failureJumps.jumps()[j].label());
-} else
-labels.append(info.m_replacementSource);
+appendLabel(info.m_failureJumps.jumps()[j].label());
+} else if (info.m_replacementSource.isSet())
+appendLabel(info.m_replacementSource);
m_exitSiteLabels.append(labels);
}
}
Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp (276685 => 276686)
--- trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp 2021-04-28 00:54:42 UTC (rev 276685)
+++ trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp 2021-04-28 01:01:15 UTC (rev 276686)
@@ -334,7 +334,7 @@
UncountableInvalidation, JSValueSource(), MethodOfGettingAValueProfile(),
this, m_stream->size()));
info.m_replacementSource = m_jit.watchpointLabel();
-ASSERT(info.m_replacementSource.isSet());
+RELEASE_ASSERT(info.m_replacementSource.isSet());
noResult(node);
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [260575] trunk/Websites/webkit.org
Title: [260575] trunk/Websites/webkit.org Revision 260575 Author fpi...@apple.com Date 2020-04-23 10:07:56 -0700 (Thu, 23 Apr 2020) Log Message Unreviewed, check in some more files for a blog post. * blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle: * blog-files/speculation-in-jsc/clobberize-dependence-graph.svg: Modified Paths trunk/Websites/webkit.org/ChangeLog trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.svg Diff Modified: trunk/Websites/webkit.org/ChangeLog (260574 => 260575) --- trunk/Websites/webkit.org/ChangeLog 2020-04-23 16:27:03 UTC (rev 260574) +++ trunk/Websites/webkit.org/ChangeLog 2020-04-23 17:07:56 UTC (rev 260575) @@ -1,3 +1,10 @@ +2020-04-23 Filip Pizlo + +Unreviewed, check in some more files for a blog post. + +* blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle: +* blog-files/speculation-in-jsc/clobberize-dependence-graph.svg: + 2020-04-21 Filip Pizlo Unreviewed, check in some more files for a blog post. Modified: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle (Binary files differ) Modified: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.svg (260574 => 260575) --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.svg 2020-04-23 16:27:03 UTC (rev 260574) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.svg 2020-04-23 17:07:56 UTC (rev 260575) @@ -1,6 +1,6 @@ - + @@ -28,12 +28,12 @@ - Produced by OmniGraffle 7.15 -2020-04-21 23:00:36 + + Produced by OmniGraffle 7.15.1 +2020-04-23 17:05:47 + - + Canvas 1 - + Layer 1 @@ -106,32 +106,20 @@ GetByOffset(“g”) - - - - - - - - - - - - - + - + - + - + - + ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [260472] trunk/Websites/webkit.org
Title: [260472] trunk/Websites/webkit.org Revision 260472 Author fpi...@apple.com Date 2020-04-21 16:01:04 -0700 (Tue, 21 Apr 2020) Log Message Unreviewed, check in some more files for a blog post. * blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle: * blog-files/speculation-in-jsc/clobberize-dependence-graph.svg: Modified Paths trunk/Websites/webkit.org/ChangeLog trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.svg Diff Modified: trunk/Websites/webkit.org/ChangeLog (260471 => 260472) --- trunk/Websites/webkit.org/ChangeLog 2020-04-21 23:00:32 UTC (rev 260471) +++ trunk/Websites/webkit.org/ChangeLog 2020-04-21 23:01:04 UTC (rev 260472) @@ -2,6 +2,13 @@ Unreviewed, check in some more files for a blog post. +* blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle: +* blog-files/speculation-in-jsc/clobberize-dependence-graph.svg: + +2020-04-21 Filip Pizlo + +Unreviewed, check in some more files for a blog post. + * blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle: Added. * blog-files/speculation-in-jsc/clobberize-dependence-graph.svg: Added. Modified: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle (Binary files differ) Modified: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.svg (260471 => 260472) --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.svg 2020-04-21 23:00:32 UTC (rev 260471) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.svg 2020-04-21 23:01:04 UTC (rev 260472) @@ -29,7 +29,7 @@ Produced by OmniGraffle 7.15 -2020-04-21 22:50:59 + +2020-04-21 23:00:36 + Canvas 1 @@ -119,7 +119,7 @@ - + @@ -172,6 +172,12 @@ + + + + + + ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [260470] trunk/Websites/webkit.org
Title: [260470] trunk/Websites/webkit.org Revision 260470 Author fpi...@apple.com Date 2020-04-21 15:55:04 -0700 (Tue, 21 Apr 2020) Log Message Unreviewed, check in some more files for a blog post. * blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle: Added. * blog-files/speculation-in-jsc/clobberize-dependence-graph.svg: Added. Modified Paths trunk/Websites/webkit.org/ChangeLog Added Paths trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.svg Diff Modified: trunk/Websites/webkit.org/ChangeLog (260469 => 260470) --- trunk/Websites/webkit.org/ChangeLog 2020-04-21 22:53:42 UTC (rev 260469) +++ trunk/Websites/webkit.org/ChangeLog 2020-04-21 22:55:04 UTC (rev 260470) @@ -2,6 +2,13 @@ Unreviewed, check in some more files for a blog post. +* blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle: Added. +* blog-files/speculation-in-jsc/clobberize-dependence-graph.svg: Added. + +2020-04-21 Filip Pizlo + +Unreviewed, check in some more files for a blog post. + * blog-files/speculation-in-jsc/abstract-heaps.graffle: * blog-files/speculation-in-jsc/abstract-heaps.svg: Added: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle (Binary files differ) Index: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle === --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle 2020-04-21 22:53:42 UTC (rev 260469) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle 2020-04-21 22:55:04 UTC (rev 260470) Property changes on: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.graffle ___ Added: svn:mime-type +application/octet-stream \ No newline at end of property Added: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.svg (0 => 260470) --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.svg (rev 0) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/clobberize-dependence-graph.svg 2020-04-21 22:55:04 UTC (rev 260470) @@ -0,0 +1,177 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Produced by OmniGraffle 7.15 +2020-04-21 22:50:59 + + + +Canvas 1 + + + Layer 1 + + + + + Call + + + + + + + PutByOffset(“f”) + + + + + + + PutByOffset(“g”) + + + + + + + PutByOffset(“h”) + + + + + + + PutByOffset(“i”) + + + + + + + PutByOffset(“j”) + + + + + + + GetByOffset(“h”) + + + + + + + GetByOffset(“j”) + + + + + + + GetByOffset(“f”) + + + + + + + GetByOffset(“g”) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Legend + + + + + Dependence edges + implicitly represented by + results of clobberize. + + + + + + + + + Instructions explicitly + represented in IR. + + + + + + + + ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [260466] trunk/Websites/webkit.org
Title: [260466] trunk/Websites/webkit.org Revision 260466 Author fpi...@apple.com Date 2020-04-21 15:37:18 -0700 (Tue, 21 Apr 2020) Log Message Unreviewed, check in some more files for a blog post. * blog-files/speculation-in-jsc/abstract-heaps.graffle: * blog-files/speculation-in-jsc/abstract-heaps.svg: Modified Paths trunk/Websites/webkit.org/ChangeLog trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.graffle trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.svg Diff Modified: trunk/Websites/webkit.org/ChangeLog (260465 => 260466) --- trunk/Websites/webkit.org/ChangeLog 2020-04-21 22:33:58 UTC (rev 260465) +++ trunk/Websites/webkit.org/ChangeLog 2020-04-21 22:37:18 UTC (rev 260466) @@ -9,6 +9,13 @@ Unreviewed, check in some more files for a blog post. +* blog-files/speculation-in-jsc/abstract-heaps.graffle: +* blog-files/speculation-in-jsc/abstract-heaps.svg: + +2020-04-21 Filip Pizlo + +Unreviewed, check in some more files for a blog post. + * blog-files/speculation-in-jsc/abstract-heaps.graffle: Added. * blog-files/speculation-in-jsc/abstract-heaps.svg: Added. Modified: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.graffle (Binary files differ) Modified: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.svg (260465 => 260466) --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.svg 2020-04-21 22:33:58 UTC (rev 260465) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.svg 2020-04-21 22:37:18 UTC (rev 260466) @@ -7,7 +7,7 @@ - + @@ -27,9 +27,14 @@ + + + + + Produced by OmniGraffle 7.15 -2020-04-21 22:32:40 + +2020-04-21 22:36:32 + Canvas 1 @@ -60,9 +65,9 @@ - - Side - State + + Side + State @@ -144,23 +149,23 @@ - - - - JSCell_ + + + + JSCell_ structureID - - - + + + JSObject_ butterfly - + … ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [260464] trunk/Websites/webkit.org
Title: [260464] trunk/Websites/webkit.org Revision 260464 Author fpi...@apple.com Date 2020-04-21 15:33:08 -0700 (Tue, 21 Apr 2020) Log Message Unreviewed, check in some more files for a blog post. * blog-files/speculation-in-jsc/abstract-heaps.graffle: * blog-files/speculation-in-jsc/abstract-heaps.svg: Modified Paths trunk/Websites/webkit.org/ChangeLog trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.graffle trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.svg Diff Modified: trunk/Websites/webkit.org/ChangeLog (260463 => 260464) --- trunk/Websites/webkit.org/ChangeLog 2020-04-21 22:27:16 UTC (rev 260463) +++ trunk/Websites/webkit.org/ChangeLog 2020-04-21 22:33:08 UTC (rev 260464) @@ -2,6 +2,13 @@ Unreviewed, check in some more files for a blog post. +* blog-files/speculation-in-jsc/abstract-heaps.graffle: +* blog-files/speculation-in-jsc/abstract-heaps.svg: + +2020-04-21 Filip Pizlo + +Unreviewed, check in some more files for a blog post. + * blog-files/speculation-in-jsc/abstract-heaps.graffle: Added. * blog-files/speculation-in-jsc/abstract-heaps.svg: Added. Modified: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.graffle (Binary files differ) Modified: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.svg (260463 => 260464) --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.svg 2020-04-21 22:27:16 UTC (rev 260463) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.svg 2020-04-21 22:33:08 UTC (rev 260464) @@ -2,29 +2,34 @@ - + - + - + - + - + - + - + - + + + + + + Produced by OmniGraffle 7.15 -2020-04-21 22:25:51 + +2020-04-21 22:32:40 + Canvas 1 @@ -34,129 +39,129 @@ - - World + + World - - Heap + + Heap - - Stack + + Stack - - Side - State + + Side + State - - argN + + argN - - arg1 + + arg1 - - … + + … - - this + + this - - loc0 + + loc0 - - locN + + locN - - … + + … - - NamedProperties + + NamedProperties - - “foo” + + “foo” - - “bar” + + “bar” - - “baz” + + “baz” - - … + + … - - JSCell_ - structureID + + JSCell_ + structureID - - JSObject_ - butterfly + + JSObject_ + butterfly - - … + + … ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [260463] trunk/Websites/webkit.org
Title: [260463] trunk/Websites/webkit.org Revision 260463 Author fpi...@apple.com Date 2020-04-21 15:27:16 -0700 (Tue, 21 Apr 2020) Log Message Unreviewed, check in some more files for a blog post. * blog-files/speculation-in-jsc/abstract-heaps.graffle: Added. * blog-files/speculation-in-jsc/abstract-heaps.svg: Added. Modified Paths trunk/Websites/webkit.org/ChangeLog Added Paths trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.graffle trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.svg Diff Modified: trunk/Websites/webkit.org/ChangeLog (260462 => 260463) --- trunk/Websites/webkit.org/ChangeLog 2020-04-21 22:21:29 UTC (rev 260462) +++ trunk/Websites/webkit.org/ChangeLog 2020-04-21 22:27:16 UTC (rev 260463) @@ -1,3 +1,10 @@ +2020-04-21 Filip Pizlo + +Unreviewed, check in some more files for a blog post. + +* blog-files/speculation-in-jsc/abstract-heaps.graffle: Added. +* blog-files/speculation-in-jsc/abstract-heaps.svg: Added. + 2020-04-18 Filip Pizlo Unreviewed, check in some more files for a blog post. Added: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.graffle (Binary files differ) Index: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.graffle === --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.graffle 2020-04-21 22:21:29 UTC (rev 260462) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.graffle 2020-04-21 22:27:16 UTC (rev 260463) Property changes on: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.graffle ___ Added: svn:mime-type +application/octet-stream \ No newline at end of property Added: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.svg (0 => 260463) --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.svg (rev 0) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/abstract-heaps.svg 2020-04-21 22:27:16 UTC (rev 260463) @@ -0,0 +1,164 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + Produced by OmniGraffle 7.15 +2020-04-21 22:25:51 + + + +Canvas 1 + + + Layer 1 + + + + + World + + + + + + + Heap + + + + + + + Stack + + + + + + + Side + State + + + + + + + argN + + + + + + + arg1 + + + + + … + + + + + + + this + + + + + + + loc0 + + + + + + + locN + + + + + … + + + + + + + NamedProperties + + + + + + + “foo” + + + + + + + “bar” + + + + + + + “baz” + + + + + … + + + + + + + JSCell_ + structureID + + + + + + + JSObject_ + butterfly + + + + + … + + + + + ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [260324] trunk/Websites/webkit.org
Title: [260324] trunk/Websites/webkit.org Revision 260324 Author fpi...@apple.com Date 2020-04-18 14:52:57 -0700 (Sat, 18 Apr 2020) Log Message Unreviewed, check in some more files for a blog post. * blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.graffle: * blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.svg: Modified Paths trunk/Websites/webkit.org/ChangeLog trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.graffle trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.svg Diff Modified: trunk/Websites/webkit.org/ChangeLog (260323 => 260324) --- trunk/Websites/webkit.org/ChangeLog 2020-04-18 21:45:34 UTC (rev 260323) +++ trunk/Websites/webkit.org/ChangeLog 2020-04-18 21:52:57 UTC (rev 260324) @@ -2,6 +2,13 @@ Unreviewed, check in some more files for a blog post. +* blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.graffle: +* blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.svg: + +2020-04-18 Filip Pizlo + +Unreviewed, check in some more files for a blog post. + * blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.graffle: Added. * blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.svg: Added. Modified: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.graffle (Binary files differ) Modified: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.svg (260323 => 260324) --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.svg 2020-04-18 21:45:34 UTC (rev 260323) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.svg 2020-04-18 21:52:57 UTC (rev 260324) @@ -1,6 +1,6 @@ - + @@ -44,11 +44,11 @@ Produced by OmniGraffle 7.15 -2020-04-18 19:55:30 + +2020-04-18 21:52:29 + Canvas 1 - + Layer 1 @@ -56,32 +56,32 @@ - - + + - - + + - + - + - - + + - - + + - + - + @@ -141,28 +141,28 @@ - + - + - + - + - + - + - + - + @@ -195,38 +195,42 @@ - - + + + OSR exit to bc#7 - - + + + OSR exit to bc#11 - - + + + OSR exit to bc#15 - - + + + OSR exit to bc#20 - - - + + + Legend - + Implicit fall-through control flow inside basic blocks @@ -233,38 +237,38 @@ - - Implicit OSR control flow - that exits blocks - sideways + + OSR control flow that + exits blocks sideways to + where the exit origin says - - + + - + - + Explicit control flow between basic blocks - - + + - + - - + + - + ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [260320] trunk/Websites/webkit.org
Title: [260320] trunk/Websites/webkit.org Revision 260320 Author fpi...@apple.com Date 2020-04-18 14:08:36 -0700 (Sat, 18 Apr 2020) Log Message Unreviewed, check in some more files for a blog post. * blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.graffle: Added. * blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.svg: Added. Modified Paths trunk/Websites/webkit.org/ChangeLog Added Paths trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.graffle trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.svg Diff Modified: trunk/Websites/webkit.org/ChangeLog (260319 => 260320) --- trunk/Websites/webkit.org/ChangeLog 2020-04-18 20:24:31 UTC (rev 260319) +++ trunk/Websites/webkit.org/ChangeLog 2020-04-18 21:08:36 UTC (rev 260320) @@ -1,3 +1,10 @@ +2020-04-18 Filip Pizlo + +Unreviewed, check in some more files for a blog post. + +* blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.graffle: Added. +* blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.svg: Added. + 2020-04-14 Filip Pizlo Unreviewed, check in some more files for a blog post. Added: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.graffle (Binary files differ) Index: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.graffle === --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.graffle 2020-04-18 20:24:31 UTC (rev 260319) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.graffle 2020-04-18 21:08:36 UTC (rev 260320) Property changes on: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.graffle ___ Added: svn:mime-type +application/octet-stream \ No newline at end of property Added: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.svg (0 => 260320) --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.svg (rev 0) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/osr-exit-implicit-control-flow.svg 2020-04-18 21:08:36 UTC (rev 260320) @@ -0,0 +1,271 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Produced by OmniGraffle 7.15 +2020-04-18 19:55:30 + + + +Canvas 1 + + + Layer 1 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + GetLocal + + + + + + + GetLocal + + + + + + + ArithAdd + + + + + + + GetByVal + + + + + + + Call + + + + + + + Branch + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + bc#7 + + + + + bc#7 + + + + + bc#7 + + + + + bc#11 + + + + + bc#15 + + + + + bc#20 + + + + + + OSR exit to bc#7 + + + + + + OSR exit to bc#11 + + + + + + OSR exit to bc#15 + + + + + + OSR exit to bc#20 + + + + + + + Legend + + + + + Implicit fall-through + control flow inside basic + blocks + + + + + Implicit OSR control flow + that exits blocks + sideways + + + + + + + + + + + + Explicit control
[webkit-changes] [260109] trunk/Websites/webkit.org
Title: [260109] trunk/Websites/webkit.org Revision 260109 Author fpi...@apple.com Date 2020-04-14 16:59:30 -0700 (Tue, 14 Apr 2020) Log Message Unreviewed, check in some more files for a blog post. * blog-files/speculation-in-jsc/full-add-cfg.graffle: * blog-files/speculation-in-jsc/full-add-cfg.svg: Modified Paths trunk/Websites/webkit.org/ChangeLog trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.graffle trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.svg Diff Modified: trunk/Websites/webkit.org/ChangeLog (260108 => 260109) --- trunk/Websites/webkit.org/ChangeLog 2020-04-14 23:58:32 UTC (rev 260108) +++ trunk/Websites/webkit.org/ChangeLog 2020-04-14 23:59:30 UTC (rev 260109) @@ -9,6 +9,13 @@ Unreviewed, check in some more files for a blog post. +* blog-files/speculation-in-jsc/full-add-cfg.graffle: +* blog-files/speculation-in-jsc/full-add-cfg.svg: + +2020-04-14 Filip Pizlo + +Unreviewed, check in some more files for a blog post. + * blog-files/speculation-in-jsc/full-add-cfg.graffle: Added. * blog-files/speculation-in-jsc/full-add-cfg.svg: Added. Modified: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.graffle (Binary files differ) Modified: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.svg (260108 => 260109) --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.svg 2020-04-14 23:58:32 UTC (rev 260108) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.svg 2020-04-14 23:59:30 UTC (rev 260109) @@ -1,6 +1,6 @@ - + @@ -19,11 +19,11 @@ Produced by OmniGraffle 7.15 -2020-04-14 23:57:26 + +2020-04-14 23:59:02 + Canvas 1 - + Layer 1 @@ -55,9 +55,9 @@ - - - + + + Branch(isNumber(right)) @@ -104,9 +104,9 @@ - - - + + + Call(slow path) @@ -135,7 +135,7 @@ - + @@ -144,22 +144,22 @@ - + - + - + - + - + ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [260107] trunk/Websites/webkit.org
Title: [260107] trunk/Websites/webkit.org Revision 260107 Author fpi...@apple.com Date 2020-04-14 16:57:49 -0700 (Tue, 14 Apr 2020) Log Message Unreviewed, check in some more files for a blog post. * blog-files/speculation-in-jsc/full-add-cfg.graffle: * blog-files/speculation-in-jsc/full-add-cfg.svg: Modified Paths trunk/Websites/webkit.org/ChangeLog trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.graffle trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.svg Diff Modified: trunk/Websites/webkit.org/ChangeLog (260106 => 260107) --- trunk/Websites/webkit.org/ChangeLog 2020-04-14 23:57:32 UTC (rev 260106) +++ trunk/Websites/webkit.org/ChangeLog 2020-04-14 23:57:49 UTC (rev 260107) @@ -2,6 +2,13 @@ Unreviewed, check in some more files for a blog post. +* blog-files/speculation-in-jsc/full-add-cfg.graffle: +* blog-files/speculation-in-jsc/full-add-cfg.svg: + +2020-04-14 Filip Pizlo + +Unreviewed, check in some more files for a blog post. + * blog-files/speculation-in-jsc/full-add-cfg.graffle: Added. * blog-files/speculation-in-jsc/full-add-cfg.svg: Added. Modified: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.graffle (Binary files differ) Modified: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.svg (260106 => 260107) --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.svg 2020-04-14 23:57:32 UTC (rev 260106) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.svg 2020-04-14 23:57:49 UTC (rev 260107) @@ -1,6 +1,6 @@ - + @@ -19,11 +19,11 @@ Produced by OmniGraffle 7.15 -2020-04-14 23:53:16 + +2020-04-14 23:57:26 + Canvas 1 - + Layer 1 @@ -41,30 +41,30 @@ - - - + + + … int32 add … - - - + + + Branch(isNumber(left)) - - - + + + Branch(isNumber(right)) - - - + + + … double add … @@ -76,16 +76,16 @@ - - - + + + Branch(isInt32(right)) - - - + + + … convert right to double … @@ -104,9 +104,9 @@ - - - + + + Call(slow path) @@ -114,52 +114,52 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [260105] trunk/Websites/webkit.org
Title: [260105] trunk/Websites/webkit.org Revision 260105 Author fpi...@apple.com Date 2020-04-14 16:54:29 -0700 (Tue, 14 Apr 2020) Log Message Unreviewed, check in some more files for a blog post. * blog-files/speculation-in-jsc/full-add-cfg.graffle: Added. * blog-files/speculation-in-jsc/full-add-cfg.svg: Added. Modified Paths trunk/Websites/webkit.org/ChangeLog Added Paths trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.graffle trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.svg Diff Modified: trunk/Websites/webkit.org/ChangeLog (260104 => 260105) --- trunk/Websites/webkit.org/ChangeLog 2020-04-14 23:53:25 UTC (rev 260104) +++ trunk/Websites/webkit.org/ChangeLog 2020-04-14 23:54:29 UTC (rev 260105) @@ -2,6 +2,13 @@ Unreviewed, check in some more files for a blog post. +* blog-files/speculation-in-jsc/full-add-cfg.graffle: Added. +* blog-files/speculation-in-jsc/full-add-cfg.svg: Added. + +2020-04-14 Filip Pizlo + +Unreviewed, check in some more files for a blog post. + * blog-files/speculation-in-jsc/dfg-pipeline-dark.graffle: Added. * blog-files/speculation-in-jsc/dfg-pipeline-dark.svg: Added. * blog-files/speculation-in-jsc/ftl-pipeline-dark.graffle Added: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.graffle (Binary files differ) Index: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.graffle === --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.graffle 2020-04-14 23:53:25 UTC (rev 260104) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.graffle 2020-04-14 23:54:29 UTC (rev 260105) Property changes on: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.graffle ___ Added: svn:mime-type +application/octet-stream \ No newline at end of property Added: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.svg (0 => 260105) --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.svg (rev 0) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/full-add-cfg.svg 2020-04-14 23:54:29 UTC (rev 260105) @@ -0,0 +1,166 @@ + + + + + + + + + + + + + + + + + + + + + Produced by OmniGraffle 7.15 +2020-04-14 23:53:16 + + + +Canvas 1 + + + Layer 1 + + + + + Branch(isInt32(left)) + + + + + + + Branch(isInt32(right)) + + + + + + + … int32 add … + + + + + + + Branch(isNumber(left)) + + + + + + + Branch(isNumber(right)) + + + + + + + … double add … + + + + + + + Branch(isNumber(right)) + + + + + + + Branch(isInt32(right)) + + + + + + + … convert right to double … + + + + + + + … convert left to double … + + + + + + + done! + + + + + + + Call(slow path) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [260103] trunk/Websites/webkit.org
Title: [260103] trunk/Websites/webkit.org Revision 260103 Author fpi...@apple.com Date 2020-04-14 16:33:03 -0700 (Tue, 14 Apr 2020) Log Message Unreviewed, check in some more files for a blog post. * blog-files/speculation-in-jsc/dfg-pipeline-dark.graffle: Added. * blog-files/speculation-in-jsc/dfg-pipeline-dark.svg: Added. * blog-files/speculation-in-jsc/ftl-pipeline-dark.graffle * blog-files/speculation-in-jsc/ftl-pipeline-dark.svg: Modified Paths trunk/Websites/webkit.org/ChangeLog trunk/Websites/webkit.org/blog-files/speculation-in-jsc/ftl-pipeline-dark.graffle trunk/Websites/webkit.org/blog-files/speculation-in-jsc/ftl-pipeline-dark.svg Added Paths trunk/Websites/webkit.org/blog-files/speculation-in-jsc/dfg-pipeline-dark.graffle trunk/Websites/webkit.org/blog-files/speculation-in-jsc/dfg-pipeline-dark.svg Diff Modified: trunk/Websites/webkit.org/ChangeLog (260102 => 260103) --- trunk/Websites/webkit.org/ChangeLog 2020-04-14 22:35:47 UTC (rev 260102) +++ trunk/Websites/webkit.org/ChangeLog 2020-04-14 23:33:03 UTC (rev 260103) @@ -2,6 +2,15 @@ Unreviewed, check in some more files for a blog post. +* blog-files/speculation-in-jsc/dfg-pipeline-dark.graffle: Added. +* blog-files/speculation-in-jsc/dfg-pipeline-dark.svg: Added. +* blog-files/speculation-in-jsc/ftl-pipeline-dark.graffle +* blog-files/speculation-in-jsc/ftl-pipeline-dark.svg: + +2020-04-14 Filip Pizlo + +Unreviewed, check in some more files for a blog post. + * blog-files/speculation-in-jsc/ftl-pipeline-dark.graffle: Added. * blog-files/speculation-in-jsc/ftl-pipeline-dark.svg: Added. Added: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/dfg-pipeline-dark.graffle (Binary files differ) Index: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/dfg-pipeline-dark.graffle === --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/dfg-pipeline-dark.graffle 2020-04-14 22:35:47 UTC (rev 260102) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/dfg-pipeline-dark.graffle 2020-04-14 23:33:03 UTC (rev 260103) Property changes on: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/dfg-pipeline-dark.graffle ___ Added: svn:mime-type +application/octet-stream \ No newline at end of property Added: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/dfg-pipeline-dark.svg (0 => 260103) --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/dfg-pipeline-dark.svg (rev 0) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/dfg-pipeline-dark.svg 2020-04-14 23:33:03 UTC (rev 260103) @@ -0,0 +1,253 @@ + + + + + + + + + + + + + + + + Produced by OmniGraffle 7.15 +2020-04-14 23:29:45 + + + +Canvas 1 + + + Layer 1 + + + + + Live Catch Variable Preservation + + + + + + + CPS Rethreading + + + + + + + Unification + + + + + + + Prediction Injection + + + + + + + Static Execution Count Estimation + + + + + + + Backwards Propagation + + + + + + + Prediction Propagation + + + + + + + Fixup + + + + + + + InvalidationPoint Injection + + + + + + + Type Check Hoisting + + + + + + + Strength Reduction + + + + + + + CPS Rethreading + + + + + + + Abstract Interpreter + + + + + + + Constant Folding + + + + + + + CFG Simplification + + + + + + + Local Common Subexpression Elimination + + + + + + + CPS Rethreading + + + + + + + Varargs Forwarding + + + + + + + Abstract Interpreter + + + + + + + Constant Folding + + + + + + + Tier Up Check Injection + + + + + + + Fast Store Barrier Insertion + + + + + + + Store
[webkit-changes] [260094] trunk/Websites/webkit.org
Title: [260094] trunk/Websites/webkit.org Revision 260094 Author fpi...@apple.com Date 2020-04-14 13:30:48 -0700 (Tue, 14 Apr 2020) Log Message Unreviewed, check in some more files for a blog post. * blog-files/speculation-in-jsc/ftl-pipeline-dark.graffle: Added. * blog-files/speculation-in-jsc/ftl-pipeline-dark.svg: Added. Modified Paths trunk/Websites/webkit.org/ChangeLog Added Paths trunk/Websites/webkit.org/blog-files/speculation-in-jsc/ftl-pipeline-dark.graffle trunk/Websites/webkit.org/blog-files/speculation-in-jsc/ftl-pipeline-dark.svg Diff Modified: trunk/Websites/webkit.org/ChangeLog (260093 => 260094) --- trunk/Websites/webkit.org/ChangeLog 2020-04-14 20:27:25 UTC (rev 260093) +++ trunk/Websites/webkit.org/ChangeLog 2020-04-14 20:30:48 UTC (rev 260094) @@ -1,3 +1,10 @@ +2020-04-14 Filip Pizlo + +Unreviewed, check in some more files for a blog post. + +* blog-files/speculation-in-jsc/ftl-pipeline-dark.graffle: Added. +* blog-files/speculation-in-jsc/ftl-pipeline-dark.svg: Added. + 2020-04-10 Filip Pizlo Unreviewed, check in some files for a blog post. Added: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/ftl-pipeline-dark.graffle (Binary files differ) Index: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/ftl-pipeline-dark.graffle === --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/ftl-pipeline-dark.graffle 2020-04-14 20:27:25 UTC (rev 260093) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/ftl-pipeline-dark.graffle 2020-04-14 20:30:48 UTC (rev 260094) Property changes on: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/ftl-pipeline-dark.graffle ___ Added: svn:mime-type +application/octet-stream \ No newline at end of property Added: trunk/Websites/webkit.org/blog-files/speculation-in-jsc/ftl-pipeline-dark.svg (0 => 260094) --- trunk/Websites/webkit.org/blog-files/speculation-in-jsc/ftl-pipeline-dark.svg (rev 0) +++ trunk/Websites/webkit.org/blog-files/speculation-in-jsc/ftl-pipeline-dark.svg 2020-04-14 20:30:48 UTC (rev 260094) @@ -0,0 +1,756 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Produced by OmniGraffle 7.15 +2020-04-14 20:28:34 + + + +Canvas 1 + + + Layer 1 + + + + + Live Catch Variable Preservation + + + + + + + CPS Rethreading + + + + + + + Unification + + + + + + + Prediction Injection + + + + + + + Static Execution Count Estimation + + + + + + + Backwards Propagation + + + + + + + Prediction Propagation + + + + + + + Fixup + + + + + + + InvalidationPoint Injection + + + + + + + Type Check Hoisting + + + + + + + Strength Reduction + + + + + + + CPS Rethreading + + + + + + + Abstract Interpreter + + + + + + + Constant Folding + + + + + + + CFG Simplification + + + + + + + Local Common Subexpression Elimination + + + + + + + CPS Rethreading + + + + + + + Abstract Interpreter + + + + + + + Constant Folding + + + + + + + DFG Byte Code Parser (the frontend) + + + + + + + Clean Up + + + + + + + Critical Edge Breaking + + + + + + + Loop Pre Header Creation + + + + + + + CPS Rethreading + + + + + + + SSA Conversion + + + + + + + SSA Lowering + + + + + +
[webkit-changes] [238326] trunk
Title: [238326] trunk
Revision 238326
Author fpi...@apple.com
Date 2018-11-16 16:42:44 -0800 (Fri, 16 Nov 2018)
Log Message
All users of ArrayBuffer should agree on the same max size
https://bugs.webkit.org/show_bug.cgi?id=191771
Reviewed by Mark Lam.
JSTests:
* stress/big-wasm-memory-grow-no-max.js: Added.
(foo):
(catch):
* stress/big-wasm-memory-grow.js: Added.
(foo):
(catch):
* stress/big-wasm-memory.js: Added.
(foo):
(catch):
Source/_javascript_Core:
Array buffers cannot be larger than 0x7fff, because otherwise loading typedArray.length in the DFG/FTL would produce
a uint32 or would require a signedness check, neither of which sounds reasonable. It's better to just bound their max size
instead.
* runtime/ArrayBuffer.cpp:
(JSC::ArrayBufferContents::ArrayBufferContents):
(JSC::ArrayBufferContents::tryAllocate):
(JSC::ArrayBufferContents::transferTo):
(JSC::ArrayBufferContents::copyTo):
(JSC::ArrayBufferContents::shareWith):
* runtime/ArrayBuffer.h:
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::tryCreate):
(JSC::Wasm::Memory::grow):
* wasm/WasmPageCount.h:
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/ArrayBuffer.cpp
trunk/Source/_javascript_Core/runtime/ArrayBuffer.h
trunk/Source/_javascript_Core/wasm/WasmMemory.cpp
trunk/Source/_javascript_Core/wasm/js/WebAssemblyMemoryConstructor.cpp
Added Paths
trunk/JSTests/stress/big-wasm-memory-grow-no-max.js
trunk/JSTests/stress/big-wasm-memory-grow.js
trunk/JSTests/stress/big-wasm-memory.js
Diff
Modified: trunk/JSTests/ChangeLog (238325 => 238326)
--- trunk/JSTests/ChangeLog 2018-11-17 00:31:29 UTC (rev 238325)
+++ trunk/JSTests/ChangeLog 2018-11-17 00:42:44 UTC (rev 238326)
@@ -1,5 +1,22 @@
2018-11-16 Filip Pizlo
+All users of ArrayBuffer should agree on the same max size
+https://bugs.webkit.org/show_bug.cgi?id=191771
+
+Reviewed by Mark Lam.
+
+* stress/big-wasm-memory-grow-no-max.js: Added.
+(foo):
+(catch):
+* stress/big-wasm-memory-grow.js: Added.
+(foo):
+(catch):
+* stress/big-wasm-memory.js: Added.
+(foo):
+(catch):
+
+2018-11-16 Filip Pizlo
+
Unreviewed, make some more tests not crash my computer by only running on instance of it. These tests do not need to
run for each JSC config since they're regression tests for runtime bugs.
Added: trunk/JSTests/stress/big-wasm-memory-grow-no-max.js (0 => 238326)
--- trunk/JSTests/stress/big-wasm-memory-grow-no-max.js (rev 0)
+++ trunk/JSTests/stress/big-wasm-memory-grow-no-max.js 2018-11-17 00:42:44 UTC (rev 238326)
@@ -0,0 +1,33 @@
+let bigArray = new Array(0x700);
+bigArray[0] = 1.1;
+bigArray[1] = 1.2;
+
+function foo(array) {
+var index = array.length;
+if (index >= bigArray.length || (index - 0x1ffdc01) < 0)
+return;
+return bigArray[index - 0x1ffdc01];
+}
+
+noInline(foo);
+
+var okArray = new Uint8Array(0x1ffdc02);
+
+for (var i = 0; i < 1; ++i)
+foo(okArray);
+
+var ok = false;
+try {
+var memory = new WebAssembly.Memory({ initial: 0x1000 });
+memory.grow(0x7000);
+var result = foo(new Uint8Array(memory.buffer));
+if (result !== void 0)
+throw "Error: bad result at end: " + result;
+ok = true;
+} catch (e) {
+if (e.toString() != "RangeError: WebAssembly.Memory.grow expects the grown size to be a valid page count")
+throw e;
+}
+
+if (ok)
+throw "Error: did not throw error";
Added: trunk/JSTests/stress/big-wasm-memory-grow.js (0 => 238326)
--- trunk/JSTests/stress/big-wasm-memory-grow.js (rev 0)
+++ trunk/JSTests/stress/big-wasm-memory-grow.js 2018-11-17 00:42:44 UTC (rev 238326)
@@ -0,0 +1,33 @@
+let bigArray = new Array(0x700);
+bigArray[0] = 1.1;
+bigArray[1] = 1.2;
+
+function foo(array) {
+var index = array.length;
+if (index >= bigArray.length || (index - 0x1ffdc01) < 0)
+return;
+return bigArray[index - 0x1ffdc01];
+}
+
+noInline(foo);
+
+var okArray = new Uint8Array(0x1ffdc02);
+
+for (var i = 0; i < 1; ++i)
+foo(okArray);
+
+var ok = false;
+try {
+var memory = new WebAssembly.Memory({ initial: 0x1000, maximum: 0x8000 });
+memory.grow(0x7000);
+var result = foo(new Uint8Array(memory.buffer));
+if (result !== void 0)
+throw "Error: bad result at end: " + result;
+ok = true;
+} catch (e) {
+if (e.toString() != "RangeError: WebAssembly.Memory.grow expects the grown size to be a valid page count")
+throw e;
+}
+
+if (ok)
+throw "Error: did not throw error";
Added: trunk/JSTests/stress/big-wasm-memory.js (0 => 238326)
--- trunk/JSTests/stress/big-wasm-memory.js (rev 0)
+++ trunk/JSTests/stress/big-wasm-memory.js 2018-11-17 00:42:44 UTC (rev 238326)
@@ -0,0 +1,31 @@
+let bigArray = new Array(0x700);
+bigArray[0] = 1.1;
+bigArray[1] = 1.2;
+
+function fo
[webkit-changes] [238324] trunk/JSTests
Title: [238324] trunk/JSTests
Revision 238324
Author fpi...@apple.com
Date 2018-11-16 16:22:39 -0800 (Fri, 16 Nov 2018)
Log Message
Unreviewed, make some more tests not crash my computer by only running on instance of it. These tests do not need to
run for each JSC config since they're regression tests for runtime bugs.
* stress/json-stringified-overflow-2.js:
* stress/json-stringified-overflow.js:
Modified Paths
trunk/JSTests/ChangeLog
trunk/JSTests/stress/json-stringified-overflow-2.js
trunk/JSTests/stress/json-stringified-overflow.js
Diff
Modified: trunk/JSTests/ChangeLog (238323 => 238324)
--- trunk/JSTests/ChangeLog 2018-11-17 00:17:32 UTC (rev 238323)
+++ trunk/JSTests/ChangeLog 2018-11-17 00:22:39 UTC (rev 238324)
@@ -1,5 +1,13 @@
2018-11-16 Filip Pizlo
+Unreviewed, make some more tests not crash my computer by only running on instance of it. These tests do not need to
+run for each JSC config since they're regression tests for runtime bugs.
+
+* stress/json-stringified-overflow-2.js:
+* stress/json-stringified-overflow.js:
+
+2018-11-16 Filip Pizlo
+
Unreviewed, make some tests not crash my computer by only running on instance of it. These tests do not need to run for each JSC
config since they're regression tests for runtime bugs.
Modified: trunk/JSTests/stress/json-stringified-overflow-2.js (238323 => 238324)
--- trunk/JSTests/stress/json-stringified-overflow-2.js 2018-11-17 00:17:32 UTC (rev 238323)
+++ trunk/JSTests/stress/json-stringified-overflow-2.js 2018-11-17 00:22:39 UTC (rev 238324)
@@ -1,4 +1,4 @@
-//@ skip if $memoryLimited
+//@ if $memoryLimited then skip else runDefault end
try {
const s = "a".padStart(0x8000 - 1);
Modified: trunk/JSTests/stress/json-stringified-overflow.js (238323 => 238324)
--- trunk/JSTests/stress/json-stringified-overflow.js 2018-11-17 00:17:32 UTC (rev 238323)
+++ trunk/JSTests/stress/json-stringified-overflow.js 2018-11-17 00:22:39 UTC (rev 238324)
@@ -1,4 +1,4 @@
-//@ skip if $memoryLimited
+//@ if $memoryLimited then skip else runDefault end
try {
const s = "123".padStart(1073741823);
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [238310] trunk/JSTests
Title: [238310] trunk/JSTests
Revision 238310
Author fpi...@apple.com
Date 2018-11-16 15:17:10 -0800 (Fri, 16 Nov 2018)
Log Message
Unreviewed, make some tests not crash my computer by only running on instance of it. These tests do not need to run for each JSC
config since they're regression tests for runtime bugs.
* stress/large-unshift-splice.js:
* stress/regress-185888.js:
Modified Paths
trunk/JSTests/ChangeLog
trunk/JSTests/stress/large-unshift-splice.js
trunk/JSTests/stress/regress-185888.js
Diff
Modified: trunk/JSTests/ChangeLog (238309 => 238310)
--- trunk/JSTests/ChangeLog 2018-11-16 23:10:12 UTC (rev 238309)
+++ trunk/JSTests/ChangeLog 2018-11-16 23:17:10 UTC (rev 238310)
@@ -1,3 +1,11 @@
+2018-11-16 Filip Pizlo
+
+Unreviewed, make some tests not crash my computer by only running on instance of it. These tests do not need to run for each JSC
+config since they're regression tests for runtime bugs.
+
+* stress/large-unshift-splice.js:
+* stress/regress-185888.js:
+
2018-11-16 Saam Barati
KnownCellUse should also have SpecCellCheck as its type filter
Modified: trunk/JSTests/stress/large-unshift-splice.js (238309 => 238310)
--- trunk/JSTests/stress/large-unshift-splice.js 2018-11-16 23:10:12 UTC (rev 238309)
+++ trunk/JSTests/stress/large-unshift-splice.js 2018-11-16 23:17:10 UTC (rev 238310)
@@ -1,4 +1,4 @@
-//@ skip if $memoryLimited
+//@ if $memoryLimited then skip else runDefault end
function make_contig_arr(sz)
{
Modified: trunk/JSTests/stress/regress-185888.js (238309 => 238310)
--- trunk/JSTests/stress/regress-185888.js 2018-11-16 23:10:12 UTC (rev 238309)
+++ trunk/JSTests/stress/regress-185888.js 2018-11-16 23:17:10 UTC (rev 238310)
@@ -1,4 +1,5 @@
-//@skip if $memoryLimited
+//@ if $memoryLimited then skip else runDefault end
+
var exception;
try {
const str = "a".padStart(0x8000 - 1);
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [234097] trunk/Source/JavaScriptCore
Title: [234097] trunk/Source/_javascript_Core
Revision 234097
Author fpi...@apple.com
Date 2018-07-23 09:13:40 -0700 (Mon, 23 Jul 2018)
Log Message
Unreviewed, fix no-JIT build.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFor):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeUnconditionally):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/InByIdStatus.cpp:
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeForStubInfo):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/CallLinkStatus.cpp
trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp
trunk/Source/_javascript_Core/bytecode/GetByIdStatus.cpp
trunk/Source/_javascript_Core/bytecode/InByIdStatus.cpp
trunk/Source/_javascript_Core/bytecode/PutByIdStatus.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (234096 => 234097)
--- trunk/Source/_javascript_Core/ChangeLog 2018-07-23 14:12:37 UTC (rev 234096)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-07-23 16:13:40 UTC (rev 234097)
@@ -1,3 +1,18 @@
+2018-07-23 Filip Pizlo
+
+Unreviewed, fix no-JIT build.
+
+* bytecode/CallLinkStatus.cpp:
+(JSC::CallLinkStatus::computeFor):
+* bytecode/CodeBlock.cpp:
+(JSC::CodeBlock::finalizeUnconditionally):
+* bytecode/GetByIdStatus.cpp:
+(JSC::GetByIdStatus::computeFor):
+(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
+* bytecode/InByIdStatus.cpp:
+* bytecode/PutByIdStatus.cpp:
+(JSC::PutByIdStatus::computeForStubInfo):
+
2018-07-22 Yusuke Suzuki
[JSC] GetByIdVariant and InByIdVariant do not need slot base if they are not "hit" variants
Modified: trunk/Source/_javascript_Core/bytecode/CallLinkStatus.cpp (234096 => 234097)
--- trunk/Source/_javascript_Core/bytecode/CallLinkStatus.cpp 2018-07-23 14:12:37 UTC (rev 234096)
+++ trunk/Source/_javascript_Core/bytecode/CallLinkStatus.cpp 2018-07-23 16:13:40 UTC (rev 234097)
@@ -85,6 +85,7 @@
UNUSED_PARAM(profiledBlock);
UNUSED_PARAM(bytecodeIndex);
UNUSED_PARAM(map);
+UNUSED_PARAM(exitSiteData);
#if ENABLE(DFG_JIT)
CallLinkInfo* callLinkInfo = map.get(CodeOrigin(bytecodeIndex)).callLinkInfo;
if (!callLinkInfo) {
@@ -263,7 +264,6 @@
result.accountForExits(exitSiteData, inlineKind);
return result;
}
-#endif
void CallLinkStatus::accountForExits(ExitSiteData exitSiteData, ExitingInlineKind inlineKind)
{
@@ -382,6 +382,7 @@
return computeFor(profiledBlock, codeOrigin.bytecodeIndex, baselineMap, exitSiteData);
}
+#endif
void CallLinkStatus::setProvenConstantCallee(CallVariant variant)
{
Modified: trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp (234096 => 234097)
--- trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp 2018-07-23 14:12:37 UTC (rev 234096)
+++ trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp 2018-07-23 16:13:40 UTC (rev 234097)
@@ -1415,10 +1415,12 @@
finalizeBaselineJITInlineCaches();
#endif
+#if ENABLE(DFG_JIT)
if (JITCode::isOptimizingJIT(jitType())) {
DFG::CommonData* dfgCommon = m_jitCode->dfgCommon();
dfgCommon->recordedStatuses.finalize();
}
+#endif // ENABLE(DFG_JIT)
VM::SpaceAndFinalizerSet::finalizerSetFor(*subspace()).remove(this);
}
Modified: trunk/Source/_javascript_Core/bytecode/GetByIdStatus.cpp (234096 => 234097)
--- trunk/Source/_javascript_Core/bytecode/GetByIdStatus.cpp 2018-07-23 14:12:37 UTC (rev 234096)
+++ trunk/Source/_javascript_Core/bytecode/GetByIdStatus.cpp 2018-07-23 16:13:40 UTC (rev 234097)
@@ -110,6 +110,8 @@
return result.slowVersion();
#else
UNUSED_PARAM(map);
+UNUSED_PARAM(didExit);
+UNUSED_PARAM(callExitSiteData);
#endif
if (!result)
@@ -288,7 +290,6 @@
RELEASE_ASSERT_NOT_REACHED();
return GetByIdStatus();
}
-#endif // ENABLE(JIT)
GetByIdStatus GetByIdStatus::computeFor(
CodeBlock* profiledBlock, ICStatusMap& baselineMap,
@@ -375,6 +376,7 @@
return result;
}
+#endif // ENABLE(JIT)
bool GetByIdStatus::makesCalls() const
{
Modified: trunk/Source/_javascript_Core/bytecode/InByIdStatus.cpp (234096 => 234097)
--- trunk/Source/_javascript_Core/bytecode/InByIdStatus.cpp 2018-07-23 14:12:37 UTC (rev 234096)
+++ trunk/Source/_javascript_Core/bytecode/InByIdStatus.cpp 2018-07-23 16:13:40 UTC (rev 234097)
@@ -42,6 +42,7 @@
return appendICStatusVariant(m_variants, variant);
}
+#if ENABLE(JIT)
InByIdStatus InByIdStatus::computeFor(CodeBlock* profiledBlock, ICStatusMap& map, unsigned bytecodeIndex, UniquedStringImpl* uid, ExitFlag didExit)
{
ConcurrentJSLocker locker(profiledBlock->m_lock);
@@ -104,6 +105,7 @@
return computeFor(profiledBlock, baselineMap, codeOrigin.bytecodeIndex, uid, didExit);
}
+#endif // ENABLE(JIT)
#if ENABLE(DFG_JIT)
InByIdStatus InByIdStatus::co
[webkit-changes] [233714] trunk/Source/JavaScriptCore
Title: [233714] trunk/Source/_javascript_Core
Revision 233714
Author fpi...@apple.com
Date 2018-07-10 17:16:07 -0700 (Tue, 10 Jul 2018)
Log Message
Change the reoptimization backoff base to 1.3 from 2
https://bugs.webkit.org/show_bug.cgi?id=187540
Reviewed by Saam Barati.
I have data that hints at this being a speed-up on JetStream, ARES-6, and Speedometer2.
I also have data that hints that a backoff base of 1 might be even better, but I think that
we want to keep *some* backoff in case we find ourselves in an unmitigated recomp loop.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::reoptimizationRetryCounter const):
(JSC::CodeBlock::countReoptimization):
(JSC::CodeBlock::adjustedCounterValue):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp
trunk/Source/_javascript_Core/runtime/Options.cpp
trunk/Source/_javascript_Core/runtime/Options.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (233713 => 233714)
--- trunk/Source/_javascript_Core/ChangeLog 2018-07-11 00:09:11 UTC (rev 233713)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-07-11 00:16:07 UTC (rev 233714)
@@ -1,3 +1,23 @@
+2018-07-10 Filip Pizlo
+
+Change the reoptimization backoff base to 1.3 from 2
+https://bugs.webkit.org/show_bug.cgi?id=187540
+
+Reviewed by Saam Barati.
+
+I have data that hints at this being a speed-up on JetStream, ARES-6, and Speedometer2.
+
+I also have data that hints that a backoff base of 1 might be even better, but I think that
+we want to keep *some* backoff in case we find ourselves in an unmitigated recomp loop.
+
+* bytecode/CodeBlock.cpp:
+(JSC::CodeBlock::reoptimizationRetryCounter const):
+(JSC::CodeBlock::countReoptimization):
+(JSC::CodeBlock::adjustedCounterValue):
+* runtime/Options.cpp:
+(JSC::recomputeDependentOptions):
+* runtime/Options.h:
+
2018-07-10 Mark Lam
[32-bit JSC tests] ASSERTION FAILED: !butterfly->propertyStorage()[-I - 1].get() under JSC::ObjectInitializationScope::verifyPropertiesAreInitialized.
Modified: trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp (233713 => 233714)
--- trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp 2018-07-11 00:09:11 UTC (rev 233713)
+++ trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp 2018-07-11 00:16:07 UTC (rev 233714)
@@ -2136,7 +2136,6 @@
unsigned CodeBlock::reoptimizationRetryCounter() const
{
#if ENABLE(JIT)
-ASSERT(m_reoptimizationRetryCounter <= Options::reoptimizationRetryCounterMax());
return m_reoptimizationRetryCounter;
#else
return 0;
@@ -2174,8 +2173,6 @@
void CodeBlock::countReoptimization()
{
m_reoptimizationRetryCounter++;
-if (m_reoptimizationRetryCounter > Options::reoptimizationRetryCounterMax())
-m_reoptimizationRetryCounter = Options::reoptimizationRetryCounterMax();
}
unsigned CodeBlock::numberOfDFGCompiles()
@@ -2294,7 +2291,7 @@
return clipThreshold(
static_cast(desiredThreshold) *
optimizationThresholdScalingFactor() *
-(1 << reoptimizationRetryCounter()));
+pow(Options::reoptimizationBackoffBase(), reoptimizationRetryCounter()));
}
bool CodeBlock::checkIfOptimizationThresholdReached()
Modified: trunk/Source/_javascript_Core/runtime/Options.cpp (233713 => 233714)
--- trunk/Source/_javascript_Core/runtime/Options.cpp 2018-07-11 00:09:11 UTC (rev 233713)
+++ trunk/Source/_javascript_Core/runtime/Options.cpp 2018-07-11 00:16:07 UTC (rev 233714)
@@ -471,18 +471,6 @@
if (Options::alwaysUseShadowChicken())
Options::maximumInliningDepth() = 1;
-// Compute the maximum value of the reoptimization retry counter. This is simply
-// the largest value at which we don't overflow the execute counter, when using it
-// to left-shift the execution counter by this amount. Currently the value ends
-// up being 18, so this loop is not so terrible; it probably takes up ~100 cycles
-// total on a 32-bit processor.
-Options::reoptimizationRetryCounterMax() = 0;
-while ((static_cast(Options::thresholdForOptimizeAfterLongWarmUp()) << (Options::reoptimizationRetryCounterMax() + 1)) <= static_cast(std::numeric_limits::max()))
-Options::reoptimizationRetryCounterMax()++;
-
-ASSERT((static_cast(Options::thresholdForOptimizeAfterLongWarmUp()) << Options::reoptimizationRetryCounterMax()) > 0);
-ASSERT((static_cast(Options::thresholdForOptimizeAfterLongWarmUp()) << Options::reoptimizationRetryCounterMax()) <= static_cast(std::numeric_limits::max()));
-
#if !defined(NDEBUG)
if (Options::maxSingleAllocationSize())
fastSetMaxSingleAllocationSize(Options::maxSingleAllocationSize());
Modified: trunk/Source/_javascript_Core/runtime/Options.h (233713 => 233714)
--- trunk/Source/_javascript_C
[webkit-changes] [233631] trunk/Tools
Title: [233631] trunk/Tools
Revision 233631
Author fpi...@apple.com
Date 2018-07-08 16:18:47 -0700 (Sun, 08 Jul 2018)
Log Message
run-benchmark should run ARES-6 1.0.1
https://bugs.webkit.org/show_bug.cgi?id=187452
Reviewed by Sam Weinig.
We forgot to update this when we released 1.0.1!
* Scripts/webkitpy/benchmark_runner/data/plans/ares6.plan:
Modified Paths
trunk/Tools/ChangeLog
trunk/Tools/Scripts/webkitpy/benchmark_runner/data/plans/ares6.plan
Diff
Modified: trunk/Tools/ChangeLog (233630 => 233631)
--- trunk/Tools/ChangeLog 2018-07-08 17:59:25 UTC (rev 233630)
+++ trunk/Tools/ChangeLog 2018-07-08 23:18:47 UTC (rev 233631)
@@ -1,3 +1,14 @@
+2018-07-08 Filip Pizlo
+
+run-benchmark should run ARES-6 1.0.1
+https://bugs.webkit.org/show_bug.cgi?id=187452
+
+Reviewed by Sam Weinig.
+
+We forgot to update this when we released 1.0.1!
+
+* Scripts/webkitpy/benchmark_runner/data/plans/ares6.plan:
+
2018-07-07 Youenn Fablet
WPT importer should create dummy HTML files for *.window.js script files
Modified: trunk/Tools/Scripts/webkitpy/benchmark_runner/data/plans/ares6.plan (233630 => 233631)
--- trunk/Tools/Scripts/webkitpy/benchmark_runner/data/plans/ares6.plan 2018-07-08 17:59:25 UTC (rev 233630)
+++ trunk/Tools/Scripts/webkitpy/benchmark_runner/data/plans/ares6.plan 2018-07-08 23:18:47 UTC (rev 233631)
@@ -1,7 +1,7 @@
{
"timeout": 600,
"count": 3,
-"svn_source": "https://svn.webkit.org/repository/webkit/trunk/PerformanceTests/ARES-6/@r216538",
+"svn_source": "https://svn.webkit.org/repository/webkit/trunk/PerformanceTests/ARES-6/@r233406",
"webserver_benchmark_patch": "data/patches/webserver/ARES-6.patch",
"webdriver_benchmark_patch": "data/patches/webdriver/ARES-6.patch",
"entry_point": "index.html",
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [232598] trunk/Source/JavaScriptCore
Title: [232598] trunk/Source/_javascript_Core
Revision 232598
Author fpi...@apple.com
Date 2018-06-07 14:01:19 -0700 (Thu, 07 Jun 2018)
Log Message
FunctionRareData::m_objectAllocationProfileWatchpoint is racy
https://bugs.webkit.org/show_bug.cgi?id=186237
Reviewed by Saam Barati.
We initialize it blind and let it go into auto-watch mode once the DFG adds a watchpoint, but
that means that we never notice that it fired if it fires between when the DFG decides to
watch it and when it actually adds the watchpoint.
Most watchpoints are initialized watched for this purpose. This one had a somewhat good
reason for being initialized blind: that's how we knew to ignore changes to the prototype
before the first allocation. However, that functionality also arose out of the fact that the
rare data is created lazily and usually won't exist until the first allocation.
The fix here is to make the watchpoint go into watched mode as soon as we initialize the
object allocation profile.
It's hard to repro this race, however it started causing spurious test failures for me after
bug 164904.
* runtime/FunctionRareData.cpp:
(JSC::FunctionRareData::FunctionRareData):
(JSC::FunctionRareData::initializeObjectAllocationProfile):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/FunctionRareData.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (232597 => 232598)
--- trunk/Source/_javascript_Core/ChangeLog 2018-06-07 20:45:19 UTC (rev 232597)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-06-07 21:01:19 UTC (rev 232598)
@@ -1,3 +1,29 @@
+2018-06-02 Filip Pizlo
+
+FunctionRareData::m_objectAllocationProfileWatchpoint is racy
+https://bugs.webkit.org/show_bug.cgi?id=186237
+
+Reviewed by Saam Barati.
+
+We initialize it blind and let it go into auto-watch mode once the DFG adds a watchpoint, but
+that means that we never notice that it fired if it fires between when the DFG decides to
+watch it and when it actually adds the watchpoint.
+
+Most watchpoints are initialized watched for this purpose. This one had a somewhat good
+reason for being initialized blind: that's how we knew to ignore changes to the prototype
+before the first allocation. However, that functionality also arose out of the fact that the
+rare data is created lazily and usually won't exist until the first allocation.
+
+The fix here is to make the watchpoint go into watched mode as soon as we initialize the
+object allocation profile.
+
+It's hard to repro this race, however it started causing spurious test failures for me after
+bug 164904.
+
+* runtime/FunctionRareData.cpp:
+(JSC::FunctionRareData::FunctionRareData):
+(JSC::FunctionRareData::initializeObjectAllocationProfile):
+
2018-06-07 Saam Barati
Make DFG to FTL OSR entry code more sane by removing bad RELEASE_ASSERTS and making it trigger compiles in outer loops before inner ones
Modified: trunk/Source/_javascript_Core/runtime/FunctionRareData.cpp (232597 => 232598)
--- trunk/Source/_javascript_Core/runtime/FunctionRareData.cpp 2018-06-07 20:45:19 UTC (rev 232597)
+++ trunk/Source/_javascript_Core/runtime/FunctionRareData.cpp 2018-06-07 21:01:19 UTC (rev 232598)
@@ -64,14 +64,8 @@
: Base(vm, vm.functionRareDataStructure.get())
, m_objectAllocationProfile()
// We initialize blind so that changes to the prototype after function creation but before
-// the optimizer kicks in don't disable optimizations. Once the optimizer kicks in, the
-// watchpoint will start watching and any changes will both force deoptimization and disable
-// future attempts to optimize. This is necessary because we are guaranteed that the
-// allocation profile is changed exactly once prior to optimizations kicking in. We could be
-// smarter and count the number of times the prototype is clobbered and only optimize if it
-// was clobbered exactly once, but that seems like overkill. In almost all cases it will be
-// clobbered once, and if it's clobbered more than once, that will probably only occur
-// before we started optimizing, anyway.
+// the first allocation don't disable optimizations. This isn't super important, since the
+// function is unlikely to allocate a rare data until the first allocation anyway.
, m_objectAllocationProfileWatchpoint(ClearWatchpoint)
{
}
@@ -82,6 +76,9 @@
void FunctionRareData::initializeObjectAllocationProfile(VM& vm, JSGlobalObject* globalObject, JSObject* prototype, size_t inlineCapacity, JSFunction* constructor)
{
+if (m_objectAllocationProfileWatchpoint.isStillValid())
+m_objectAllocationProfileWatchpoint.startWatching();
+
m_objectAllocationProfile.initializeProfile(vm, globalObject, this, prototype, inlineCapacity, constructor, this)
[webkit-changes] [232227] trunk/Source/WTF
Title: [232227] trunk/Source/WTF
Revision 232227
Author fpi...@apple.com
Date 2018-05-26 13:59:04 -0700 (Sat, 26 May 2018)
Log Message
testair sometimes crashes due to races in initialization of ARC4RandomNumberGenerator
https://bugs.webkit.org/show_bug.cgi?id=186014
Reviewed by Yusuke Suzuki.
testair launches a bunch of threads and the threads do B3 things that use random numbers.
Sometimes two threads will initialize the random number generator at the same time, because
that's what happens when you use static NeverDestroyed<>.
This changes that code to use std::call_once to initialize the shared
ARC4RandomNumberGenerator.
Also, this adds a diagnostic message to the lock's assertion. This assertion was the symptom
of the race, and knowing the state of the lock when the assertion fired gave a darn good clue
about what was going on: the lock's value was 0 at time of unlock, implying that another
thread reinitialized the lock to zero by rerunning the constructor.
* wtf/CryptographicallyRandomNumber.cpp:
* wtf/LockAlgorithmInlines.h:
(WTF::Hooks>::unlockSlow):
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/CryptographicallyRandomNumber.cpp
trunk/Source/WTF/wtf/LockAlgorithmInlines.h
Diff
Modified: trunk/Source/WTF/ChangeLog (232226 => 232227)
--- trunk/Source/WTF/ChangeLog 2018-05-26 18:17:09 UTC (rev 232226)
+++ trunk/Source/WTF/ChangeLog 2018-05-26 20:59:04 UTC (rev 232227)
@@ -1,3 +1,26 @@
+2018-05-26 Filip Pizlo
+
+testair sometimes crashes due to races in initialization of ARC4RandomNumberGenerator
+https://bugs.webkit.org/show_bug.cgi?id=186014
+
+Reviewed by Yusuke Suzuki.
+
+testair launches a bunch of threads and the threads do B3 things that use random numbers.
+Sometimes two threads will initialize the random number generator at the same time, because
+that's what happens when you use static NeverDestroyed<>.
+
+This changes that code to use std::call_once to initialize the shared
+ARC4RandomNumberGenerator.
+
+Also, this adds a diagnostic message to the lock's assertion. This assertion was the symptom
+of the race, and knowing the state of the lock when the assertion fired gave a darn good clue
+about what was going on: the lock's value was 0 at time of unlock, implying that another
+thread reinitialized the lock to zero by rerunning the constructor.
+
+* wtf/CryptographicallyRandomNumber.cpp:
+* wtf/LockAlgorithmInlines.h:
+(WTF::Hooks>::unlockSlow):
+
2018-05-25 Michael Saboff
_javascript_Core: Disable 32-bit JIT on Windows
Modified: trunk/Source/WTF/wtf/CryptographicallyRandomNumber.cpp (232226 => 232227)
--- trunk/Source/WTF/wtf/CryptographicallyRandomNumber.cpp 2018-05-26 18:17:09 UTC (rev 232226)
+++ trunk/Source/WTF/wtf/CryptographicallyRandomNumber.cpp 2018-05-26 20:59:04 UTC (rev 232227)
@@ -159,7 +159,13 @@
ARC4RandomNumberGenerator& sharedRandomNumberGenerator()
{
-static NeverDestroyed randomNumberGenerator;
+static LazyNeverDestroyed randomNumberGenerator;
+static std::once_flag onceFlag;
+std::call_once(
+onceFlag,
+[] {
+randomNumberGenerator.construct();
+});
return randomNumberGenerator;
}
Modified: trunk/Source/WTF/wtf/LockAlgorithmInlines.h (232226 => 232227)
--- trunk/Source/WTF/wtf/LockAlgorithmInlines.h 2018-05-26 18:17:09 UTC (rev 232226)
+++ trunk/Source/WTF/wtf/LockAlgorithmInlines.h 2018-05-26 20:59:04 UTC (rev 232227)
@@ -110,9 +110,11 @@
// be held and parked if someone attempts to lock just as we are unlocking.
for (;;) {
uint8_t oldByteValue = lock.load();
-RELEASE_ASSERT(
-(oldByteValue & mask) == isHeldBit
-|| (oldByteValue & mask) == (isHeldBit | hasParkedBit));
+if ((oldByteValue & mask) != isHeldBit
+&& (oldByteValue & mask) != (isHeldBit | hasParkedBit)) {
+dataLog("Invalid value for lock: ", oldByteValue, "\n");
+RELEASE_ASSERT_NOT_REACHED();
+}
if ((oldByteValue & mask) == isHeldBit) {
if (lock.compareExchangeWeak(oldByteValue, Hooks::unlockHook(oldByteValue & ~isHeldBit)))
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [232132] trunk/Source
Title: [232132] trunk/Source Revision 232132 Author fpi...@apple.com Date 2018-05-23 15:34:18 -0700 (Wed, 23 May 2018) Log Message Speed up JetStream/base64 https://bugs.webkit.org/show_bug.cgi?id=185914 Reviewed by Michael Saboff. Source/_javascript_Core: Make allocation fast paths ALWAYS_INLINE. This is a 1% speed-up on SunSpider, mostly because of base64. It also speeds up pdfjs by ~6%. * CMakeLists.txt: * _javascript_Core.xcodeproj/project.pbxproj: * heap/AllocatorInlines.h: (JSC::Allocator::allocate const): * heap/CompleteSubspace.cpp: (JSC::CompleteSubspace::allocateNonVirtual): Deleted. * heap/CompleteSubspace.h: * heap/CompleteSubspaceInlines.h: Added. (JSC::CompleteSubspace::allocateNonVirtual): * heap/FreeListInlines.h: (JSC::FreeList::allocate): * heap/IsoSubspace.cpp: (JSC::IsoSubspace::allocateNonVirtual): Deleted. * heap/IsoSubspace.h: (JSC::IsoSubspace::allocatorForNonVirtual): * heap/IsoSubspaceInlines.h: Added. (JSC::IsoSubspace::allocateNonVirtual): * runtime/JSCellInlines.h: * runtime/VM.h: Source/WTF: Make Vector<>::append ALWAYS_INLINE. * wtf/Vector.h: (WTF::Vector::append): (WTF::minCapacity>::expandCapacity): (WTF::minCapacity>::append): (WTF::minCapacity>::tryAppend): Modified Paths trunk/Source/_javascript_Core/CMakeLists.txt trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj trunk/Source/_javascript_Core/heap/AllocatorInlines.h trunk/Source/_javascript_Core/heap/CompleteSubspace.cpp trunk/Source/_javascript_Core/heap/CompleteSubspace.h trunk/Source/_javascript_Core/heap/FreeListInlines.h trunk/Source/_javascript_Core/heap/IsoSubspace.cpp trunk/Source/_javascript_Core/heap/IsoSubspace.h trunk/Source/_javascript_Core/runtime/JSCellInlines.h trunk/Source/_javascript_Core/runtime/JSString.cpp trunk/Source/_javascript_Core/runtime/VM.h trunk/Source/WTF/ChangeLog trunk/Source/WTF/wtf/Vector.h Added Paths trunk/Source/_javascript_Core/heap/CompleteSubspaceInlines.h trunk/Source/_javascript_Core/heap/IsoSubspaceInlines.h Diff Modified: trunk/Source/_javascript_Core/CMakeLists.txt (232131 => 232132) --- trunk/Source/_javascript_Core/CMakeLists.txt 2018-05-23 22:23:18 UTC (rev 232131) +++ trunk/Source/_javascript_Core/CMakeLists.txt 2018-05-23 22:34:18 UTC (rev 232132) @@ -490,6 +490,7 @@ heap/AlignedMemoryAllocator.h heap/AllocationFailureMode.h heap/Allocator.h +heap/AllocatorInlines.h heap/AllocatorForMode.h heap/BlockDirectory.h heap/BlockDirectoryInlines.h @@ -500,6 +501,7 @@ heap/CollectionScope.h heap/CollectorPhase.h heap/CompleteSubspace.h +heap/CompleteSubspaceInlines.h heap/ConstraintConcurrency.h heap/ConstraintParallelism.h heap/ConstraintVolatility.h @@ -533,10 +535,12 @@ heap/IncrementalSweeper.h heap/IsoCellSet.h heap/IsoSubspace.h +heap/IsoSubspaceInlines.h heap/IsoSubspacePerVM.h heap/LargeAllocation.h heap/ListableHandler.h heap/LocalAllocator.h +heap/LocalAllocatorInlines.h heap/LockDuringMarking.h heap/MachineStackMarker.h heap/MarkStack.h Modified: trunk/Source/_javascript_Core/ChangeLog (232131 => 232132) --- trunk/Source/_javascript_Core/ChangeLog 2018-05-23 22:23:18 UTC (rev 232131) +++ trunk/Source/_javascript_Core/ChangeLog 2018-05-23 22:34:18 UTC (rev 232132) @@ -1,3 +1,35 @@ +2018-05-23 Filip Pizlo + +Speed up JetStream/base64 +https://bugs.webkit.org/show_bug.cgi?id=185914 + +Reviewed by Michael Saboff. + +Make allocation fast paths ALWAYS_INLINE. + +This is a 1% speed-up on SunSpider, mostly because of base64. It also speeds up pdfjs by +~6%. + +* CMakeLists.txt: +* _javascript_Core.xcodeproj/project.pbxproj: +* heap/AllocatorInlines.h: +(JSC::Allocator::allocate const): +* heap/CompleteSubspace.cpp: +(JSC::CompleteSubspace::allocateNonVirtual): Deleted. +* heap/CompleteSubspace.h: +* heap/CompleteSubspaceInlines.h: Added. +(JSC::CompleteSubspace::allocateNonVirtual): +* heap/FreeListInlines.h: +(JSC::FreeList::allocate): +* heap/IsoSubspace.cpp: +(JSC::IsoSubspace::allocateNonVirtual): Deleted. +* heap/IsoSubspace.h: +(JSC::IsoSubspace::allocatorForNonVirtual): +* heap/IsoSubspaceInlines.h: Added. +(JSC::IsoSubspace::allocateNonVirtual): +* runtime/JSCellInlines.h: +* runtime/VM.h: + 2018-05-23 Rick Waldron Conversion misspelled "Convertion" in error message string Modified: trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj (232131 => 232132) --- trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj 2018-05-23 22:23:18 UTC (rev 232131) +++ trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj 2018-05-23 22:34:18 UTC (rev 232132) @@ -39
[webkit-changes] [232074] trunk/Source
Title: [232074] trunk/Source Revision 232074 Author fpi...@apple.com Date 2018-05-22 12:20:05 -0700 (Tue, 22 May 2018) Log Message Get rid of TLCs https://bugs.webkit.org/show_bug.cgi?id=185846 Rubber stamped by Geoffrey Garen. Source/_javascript_Core: This removes support for thread-local caches from the GC in order to speed up allocation a bit. We added TLCs as part of Spectre mitigations, which we have since removed. We will want some kind of TLCs eventually, since they allow us to: - have a global GC, which may be a perf optimization at some point. - allocate objects from JIT threads, which we've been wanting to do for a while. This change keeps the most interesting aspect of TLCs, which is the LocalAllocator/BlockDirectory separation. This means that it ought to be easy to implement TLCs again in the future if we wanted this feature. This change removes the part of TLCs that causes a perf regression, namely that Allocator is an offset that requires a bounds check and lookup that makes the rest of the allocation fast path dependent on the load of the TLC. Now, Allocator is really just a LocalAllocator*, so you can directly use it to allocate. This removes two loads and a check from the allocation fast path. In hindsight, I probably could have made that whole thing more efficient, had I allowed us to have a statically known set of LocalAllocators. This would have removed the bounds check (one load and one branch) and it would have made it possible to CSE the load of the TLC data structure, since that would no longer resize. But that's a harder change that this patch, and we don't need it right now. While reviewing the allocation hot paths, I found that CreateThis had an unnecessary branch to check if the allocator is null. I removed that check. AssemblyHelpers::emitAllocate() does that check already. Previously, the TLC bounds check doubled as this check. This is a 1% speed-up on Octane and a 2.3% speed-up on TailBench. However, the Octane speed-up on my machine includes an 8% regexp speed-up. I've found that sometimes regexp speeds up or slows down by 8% depending on which path I build JSC from. Without that 8%, this is still an Octane speed-up due to 2-4% speed-ups in earley, boyer, raytrace, and splay. * _javascript_Core.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/ObjectAllocationProfileInlines.h: (JSC::ObjectAllocationProfile::initializeProfile): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCreateThis): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject): (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl): (JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell): (JSC::FTL::DFG::LowerDFGToB3::allocateObject): (JSC::FTL::DFG::LowerDFGToB3::allocatorForSize): * heap/Allocator.cpp: (JSC::Allocator::cellSize const): * heap/Allocator.h: (JSC::Allocator::Allocator): (JSC::Allocator::localAllocator const): (JSC::Allocator::operator== const): (JSC::Allocator::offset const): Deleted. * heap/AllocatorInlines.h: (JSC::Allocator::allocate const): (JSC::Allocator::tryAllocate const): Deleted. * heap/BlockDirectory.cpp: (JSC::BlockDirectory::BlockDirectory): (JSC::BlockDirectory::~BlockDirectory): * heap/BlockDirectory.h: (JSC::BlockDirectory::allocator const): Deleted. * heap/CompleteSubspace.cpp: (JSC::CompleteSubspace::allocateNonVirtual): (JSC::CompleteSubspace::allocatorForSlow): (JSC::CompleteSubspace::tryAllocateSlow): * heap/CompleteSubspace.h: * heap/Heap.cpp: (JSC::Heap::Heap): * heap/Heap.h: (JSC::Heap::threadLocalCacheLayout): Deleted. * heap/IsoSubspace.cpp: (JSC::IsoSubspace::IsoSubspace): (JSC::IsoSubspace::allocateNonVirtual): * heap/IsoSubspace.h: (JSC::IsoSubspace::allocatorForNonVirtual): * heap/LocalAllocator.cpp: (JSC::LocalAllocator::LocalAllocator): (JSC::LocalAllocator::~LocalAllocator): * heap/LocalAllocator.h: (JSC::LocalAllocator::cellSize const): (JSC::LocalAllocator::tlc const): Deleted. * heap/ThreadLocalCache.cpp: Removed. * heap/ThreadLocalCache.h: Removed. * heap/ThreadLocalCacheInlines.h: Removed. * heap/ThreadLocalCacheLayout.cpp: Removed. * heap/ThreadLocalCacheLayout.h: Removed. * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator): (JSC::AssemblyHelpers::emitAllocate): (JSC::AssemblyHelpers::emitAllocateVariableSized): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_create_this): * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::~VM): * runtime/VM.h: * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::~VMEntryScope): * runtime/VMEntryScope.h: Source/WTF: * wtf/Platform.h: Modified Paths trunk/Source/_javascript_Core/CMakeLists.txt trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj trunk/Source/_javascript_Core/Sources.txt trunk/Source/_javascript_Co
[webkit-changes] [232008] trunk/Source/JavaScriptCore
Title: [232008] trunk/Source/_javascript_Core
Revision 232008
Author fpi...@apple.com
Date 2018-05-20 17:51:10 -0700 (Sun, 20 May 2018)
Log Message
Revert the B3 compiler pipeline's treatment of taildup
https://bugs.webkit.org/show_bug.cgi?id=185808
Reviewed by Yusuke Suzuki.
While trying to implement path specialization (bug 185060), I reorganized the B3 pass pipeline.
But then path specialization turned out to be a negative result. This reverts the pipeline to the
way it was before that work.
1.5% progression on V8Spider-CompileTime.
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/b3/B3Generate.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (232007 => 232008)
--- trunk/Source/_javascript_Core/ChangeLog 2018-05-20 22:21:02 UTC (rev 232007)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-05-21 00:51:10 UTC (rev 232008)
@@ -1,3 +1,19 @@
+2018-05-20 Filip Pizlo
+
+Revert the B3 compiler pipeline's treatment of taildup
+https://bugs.webkit.org/show_bug.cgi?id=185808
+
+Reviewed by Yusuke Suzuki.
+
+While trying to implement path specialization (bug 185060), I reorganized the B3 pass pipeline.
+But then path specialization turned out to be a negative result. This reverts the pipeline to the
+way it was before that work.
+
+1.5% progression on V8Spider-CompileTime.
+
+* b3/B3Generate.cpp:
+(JSC::B3::generateToAir):
+
2018-05-20 Yusuke Suzuki
[DFG] CheckTypeInfoFlags should say `eliminated` if it is removed in constant folding phase
Modified: trunk/Source/_javascript_Core/b3/B3Generate.cpp (232007 => 232008)
--- trunk/Source/_javascript_Core/b3/B3Generate.cpp 2018-05-20 22:21:02 UTC (rev 232007)
+++ trunk/Source/_javascript_Core/b3/B3Generate.cpp 2018-05-21 00:51:10 UTC (rev 232008)
@@ -88,6 +88,10 @@
if (eliminateCommonSubexpressions(procedure))
eliminateCommonSubexpressions(procedure);
inferSwitches(procedure);
+if (Options::useB3TailDup())
+duplicateTails(procedure);
+fixSSA(procedure);
+foldPathConstants(procedure);
// FIXME: Add more optimizations here.
// https://bugs.webkit.org/show_bug.cgi?id=150507
@@ -101,11 +105,6 @@
if (procedure.optLevel() >= 2) {
reduceStrength(procedure);
-if (Options::useB3TailDup())
-duplicateTails(procedure);
-fixSSA(procedure);
-foldPathConstants(procedure);
-reduceStrength(procedure);
// FIXME: Add more optimizations here.
// https://bugs.webkit.org/show_bug.cgi?id=150507
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [232000] trunk/Source
Title: [232000] trunk/Source Revision 232000 Author fpi...@apple.com Date 2018-05-19 15:00:21 -0700 (Sat, 19 May 2018) Log Message DFG should inline InstanceOf ICs https://bugs.webkit.org/show_bug.cgi?id=185695 Reviewed by Yusuke Suzuki. Source/_javascript_Core: This teaches the DFG how to inline InstanceOf ICs into a MatchStructure node. This can then be folded to a CheckStructure + JSConstant. In the process of testing this, I found a bug where LICM was not hoisting things that depended on ExtraOSREntryLocal because that might return SpecEmpty. I fixed that by teaching LICM how to materialize CheckNotEmpty on demand whenever !HoistingFailed. This is a ~5% speed-up on boyer. ~2x speed-up on the instanceof-always-hit-one, instanceof-always-hit-two, and instanceof-sometimes-hit microbenchmarks. * _javascript_Core.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::appendVariant): (JSC::GetByIdStatus::filter): * bytecode/GetByIdStatus.h: (JSC::GetByIdStatus::operator bool const): (JSC::GetByIdStatus::operator! const): Deleted. * bytecode/GetByIdVariant.h: (JSC::GetByIdVariant::operator bool const): (JSC::GetByIdVariant::operator! const): Deleted. * bytecode/ICStatusUtils.h: Added. (JSC::appendICStatusVariant): (JSC::filterICStatusVariants): * bytecode/InstanceOfStatus.cpp: Added. (JSC::InstanceOfStatus::appendVariant): (JSC::InstanceOfStatus::computeFor): (JSC::InstanceOfStatus::computeForStubInfo): (JSC::InstanceOfStatus::commonPrototype const): (JSC::InstanceOfStatus::filter): * bytecode/InstanceOfStatus.h: Added. (JSC::InstanceOfStatus::InstanceOfStatus): (JSC::InstanceOfStatus::state const): (JSC::InstanceOfStatus::isSet const): (JSC::InstanceOfStatus::operator bool const): (JSC::InstanceOfStatus::isSimple const): (JSC::InstanceOfStatus::takesSlowPath const): (JSC::InstanceOfStatus::numVariants const): (JSC::InstanceOfStatus::variants const): (JSC::InstanceOfStatus::at const): (JSC::InstanceOfStatus::operator[] const): * bytecode/InstanceOfVariant.cpp: Added. (JSC::InstanceOfVariant::InstanceOfVariant): (JSC::InstanceOfVariant::attemptToMerge): (JSC::InstanceOfVariant::dump const): (JSC::InstanceOfVariant::dumpInContext const): * bytecode/InstanceOfVariant.h: Added. (JSC::InstanceOfVariant::InstanceOfVariant): (JSC::InstanceOfVariant::operator bool const): (JSC::InstanceOfVariant::structureSet const): (JSC::InstanceOfVariant::structureSet): (JSC::InstanceOfVariant::conditionSet const): (JSC::InstanceOfVariant::prototype const): (JSC::InstanceOfVariant::isHit const): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::StructureStubInfo): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::considerCaching): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: * dfg/DFGLICMPhase.cpp: (JSC::DFG::LICMPhase::attemptHoist): * dfg/DFGNode.cpp: (JSC::DFG::Node::remove): * dfg/DFGNode.h: (JSC::DFG::Node::hasMatchStructureData): (JSC::DFG::Node::matchStructureData): * dfg/DFGNodeType.h: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileMatchStructure): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileMatchStructure): Source/WTF: I found myself needing a way to represent bottom/false/true/top, so I created it. * WTF.xcodeproj/project.pbxproj: * wtf/BooleanLattice.h: Added. (WTF::lubBooleanLattice): (WTF::printInternal): * wtf/CMakeLists.txt: Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj trunk/Source/_javascript_Core/Sources.txt trunk/Source/_javascript_Core/bytecode/GetByIdStatus.cpp trunk/Source/_javascript_Core/bytecode/GetByIdStatus.h trunk/Source/_javascript_Core/bytecode/GetByIdVariant.h trunk/Source/_javascript_Core/bytecode/StructureStubInfo.cpp trunk/Source/_javascript_Core/bytecode/StructureStubInfo.h trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp trunk/Source/_javascript_Core/dfg/DFGClobberize.h trunk/Source/_javascript_Core/dfg/DFGConstantFoldingPhase.cpp trunk/Source/_javascript_Core/dfg/DFGDoesGC.cpp trunk/Source/_javascript_Core/dfg/DFGFixupPhase.cpp trunk/Source/_javascript_Core/dfg/DFGGraph.cpp trunk/Source/_javasc
[webkit-changes] [231871] trunk
Title: [231871] trunk
Revision 231871
Author fpi...@apple.com
Date 2018-05-16 14:02:49 -0700 (Wed, 16 May 2018)
Log Message
DFG models InstanceOf incorrectly
https://bugs.webkit.org/show_bug.cgi?id=185694
Reviewed by Keith Miller.
JSTests:
* stress/instanceof-proxy-check-structure.js: Added.
(Foo):
(Bar):
(doBadThings):
(getPrototypeOf):
(foo):
(i.new.Bar):
(new.Bar):
* stress/instanceof-proxy-loop.js: Added.
(Foo):
(Bar):
(doBadThings):
(getPrototypeOf):
(foo):
* stress/instanceof-proxy.js: Added.
(Foo):
(Bar):
(doBadThings):
(getPrototypeOf):
(foo):
Source/_javascript_Core:
Proxies mean that InstanceOf can have effects. Exceptions mean that it's illegal to DCE it or
hoist it.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGNodeType.h:
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h
trunk/Source/_javascript_Core/dfg/DFGClobberize.h
trunk/Source/_javascript_Core/dfg/DFGHeapLocation.cpp
trunk/Source/_javascript_Core/dfg/DFGHeapLocation.h
trunk/Source/_javascript_Core/dfg/DFGNodeType.h
Added Paths
trunk/JSTests/stress/instanceof-proxy-check-structure.js
trunk/JSTests/stress/instanceof-proxy-loop.js
trunk/JSTests/stress/instanceof-proxy.js
Diff
Modified: trunk/JSTests/ChangeLog (231870 => 231871)
--- trunk/JSTests/ChangeLog 2018-05-16 20:55:12 UTC (rev 231870)
+++ trunk/JSTests/ChangeLog 2018-05-16 21:02:49 UTC (rev 231871)
@@ -1,3 +1,31 @@
+2018-05-16 Filip Pizlo
+
+DFG models InstanceOf incorrectly
+https://bugs.webkit.org/show_bug.cgi?id=185694
+
+Reviewed by Keith Miller.
+
+* stress/instanceof-proxy-check-structure.js: Added.
+(Foo):
+(Bar):
+(doBadThings):
+(getPrototypeOf):
+(foo):
+(i.new.Bar):
+(new.Bar):
+* stress/instanceof-proxy-loop.js: Added.
+(Foo):
+(Bar):
+(doBadThings):
+(getPrototypeOf):
+(foo):
+* stress/instanceof-proxy.js: Added.
+(Foo):
+(Bar):
+(doBadThings):
+(getPrototypeOf):
+(foo):
+
2018-05-16 Caio Lima
[ESNext][BigInt] Implement support for "/" operation
Added: trunk/JSTests/stress/instanceof-proxy-check-structure.js (0 => 231871)
--- trunk/JSTests/stress/instanceof-proxy-check-structure.js (rev 0)
+++ trunk/JSTests/stress/instanceof-proxy-check-structure.js 2018-05-16 21:02:49 UTC (rev 231871)
@@ -0,0 +1,59 @@
+class Foo { }
+
+function Bar() { }
+
+var numberOfGetPrototypeOfCalls = 0;
+
+var doBadThings = function() { };
+
+Bar.prototype = new Proxy(
+{},
+{
+getPrototypeOf()
+{
+numberOfGetPrototypeOfCalls++;
+doBadThings();
+return Foo.prototype;
+}
+});
+
+// Break some watchpoints.
+var o = {f:42};
+o.g = 43;
+
+function foo(o, p, q)
+{
+var result = o.f;
+var _ = p instanceof Foo;
+q.f = 11;
+return result + o.f;
+}
+
+noInline(foo);
+
+for (var i = 0; i < 1; ++i) {
+var result = foo({f:42}, new Bar(), {f:0});
+if (result != 84)
+throw "Error: bad result in loop: " + result;
+}
+
+if (numberOfGetPrototypeOfCalls != 1)
+throw "Error: did not call getPrototypeOf() the right number of times";
+
+var globalO = {f:42};
+var didCallGetter = false;
+doBadThings = function() {
+delete globalO.f;
+globalO.__defineGetter__("f", function() {
+didCallGetter = true;
+return 43;
+});
+};
+
+var result = foo(globalO, new Bar(), {f:0});
+if (result != 85)
+throw "Error: bad result at end: " + result;
+if (!didCallGetter)
+throw "Error: did not call getter";
+if (numberOfGetPrototypeOfCalls != 10001)
+throw "Error: did not call getPrototypeOf() the right number of times at end";
Added: trunk/JSTests/stress/instanceof-proxy-loop.js (0 => 231871)
--- trunk/JSTests/stress/instanceof-proxy-loop.js (rev 0)
+++ trunk/JSTests/stress/instanceof-proxy-loop.js 2018-05-16 21:02:49 UTC (rev 231871)
@@ -0,0 +1,59 @@
+class Foo { }
+
+function Bar() { }
+
+var numberOfGetPrototypeOfCalls = 0;
+
+var doBadThings = function() { };
+
+Bar.prototype = new Proxy(
+{},
+{
+getPrototypeOf()
+{
+numberOfGetPrototypeOfCalls++;
+doBadThings();
+return Foo.prototype;
+}
+});
+
+// Break some watchpoints.
+var o = {f:42};
+o.g = 43;
+
+function foo(o, p)
+{
+var result = o.f;
+for (var i = 0; i < 5; ++i)
+var _ = p instanceof Foo;
+return result + o.f;
+}
+
+noInline(foo);
+
+for (var i = 0; i < 1; ++i) {
+var result = foo({f:42}, new Bar());
+if (result != 84)
+throw "Error: bad result in loop: " + resu
[webkit-changes] [231743] trunk/Source/WTF
Title: [231743] trunk/Source/WTF Revision 231743 Author fpi...@apple.com Date 2018-05-13 11:57:03 -0700 (Sun, 13 May 2018) Log Message Disable pointer poisoning https://bugs.webkit.org/show_bug.cgi?id=185586 Reviewed by Yusuke Suzuki. This seems like a 0.3% speed-up on microbenchmarks. It seems like it may be a small speed-up on other tests, too. * wtf/Platform.h: Modified Paths trunk/Source/WTF/ChangeLog trunk/Source/WTF/wtf/Platform.h Diff Modified: trunk/Source/WTF/ChangeLog (231742 => 231743) --- trunk/Source/WTF/ChangeLog 2018-05-13 18:16:20 UTC (rev 231742) +++ trunk/Source/WTF/ChangeLog 2018-05-13 18:57:03 UTC (rev 231743) @@ -1,3 +1,15 @@ +2018-05-13 Filip Pizlo + +Disable pointer poisoning +https://bugs.webkit.org/show_bug.cgi?id=185586 + +Reviewed by Yusuke Suzuki. + +This seems like a 0.3% speed-up on microbenchmarks. It seems like it may be a small speed-up on +other tests, too. + +* wtf/Platform.h: + 2018-05-11 Chris Dumez REGRESSION (async policy delegate): Revoking an object URL immediately after triggering download breaks file download Modified: trunk/Source/WTF/wtf/Platform.h (231742 => 231743) --- trunk/Source/WTF/wtf/Platform.h 2018-05-13 18:16:20 UTC (rev 231742) +++ trunk/Source/WTF/wtf/Platform.h 2018-05-13 18:57:03 UTC (rev 231743) @@ -991,12 +991,7 @@ #define ENABLE_SIGNAL_BASED_VM_TRAPS 1 #endif -#define ENABLE_POISON 1 -/* Not currently supported for 32-bit or OS(WINDOWS) builds (because of missing llint support). Make sure it's disabled. */ -#if USE(JSVALUE32_64) || OS(WINDOWS) -#undef ENABLE_POISON #define ENABLE_POISON 0 -#endif #if !defined(USE_POINTER_PROFILING) || USE(JSVALUE32_64) || !ENABLE(JIT) #undef USE_POINTER_PROFILING ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [231741] trunk/Source/JavaScriptCore
Title: [231741] trunk/Source/_javascript_Core
Revision 231741
Author fpi...@apple.com
Date 2018-05-13 09:54:55 -0700 (Sun, 13 May 2018)
Log Message
CachedCall::call() should be faster
https://bugs.webkit.org/show_bug.cgi?id=185583
Reviewed by Yusuke Suzuki.
CachedCall is an optimization for String.prototype.replace(r, f) where f is a function.
Unfortunately, because of a combination of abstraction and assertions, this code path had a
lot of overhead. This patch reduces this overhead by:
- Turning off some assertions. These assertions don't look to have security value; they're
mostly for sanity. I turned off stack alignment checks and VM state checks having to do
with whether the JSLock is held. The JSLock checks are not relevant when doing a cached
call, considering that the caller would have already been strongly assuming that the JSLock
is held.
- Making more things inlineable.
This looks like a small (4% ish) speed-up on SunSpider/string-unpack-code.
* _javascript_Core.xcodeproj/project.pbxproj:
* interpreter/CachedCall.h:
(JSC::CachedCall::call):
* interpreter/Interpreter.cpp:
(JSC::checkedReturn): Deleted.
* interpreter/Interpreter.h:
(JSC::Interpreter::checkedReturn):
* interpreter/InterpreterInlines.h:
(JSC::Interpreter::execute):
* jit/JITCode.cpp:
(JSC::JITCode::execute): Deleted.
* jit/JITCodeInlines.h: Added.
(JSC::JITCode::execute):
* llint/LowLevelInterpreter.asm:
* runtime/StringPrototype.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj
trunk/Source/_javascript_Core/interpreter/CachedCall.h
trunk/Source/_javascript_Core/interpreter/Interpreter.cpp
trunk/Source/_javascript_Core/interpreter/Interpreter.h
trunk/Source/_javascript_Core/interpreter/InterpreterInlines.h
trunk/Source/_javascript_Core/jit/JITCode.cpp
trunk/Source/_javascript_Core/llint/LowLevelInterpreter.asm
trunk/Source/_javascript_Core/runtime/StringPrototype.cpp
Added Paths
trunk/Source/_javascript_Core/jit/JITCodeInlines.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (231740 => 231741)
--- trunk/Source/_javascript_Core/ChangeLog 2018-05-13 14:28:39 UTC (rev 231740)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-05-13 16:54:55 UTC (rev 231741)
@@ -1,3 +1,40 @@
+2018-05-12 Filip Pizlo
+
+CachedCall::call() should be faster
+https://bugs.webkit.org/show_bug.cgi?id=185583
+
+Reviewed by Yusuke Suzuki.
+
+CachedCall is an optimization for String.prototype.replace(r, f) where f is a function.
+Unfortunately, because of a combination of abstraction and assertions, this code path had a
+lot of overhead. This patch reduces this overhead by:
+
+- Turning off some assertions. These assertions don't look to have security value; they're
+ mostly for sanity. I turned off stack alignment checks and VM state checks having to do
+ with whether the JSLock is held. The JSLock checks are not relevant when doing a cached
+ call, considering that the caller would have already been strongly assuming that the JSLock
+ is held.
+
+- Making more things inlineable.
+
+This looks like a small (4% ish) speed-up on SunSpider/string-unpack-code.
+
+* _javascript_Core.xcodeproj/project.pbxproj:
+* interpreter/CachedCall.h:
+(JSC::CachedCall::call):
+* interpreter/Interpreter.cpp:
+(JSC::checkedReturn): Deleted.
+* interpreter/Interpreter.h:
+(JSC::Interpreter::checkedReturn):
+* interpreter/InterpreterInlines.h:
+(JSC::Interpreter::execute):
+* jit/JITCode.cpp:
+(JSC::JITCode::execute): Deleted.
+* jit/JITCodeInlines.h: Added.
+(JSC::JITCode::execute):
+* llint/LowLevelInterpreter.asm:
+* runtime/StringPrototype.cpp:
+
2018-05-13 Andy VanWagoner
[INTL] Improve spec & test262 compliance for Intl APIs
Modified: trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj (231740 => 231741)
--- trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj 2018-05-13 14:28:39 UTC (rev 231740)
+++ trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj 2018-05-13 16:54:55 UTC (rev 231741)
@@ -712,6 +712,7 @@
0FF9CE741B9CD6D0004EDCA6 /* PolymorphicAccess.h in Headers */ = {isa = PBXBuildFile; fileRef = 0FF9CE721B9CD6D0004EDCA6 /* PolymorphicAccess.h */; settings = {ATTRIBUTES = (Private, ); }; };
0FFA549816B8835300B3A982 /* A64DOpcode.h in Headers */ = {isa = PBXBuildFile; fileRef = 652A3A231651C69700A80AFE /* A64DOpcode.h */; settings = {ATTRIBUTES = (Private, ); }; };
0FFB6C391AF48DDC00DB1BF7 /* TypeofType.h in Headers */ = {isa = PBXBuildFile; fileRef = 0FFB6C371AF48DDC00DB1BF7 /* TypeofType.h */; settings = {ATTRIBUTES = (Private, ); }; };
+ 0FFB80BC20A794730006AAF6 /* JITCodeI
[webkit-changes] [231665] trunk/Source/JavaScriptCore
Title: [231665] trunk/Source/_javascript_Core
Revision 231665
Author fpi...@apple.com
Date 2018-05-10 15:23:12 -0700 (Thu, 10 May 2018)
Log Message
DFG CFA should pick the right time to inject OSR entry data
https://bugs.webkit.org/show_bug.cgi?id=185530
Reviewed by Saam Barati.
Previously, we would do a bonus run of CFA to inject OSR entry data. This patch makes us inject
OSR entry data as part of the normal flow of CFA, which reduces the total number of CFA
reexecutions while minimizing the likelihood that we have CFA execute constants in paths that
would eventually LUB to non-constant.
This looks like almost a 1% speed-up on SunSpider-CompileTime. All of the logic for preventing
execution over constants is for V8Spider-CompileTime/regexp, which would otherwise do a lot of
useless regexp/string execution in the compiler.
* dfg/DFGBlockSet.h:
(JSC::DFG::BlockSet::remove):
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::run):
(JSC::DFG::CFAPhase::injectOSR):
(JSC::DFG::CFAPhase::performBlockCFA):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGBlockSet.h
trunk/Source/_javascript_Core/dfg/DFGCFAPhase.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (231664 => 231665)
--- trunk/Source/_javascript_Core/ChangeLog 2018-05-10 22:06:23 UTC (rev 231664)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-05-10 22:23:12 UTC (rev 231665)
@@ -1,3 +1,26 @@
+2018-05-10 Filip Pizlo
+
+DFG CFA should pick the right time to inject OSR entry data
+https://bugs.webkit.org/show_bug.cgi?id=185530
+
+Reviewed by Saam Barati.
+
+Previously, we would do a bonus run of CFA to inject OSR entry data. This patch makes us inject
+OSR entry data as part of the normal flow of CFA, which reduces the total number of CFA
+reexecutions while minimizing the likelihood that we have CFA execute constants in paths that
+would eventually LUB to non-constant.
+
+This looks like almost a 1% speed-up on SunSpider-CompileTime. All of the logic for preventing
+execution over constants is for V8Spider-CompileTime/regexp, which would otherwise do a lot of
+useless regexp/string execution in the compiler.
+
+* dfg/DFGBlockSet.h:
+(JSC::DFG::BlockSet::remove):
+* dfg/DFGCFAPhase.cpp:
+(JSC::DFG::CFAPhase::run):
+(JSC::DFG::CFAPhase::injectOSR):
+(JSC::DFG::CFAPhase::performBlockCFA):
+
2018-05-09 Filip Pizlo
InPlaceAbstractState::beginBasicBlock shouldn't copy all m_variables every time
Modified: trunk/Source/_javascript_Core/dfg/DFGBlockSet.h (231664 => 231665)
--- trunk/Source/_javascript_Core/dfg/DFGBlockSet.h 2018-05-10 22:06:23 UTC (rev 231664)
+++ trunk/Source/_javascript_Core/dfg/DFGBlockSet.h 2018-05-10 22:23:12 UTC (rev 231665)
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2014 Apple Inc. All rights reserved.
+ * Copyright (C) 2014-2018 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -44,6 +44,12 @@
return !m_set.set(block->index);
}
+// Return true if the block was removed, false if it was already absent.
+bool remove(BasicBlock* block)
+{
+return m_set.clear(block->index);
+}
+
bool contains(BasicBlock* block) const
{
if (!block)
Modified: trunk/Source/_javascript_Core/dfg/DFGCFAPhase.cpp (231664 => 231665)
--- trunk/Source/_javascript_Core/dfg/DFGCFAPhase.cpp 2018-05-10 22:06:23 UTC (rev 231664)
+++ trunk/Source/_javascript_Core/dfg/DFGCFAPhase.cpp 2018-05-10 22:23:12 UTC (rev 231665)
@@ -29,6 +29,7 @@
#if ENABLE(DFG_JIT)
#include "DFGAbstractInterpreterInlines.h"
+#include "DFGBlockSet.h"
#include "DFGClobberSet.h"
#include "DFGGraph.h"
#include "DFGInPlaceAbstractState.h"
@@ -75,17 +76,10 @@
m_state.initialize();
-do {
-m_changed = false;
-performForwardCFA();
-} while (m_changed);
-
if (m_graph.m_form != SSA) {
if (m_verbose)
dataLog(" Widening state at OSR entry block.\n");
-ASSERT(!m_changed);
-
// Widen the abstract values at the block that serves as the must-handle OSR entry.
for (BlockIndex blockIndex = m_graph.numBlocks(); blockIndex--;) {
BasicBlock* block = m_graph.block(blockIndex);
@@ -97,41 +91,48 @@
if (block->bytecodeBegin != m_graph.m_plan.osrEntryBytecodeIndex)
continue;
-if (m_verbose)
-dataLog(" Found must-handle block: ", *block, "\n");
-
-bool changed = false;
-for (size_t i = m_graph.m_plan.mustHandleValues.size(); i--;) {
-
[webkit-changes] [231660] trunk/Source/JavaScriptCore
Title: [231660] trunk/Source/_javascript_Core Revision 231660 Author fpi...@apple.com Date 2018-05-10 14:31:49 -0700 (Thu, 10 May 2018) Log Message InPlaceAbstractState::beginBasicBlock shouldn't copy all m_variables every time https://bugs.webkit.org/show_bug.cgi?id=185452 Reviewed by Michael Saboff. We were spending a lot of time in beginBasicBlock() just copying the state of all variables from the block head to InPlaceAbstractState::m_variables. It is necessary for InPlaceAbstractState to have its own copy since we need to mutate it separately from block->valuesAtHead. But most variables are untouched by most basic blocks, so this was a lot of superfluous work. This change adds a bitvector called m_activeVariables that tracks which variables have been copied. We lazily copy the variables on first use. Variables that were never copied also have a simplified merging path, which just needs to consider if the variable got clobbered between head and tail. This is a 1.5% speed-up on SunSpider-CompileTime and a 1.7% speed-up on V8Spider-CompileTime. * bytecode/Operands.h: (JSC::Operands::argumentIndex const): (JSC::Operands::localIndex const): (JSC::Operands::argument): (JSC::Operands::argument const): (JSC::Operands::local): (JSC::Operands::local const): (JSC::Operands::operandIndex const): * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::fastForwardFromTo): * dfg/DFGCFAPhase.cpp: (JSC::DFG::CFAPhase::performForwardCFA): * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::beginBasicBlock): (JSC::DFG::InPlaceAbstractState::variablesForDebugging): (JSC::DFG::InPlaceAbstractState::activateAllVariables): (JSC::DFG::InPlaceAbstractState::endBasicBlock): (JSC::DFG::InPlaceAbstractState::activateVariable): (JSC::DFG::InPlaceAbstractState::mergeStateAtTail): Deleted. * dfg/DFGInPlaceAbstractState.h: (JSC::DFG::InPlaceAbstractState::variableAt): (JSC::DFG::InPlaceAbstractState::operand): (JSC::DFG::InPlaceAbstractState::local): (JSC::DFG::InPlaceAbstractState::argument): (JSC::DFG::InPlaceAbstractState::activateVariableIfNecessary): (JSC::DFG::InPlaceAbstractState::variablesForDebugging): Deleted. Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/bytecode/Operands.h trunk/Source/_javascript_Core/dfg/DFGAbstractValue.h trunk/Source/_javascript_Core/dfg/DFGCFAPhase.cpp trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.cpp trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.h Diff Modified: trunk/Source/_javascript_Core/ChangeLog (231659 => 231660) --- trunk/Source/_javascript_Core/ChangeLog 2018-05-10 20:59:07 UTC (rev 231659) +++ trunk/Source/_javascript_Core/ChangeLog 2018-05-10 21:31:49 UTC (rev 231660) @@ -1,3 +1,50 @@ +2018-05-09 Filip Pizlo + +InPlaceAbstractState::beginBasicBlock shouldn't copy all m_variables every time +https://bugs.webkit.org/show_bug.cgi?id=185452 + +Reviewed by Michael Saboff. + +We were spending a lot of time in beginBasicBlock() just copying the state of all variables +from the block head to InPlaceAbstractState::m_variables. It is necessary for +InPlaceAbstractState to have its own copy since we need to mutate it separately from +block->valuesAtHead. But most variables are untouched by most basic blocks, so this was a lot +of superfluous work. + +This change adds a bitvector called m_activeVariables that tracks which variables have been +copied. We lazily copy the variables on first use. Variables that were never copied also have +a simplified merging path, which just needs to consider if the variable got clobbered between +head and tail. + +This is a 1.5% speed-up on SunSpider-CompileTime and a 1.7% speed-up on V8Spider-CompileTime. + +* bytecode/Operands.h: +(JSC::Operands::argumentIndex const): +(JSC::Operands::localIndex const): +(JSC::Operands::argument): +(JSC::Operands::argument const): +(JSC::Operands::local): +(JSC::Operands::local const): +(JSC::Operands::operandIndex const): +* dfg/DFGAbstractValue.h: +(JSC::DFG::AbstractValue::fastForwardFromTo): +* dfg/DFGCFAPhase.cpp: +(JSC::DFG::CFAPhase::performForwardCFA): +* dfg/DFGInPlaceAbstractState.cpp: +(JSC::DFG::InPlaceAbstractState::beginBasicBlock): +(JSC::DFG::InPlaceAbstractState::variablesForDebugging): +(JSC::DFG::InPlaceAbstractState::activateAllVariables): +(JSC::DFG::InPlaceAbstractState::endBasicBlock): +(JSC::DFG::InPlaceAbstractState::activateVariable): +(JSC::DFG::InPlaceAbstractState::mergeStateAtTail): Deleted. +* dfg/DFGInPlaceAbstractState.h: +(JSC::DFG::InPlaceAbstractState::variableAt): +(JSC::DFG::InPlaceAbstractState::operand): +(JSC::DFG::InPlaceAbstractState::local): +(JSC::DFG:
[webkit-changes] [231607] trunk/Source/JavaScriptCore
Title: [231607] trunk/Source/_javascript_Core Revision 231607 Author fpi...@apple.com Date 2018-05-09 16:31:14 -0700 (Wed, 09 May 2018) Log Message Speed up AbstractInterpreter::executeEdges https://bugs.webkit.org/show_bug.cgi?id=185457 Reviewed by Saam Barati. This patch started out with the desire to make executeEdges() faster by making filtering faster. However, when I studied the disassembly, I found that there are many opportunities for improvement and I implemented all of them: - Filtering itself now has an inline fast path for when the filtering didn't change the value or for non-cells. - Edge execution doesn't fast-forward anything if the filtering fast path would have succeeded, since fast-forwarding is only interesting for cells and only if we have a clobbered value. - Similarly, edge verification doesn't need to fast-forward in the common case. - A bunch of stuff related to Graph::doToChildren is now inlined properly. - The edge doesn't even have to be considered for execution if it's UntypedUse. That last bit was the trickiest. We had gotten into a bad habit of using SpecFullNumber in the abstract interpreter. It's not correct to use SpecFullNumber in the abstract interpreter, because it means proving that the value could either be formatted as a double (with impure NaN values), or as any JSValue, or as an Int52. There is no value that could possibly hold all of those states. This "worked" before because UntypedUse would filter this down to SpecBytecodeNumber. To make it work again, I needed to fix all of those uses of SpecFullNumber. In the future, we need to be careful about picking either SpecFullDouble (if returning a DoubleRep) or SpecBytecodeNumber (if returning a JSValueRep). But that fix revealed an amazing timeout in stress/keep-checks-when-converting-to-lazy-js-constant-in-strength-reduction.js. We were getting stuck in an OSR loop (baseline->DFG->FTL->baseline), all involving the same bytecode, without ever realizing that we should jettison something. The problem was with how triggerReoptimizationNow was getting the optimizedCodeBlock. It was trying to guess it by using baselineCodeBlock->replacement(), but that's wrong for FTL-for-OSR-entry code blocks. This is a 1% improvement in V8Spider-CompileTime. * bytecode/ExitKind.cpp: (JSC::exitKindMayJettison): * dfg/DFGAbstractInterpreter.h: (JSC::DFG::AbstractInterpreter::filterEdgeByUse): (JSC::DFG::AbstractInterpreter::filterByType): Deleted. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreterExecuteEdgesFunc::AbstractInterpreterExecuteEdgesFunc): (JSC::DFG::AbstractInterpreterExecuteEdgesFunc::operator() const): (JSC::DFG::AbstractInterpreter::executeEdges): (JSC::DFG::AbstractInterpreter::filterByType): (JSC::DFG::AbstractInterpreter::verifyEdge): (JSC::DFG::AbstractInterpreter::executeEffects): (JSC::DFG::AbstractInterpreter::executeDoubleUnaryOpEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::filterSlow): (JSC::DFG::AbstractValue::fastForwardToAndFilterSlow): * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::filter): (JSC::DFG::AbstractValue::fastForwardToAndFilter): (JSC::DFG::AbstractValue::fastForwardToAndFilterUnproven): (JSC::DFG::AbstractValue::makeTop): * dfg/DFGAtTailAbstractState.h: (JSC::DFG::AtTailAbstractState::fastForward): (JSC::DFG::AtTailAbstractState::forNodeWithoutFastForward): (JSC::DFG::AtTailAbstractState::fastForwardAndFilterUnproven): * dfg/DFGGraph.h: (JSC::DFG::Graph::doToChildren): * dfg/DFGInPlaceAbstractState.h: (JSC::DFG::InPlaceAbstractState::fastForward): (JSC::DFG::InPlaceAbstractState::fastForwardAndFilterUnproven): (JSC::DFG::InPlaceAbstractState::forNodeWithoutFastForward): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::executeOSRExit): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::handleExitCounts): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/bytecode/ExitKind.cpp trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreter.h trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h trunk/Source/_javascript_Core/dfg/DFGAbstractValue.cpp trunk/Source/_javascript_Core/dfg/DFGAbstractValue.h trunk/Source/_javascript_Core/dfg/DFGAtTailAbstractState.h trunk/Source/_javascript_Core/dfg/DFGGraph.h trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.h trunk/Source/_javascript_Core/dfg/DFGOSRExit.cpp trunk/Source/_javascript_Core/dfg/DFGOSRExitCompilerCommon.cpp trunk/Source/_javascript_Core/dfg/DFGOperations.cpp trunk/Source/_javascript_Core/dfg/DFGOperations.h Diff Modified: trunk/Source/_javascript_Core/ChangeLog (231606 => 231607) --- trunk/Source/_javascript_Core/ChangeLog 2018-05-09 23:15:49 UTC (rev 231606) +++ trunk/Source/_javascript_Core/ChangeLog 2018-05-09 23:31:14 UTC (rev 231607) @@ -1,3 +1,82 @@ +2018-05-09 Filip Pizlo + +Speed up AbstractInterpreter::exec
[webkit-changes] [231522] trunk/Source/JavaScriptCore
Title: [231522] trunk/Source/_javascript_Core
Revision 231522
Author fpi...@apple.com
Date 2018-05-08 16:30:31 -0700 (Tue, 08 May 2018)
Log Message
DFG::FlowMap::resize() shouldn't resize the shadow map unless we're in SSA
https://bugs.webkit.org/show_bug.cgi?id=185453
Reviewed by Michael Saboff.
Tiny improvement for compile times.
* dfg/DFGFlowMap.h:
(JSC::DFG::FlowMap::resize): Remove one Vector::resize() when we're not in SSA.
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::beginBasicBlock): Record some data about how long we spend in different parts of this and add a FIXME linking bug 185452.
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGFlowMap.h
trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (231521 => 231522)
--- trunk/Source/_javascript_Core/ChangeLog 2018-05-08 23:28:05 UTC (rev 231521)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-05-08 23:30:31 UTC (rev 231522)
@@ -1,3 +1,17 @@
+2018-05-08 Filip Pizlo
+
+DFG::FlowMap::resize() shouldn't resize the shadow map unless we're in SSA
+https://bugs.webkit.org/show_bug.cgi?id=185453
+
+Reviewed by Michael Saboff.
+
+Tiny improvement for compile times.
+
+* dfg/DFGFlowMap.h:
+(JSC::DFG::FlowMap::resize): Remove one Vector::resize() when we're not in SSA.
+* dfg/DFGInPlaceAbstractState.cpp:
+(JSC::DFG::InPlaceAbstractState::beginBasicBlock): Record some data about how long we spend in different parts of this and add a FIXME linking bug 185452.
+
2018-05-08 Michael Saboff
Deferred firing of structure transition watchpoints is racy
Modified: trunk/Source/_javascript_Core/dfg/DFGFlowMap.h (231521 => 231522)
--- trunk/Source/_javascript_Core/dfg/DFGFlowMap.h 2018-05-08 23:28:05 UTC (rev 231521)
+++ trunk/Source/_javascript_Core/dfg/DFGFlowMap.h 2018-05-08 23:30:31 UTC (rev 231522)
@@ -50,7 +50,8 @@
void resize()
{
m_map.resize(m_graph.maxNodeCount());
-m_shadowMap.resize(m_graph.maxNodeCount());
+if (m_graph.m_form == SSA)
+m_shadowMap.resize(m_graph.maxNodeCount());
}
Graph& graph() const { return m_graph; }
Modified: trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.cpp (231521 => 231522)
--- trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.cpp 2018-05-08 23:28:05 UTC (rev 231521)
+++ trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.cpp 2018-05-08 23:30:31 UTC (rev 231522)
@@ -34,6 +34,7 @@
#include "JSCInlines.h"
#include "PutByIdStatus.h"
#include "StringObject.h"
+#include "SuperSampler.h"
namespace JSC { namespace DFG {
@@ -53,6 +54,8 @@
void InPlaceAbstractState::beginBasicBlock(BasicBlock* basicBlock)
{
+// This function is ~1.6-2% of execution time.
+
ASSERT(!m_block);
ASSERT(basicBlock->variablesAtHead.numberOfLocals() == basicBlock->valuesAtHead.numberOfLocals());
@@ -59,11 +62,15 @@
ASSERT(basicBlock->variablesAtTail.numberOfLocals() == basicBlock->valuesAtTail.numberOfLocals());
ASSERT(basicBlock->variablesAtHead.numberOfLocals() == basicBlock->variablesAtTail.numberOfLocals());
-m_abstractValues.resize();
+m_abstractValues.resize(); // This part is ~0.1-0.4% of execution time.
AbstractValueClobberEpoch epoch = AbstractValueClobberEpoch::first(basicBlock->cfaStructureClobberStateAtHead);
m_effectEpoch = epoch;
-
+
+// This loop is 0.9-1.2% of execution time.
+// FIXME: Lazily populate m_variables when GetLocal/SetLocal happens. Apply the same idea to
+// merging. Alternatively, we could just use liveness here.
+// https://bugs.webkit.org/show_bug.cgi?id=185452
for (size_t i = m_variables.size(); i--;) {
AbstractValue& value = m_variables[i];
value = basicBlock->valuesAtHead[i];
@@ -71,6 +78,7 @@
}
if (m_graph.m_form == SSA) {
+// This loop is 0.05-0.17% of execution time.
for (NodeAbstractValuePair& entry : basicBlock->ssa->valuesAtHead) {
if (entry.node.isStillValid()) {
AbstractValue& value = m_abstractValues.at(entry.node);
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [231514] trunk
Title: [231514] trunk Revision 231514 Author fpi...@apple.com Date 2018-05-08 14:49:09 -0700 (Tue, 08 May 2018) Log Message InPlaceAbstractState::beginBasicBlock shouldn't have to clear any abstract values https://bugs.webkit.org/show_bug.cgi?id=185365 Reviewed by Saam Barati. Source/_javascript_Core: This patch does three things to improve compile times: - Fixes some inlining goofs. - Adds the ability to measure compile times with run-jsc-benchmarks. - Dramatically improves the performance of InPlaceAbstractState::beginBasicBlock by removing the code that clears abstract values. It turns out that on constant folding "needed" this, in the sense that this was the only thing protecting it from loading the abstract value of a no-result node and then concluding that because it had a non-empty m_value, it could be constant-folded. Any node that produces a result will explicitly set its abstract value, so this problem can also be guarded by just having constant folding check if the node it wants to fold returns any result. Solid 0.96% compile time speed-up across SunSpider-CompileTime and V8Spider-CompileTime. Rolling back in after fixing cloop build. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::set): * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::merge): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGGraph.h: (JSC::DFG::Graph::doToChildrenWithNode): (JSC::DFG::Graph::doToChildren): * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::beginBasicBlock): * jit/JIT.cpp: (JSC::JIT::totalCompileTime): * jit/JIT.h: * jsc.cpp: (GlobalObject::finishCreation): (functionTotalCompileTime): Source/WTF: Fix some inlining goof-ups. Rolling back in after fixing cloop build. * wtf/TinyPtrSet.h: (WTF::TinyPtrSet::add): (WTF::TinyPtrSet::merge): (WTF::TinyPtrSet::addOutOfLine): (WTF::TinyPtrSet::mergeOtherOutOfLine): Tools: Make it possible to measure compile times. Rolling back in after fixing cloop builds. * Scripts/run-jsc-benchmarks: Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h trunk/Source/_javascript_Core/dfg/DFGAbstractValue.cpp trunk/Source/_javascript_Core/dfg/DFGAbstractValue.h trunk/Source/_javascript_Core/dfg/DFGConstantFoldingPhase.cpp trunk/Source/_javascript_Core/dfg/DFGGraph.h trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.cpp trunk/Source/_javascript_Core/jit/JIT.cpp trunk/Source/_javascript_Core/jit/JIT.h trunk/Source/_javascript_Core/jsc.cpp trunk/Source/WTF/ChangeLog trunk/Source/WTF/wtf/TinyPtrSet.h trunk/Tools/ChangeLog trunk/Tools/Scripts/run-jsc-benchmarks Diff Modified: trunk/Source/_javascript_Core/ChangeLog (231513 => 231514) --- trunk/Source/_javascript_Core/ChangeLog 2018-05-08 21:32:03 UTC (rev 231513) +++ trunk/Source/_javascript_Core/ChangeLog 2018-05-08 21:49:09 UTC (rev 231514) @@ -1,3 +1,48 @@ +2018-05-06 Filip Pizlo + +InPlaceAbstractState::beginBasicBlock shouldn't have to clear any abstract values +https://bugs.webkit.org/show_bug.cgi?id=185365 + +Reviewed by Saam Barati. + +This patch does three things to improve compile times: + +- Fixes some inlining goofs. + +- Adds the ability to measure compile times with run-jsc-benchmarks. + +- Dramatically improves the performance of InPlaceAbstractState::beginBasicBlock by removing the + code that clears abstract values. It turns out that on constant folding "needed" this, in the + sense that this was the only thing protecting it from loading the abstract value of a no-result + node and then concluding that because it had a non-empty m_value, it could be constant-folded. + Any node that produces a result will explicitly set its abstract value, so this problem can + also be guarded by just having constant folding check if the node it wants to fold returns any + result. + +Solid 0.96% compile time speed-up across SunSpider-CompileTime and V8Spider-CompileTime. + +Rolling back in after fixing cloop build. + +* dfg/DFGAbstractInterpreterInlines.h: +(JSC::DFG::AbstractInterpreter::executeEffects): +* dfg/DFGAbstractValue.cpp: +(JSC::DFG::AbstractValue::set): +* dfg/DFGAbstractValue.h: +(JSC::DFG::AbstractValue::merge): +* dfg/DFGConstantFoldingPhase.cpp: +(JSC::DFG::ConstantFoldingPhase::foldConstants): +* dfg/DFGGraph.h: +(JSC::DFG::Graph::doToChildrenWithNode): +(JSC::DFG::Graph::doToChildren): +* dfg/DFGInPlaceAbstractState.cpp: +(JSC::DFG::InPlaceAbstractState::beginBasicBlock): +* jit/JIT.cpp: +(JSC::JIT
[webkit-changes] [231468] trunk
Title: [231468] trunk Revision 231468 Author fpi...@apple.com Date 2018-05-07 17:07:20 -0700 (Mon, 07 May 2018) Log Message InPlaceAbstractState::beginBasicBlock shouldn't have to clear any abstract values https://bugs.webkit.org/show_bug.cgi?id=185365 Reviewed by Saam Barati. Source/_javascript_Core: This patch does three things to improve compile times: - Fixes some inlining goofs. - Adds the ability to measure compile times with run-jsc-benchmarks. - Dramatically improves the performance of InPlaceAbstractState::beginBasicBlock by removing the code that clears abstract values. It turns out that on constant folding "needed" this, in the sense that this was the only thing protecting it from loading the abstract value of a no-result node and then concluding that because it had a non-empty m_value, it could be constant-folded. Any node that produces a result will explicitly set its abstract value, so this problem can also be guarded by just having constant folding check if the node it wants to fold returns any result. Solid 0.96% compile time speed-up across SunSpider-CompileTime and V8Spider-CompileTime. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::set): * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::merge): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGGraph.h: (JSC::DFG::Graph::doToChildrenWithNode): (JSC::DFG::Graph::doToChildren): * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::beginBasicBlock): * jit/JIT.cpp: (JSC::JIT::totalCompileTime): * jit/JIT.h: * jsc.cpp: (GlobalObject::finishCreation): (functionTotalCompileTime): Source/WTF: Fix some inlining goof-ups. * wtf/TinyPtrSet.h: (WTF::TinyPtrSet::add): (WTF::TinyPtrSet::merge): (WTF::TinyPtrSet::addOutOfLine): (WTF::TinyPtrSet::mergeOtherOutOfLine): Tools: Make it possible to measure compile times. * Scripts/run-jsc-benchmarks: Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h trunk/Source/_javascript_Core/dfg/DFGAbstractValue.cpp trunk/Source/_javascript_Core/dfg/DFGAbstractValue.h trunk/Source/_javascript_Core/dfg/DFGConstantFoldingPhase.cpp trunk/Source/_javascript_Core/dfg/DFGGraph.h trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.cpp trunk/Source/_javascript_Core/jit/JIT.cpp trunk/Source/_javascript_Core/jit/JIT.h trunk/Source/_javascript_Core/jsc.cpp trunk/Source/WTF/ChangeLog trunk/Source/WTF/wtf/TinyPtrSet.h trunk/Tools/ChangeLog trunk/Tools/Scripts/run-jsc-benchmarks Diff Modified: trunk/Source/_javascript_Core/ChangeLog (231467 => 231468) --- trunk/Source/_javascript_Core/ChangeLog 2018-05-08 00:05:08 UTC (rev 231467) +++ trunk/Source/_javascript_Core/ChangeLog 2018-05-08 00:07:20 UTC (rev 231468) @@ -1,3 +1,46 @@ +2018-05-06 Filip Pizlo + +InPlaceAbstractState::beginBasicBlock shouldn't have to clear any abstract values +https://bugs.webkit.org/show_bug.cgi?id=185365 + +Reviewed by Saam Barati. + +This patch does three things to improve compile times: + +- Fixes some inlining goofs. + +- Adds the ability to measure compile times with run-jsc-benchmarks. + +- Dramatically improves the performance of InPlaceAbstractState::beginBasicBlock by removing the + code that clears abstract values. It turns out that on constant folding "needed" this, in the + sense that this was the only thing protecting it from loading the abstract value of a no-result + node and then concluding that because it had a non-empty m_value, it could be constant-folded. + Any node that produces a result will explicitly set its abstract value, so this problem can + also be guarded by just having constant folding check if the node it wants to fold returns any + result. + +Solid 0.96% compile time speed-up across SunSpider-CompileTime and V8Spider-CompileTime. + +* dfg/DFGAbstractInterpreterInlines.h: +(JSC::DFG::AbstractInterpreter::executeEffects): +* dfg/DFGAbstractValue.cpp: +(JSC::DFG::AbstractValue::set): +* dfg/DFGAbstractValue.h: +(JSC::DFG::AbstractValue::merge): +* dfg/DFGConstantFoldingPhase.cpp: +(JSC::DFG::ConstantFoldingPhase::foldConstants): +* dfg/DFGGraph.h: +(JSC::DFG::Graph::doToChildrenWithNode): +(JSC::DFG::Graph::doToChildren): +* dfg/DFGInPlaceAbstractState.cpp: +(JSC::DFG::InPlaceAbstractState::beginBasicBlock): +* jit/JIT.cpp: +(JSC::JIT::totalCompileTime): +* jit/JIT.h: +* jsc.cpp: +(GlobalObject::finishCreation): +(functionTotalCompileTime): + 2018-05-05 Filip Pizlo DFG AI doesn't need to merge value
[webkit-changes] [231467] trunk/Source/JavaScriptCore
Title: [231467] trunk/Source/_javascript_Core
Revision 231467
Author fpi...@apple.com
Date 2018-05-07 17:05:08 -0700 (Mon, 07 May 2018)
Log Message
DFG AI doesn't need to merge valuesAtTail - it can just assign them
https://bugs.webkit.org/show_bug.cgi?id=185355
Reviewed by Mark Lam.
This is a further attempt to improve compile times. Assigning AbstractValue ought to always
be faster than merging. There's no need to merge valuesAtTail. In most cases, assigning and
merging will get the same answer because the value computed this time will be either the same
as or more general than the value computed last time. If the value does change for some
reason, then valuesAtHead are already merged, which ensures monotonicity. Also, if the value
changes, then we have no reason to believe that this new value is less right than the last
one we computed. Finally, the one client of valuesAtTail (AtTailAbstractState) doesn't care
if it's getting the merged valuesAtTail or just some correct answer for valuesAtTail.
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::endBasicBlock):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (231466 => 231467)
--- trunk/Source/_javascript_Core/ChangeLog 2018-05-07 23:59:37 UTC (rev 231466)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-05-08 00:05:08 UTC (rev 231467)
@@ -1,3 +1,22 @@
+2018-05-05 Filip Pizlo
+
+DFG AI doesn't need to merge valuesAtTail - it can just assign them
+https://bugs.webkit.org/show_bug.cgi?id=185355
+
+Reviewed by Mark Lam.
+
+This is a further attempt to improve compile times. Assigning AbstractValue ought to always
+be faster than merging. There's no need to merge valuesAtTail. In most cases, assigning and
+merging will get the same answer because the value computed this time will be either the same
+as or more general than the value computed last time. If the value does change for some
+reason, then valuesAtHead are already merged, which ensures monotonicity. Also, if the value
+changes, then we have no reason to believe that this new value is less right than the last
+one we computed. Finally, the one client of valuesAtTail (AtTailAbstractState) doesn't care
+if it's getting the merged valuesAtTail or just some correct answer for valuesAtTail.
+
+* dfg/DFGInPlaceAbstractState.cpp:
+(JSC::DFG::InPlaceAbstractState::endBasicBlock):
+
2018-05-07 Andy VanWagoner
Remove defunct email address
Modified: trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.cpp (231466 => 231467)
--- trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.cpp 2018-05-07 23:59:37 UTC (rev 231466)
+++ trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.cpp 2018-05-08 00:05:08 UTC (rev 231467)
@@ -213,13 +213,10 @@
case SSA: {
for (size_t i = 0; i < block->valuesAtTail.size(); ++i)
-block->valuesAtTail[i].merge(m_variables[i]);
+block->valuesAtTail[i] = m_variables[i];
-for (NodeAbstractValuePair& valueAtTail : block->ssa->valuesAtTail) {
-AbstractValue& valueAtNode = forNode(valueAtTail.node);
-valueAtTail.value.merge(valueAtNode);
-valueAtNode = valueAtTail.value;
-}
+for (NodeAbstractValuePair& valueAtTail : block->ssa->valuesAtTail)
+valueAtTail.value = forNode(valueAtTail.node);
break;
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [231399] trunk/Source/JavaScriptCore
Title: [231399] trunk/Source/_javascript_Core
Revision 231399
Author fpi...@apple.com
Date 2018-05-05 18:06:09 -0700 (Sat, 05 May 2018)
Log Message
DFG CFA phase should only do clobber asserts in debug
https://bugs.webkit.org/show_bug.cgi?id=185354
Reviewed by Saam Barati.
Clobber asserts are responsible for 1% of compile time. That's too much. This disables them
unless asserts are enabled.
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::performBlockCFA):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGCFAPhase.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (231398 => 231399)
--- trunk/Source/_javascript_Core/ChangeLog 2018-05-05 23:45:15 UTC (rev 231398)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-05-06 01:06:09 UTC (rev 231399)
@@ -1,3 +1,16 @@
+2018-05-05 Filip Pizlo
+
+DFG CFA phase should only do clobber asserts in debug
+https://bugs.webkit.org/show_bug.cgi?id=185354
+
+Reviewed by Saam Barati.
+
+Clobber asserts are responsible for 1% of compile time. That's too much. This disables them
+unless asserts are enabled.
+
+* dfg/DFGCFAPhase.cpp:
+(JSC::DFG::CFAPhase::performBlockCFA):
+
2018-05-04 Keith Miller
isCacheableArrayLength should return true for undecided arrays
Modified: trunk/Source/_javascript_Core/dfg/DFGCFAPhase.cpp (231398 => 231399)
--- trunk/Source/_javascript_Core/dfg/DFGCFAPhase.cpp 2018-05-05 23:45:15 UTC (rev 231398)
+++ trunk/Source/_javascript_Core/dfg/DFGCFAPhase.cpp 2018-05-06 01:06:09 UTC (rev 231399)
@@ -181,7 +181,8 @@
break;
}
-if (m_state.didClobberOrFolded() != writesOverlap(m_graph, node, JSCell_structureID))
+if (!ASSERT_DISABLED
+&& m_state.didClobberOrFolded() != writesOverlap(m_graph, node, JSCell_structureID))
DFG_CRASH(m_graph, node, toCString("AI-clobberize disagreement; AI says ", m_state.clobberState(), " while clobberize says ", writeSet(m_graph, node)).data());
}
if (m_verbose) {
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [231338] trunk/Source/JavaScriptCore
Title: [231338] trunk/Source/_javascript_Core
Revision 231338
Author fpi...@apple.com
Date 2018-05-03 17:41:58 -0700 (Thu, 03 May 2018)
Log Message
Make it easy to log compile times for all optimizing tiers
https://bugs.webkit.org/show_bug.cgi?id=185270
Reviewed by Keith Miller.
This makes --logPhaseTimes=true enable logging of phase times for DFG and B3 using a common
helper class, CompilerTimingScope. This used to be called B3::TimingScope and only B3 used
it.
This should help us reduce compile times by telling us where to look. So, far, it looks like
CFA is the worst.
* _javascript_Core.xcodeproj/project.pbxproj:
* Sources.txt:
* b3/B3Common.cpp:
(JSC::B3::shouldMeasurePhaseTiming): Deleted.
* b3/B3Common.h:
* b3/B3TimingScope.cpp: Removed.
* b3/B3TimingScope.h:
(JSC::B3::TimingScope::TimingScope):
* dfg/DFGPhase.h:
(JSC::DFG::runAndLog):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThread):
* tools/CompilerTimingScope.cpp: Added.
(JSC::CompilerTimingScope::CompilerTimingScope):
(JSC::CompilerTimingScope::~CompilerTimingScope):
* tools/CompilerTimingScope.h: Added.
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj
trunk/Source/_javascript_Core/Sources.txt
trunk/Source/_javascript_Core/b3/B3Common.cpp
trunk/Source/_javascript_Core/b3/B3Common.h
trunk/Source/_javascript_Core/b3/B3TimingScope.h
trunk/Source/_javascript_Core/dfg/DFGPhase.h
trunk/Source/_javascript_Core/dfg/DFGPlan.cpp
trunk/Source/_javascript_Core/runtime/Options.cpp
trunk/Source/_javascript_Core/runtime/Options.h
Added Paths
trunk/Source/_javascript_Core/tools/CompilerTimingScope.cpp
trunk/Source/_javascript_Core/tools/CompilerTimingScope.h
Removed Paths
trunk/Source/_javascript_Core/b3/B3TimingScope.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (231337 => 231338)
--- trunk/Source/_javascript_Core/ChangeLog 2018-05-04 00:40:18 UTC (rev 231337)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-05-04 00:41:58 UTC (rev 231338)
@@ -1,5 +1,39 @@
2018-05-03 Filip Pizlo
+Make it easy to log compile times for all optimizing tiers
+https://bugs.webkit.org/show_bug.cgi?id=185270
+
+Reviewed by Keith Miller.
+
+This makes --logPhaseTimes=true enable logging of phase times for DFG and B3 using a common
+helper class, CompilerTimingScope. This used to be called B3::TimingScope and only B3 used
+it.
+
+This should help us reduce compile times by telling us where to look. So, far, it looks like
+CFA is the worst.
+
+* _javascript_Core.xcodeproj/project.pbxproj:
+* Sources.txt:
+* b3/B3Common.cpp:
+(JSC::B3::shouldMeasurePhaseTiming): Deleted.
+* b3/B3Common.h:
+* b3/B3TimingScope.cpp: Removed.
+* b3/B3TimingScope.h:
+(JSC::B3::TimingScope::TimingScope):
+* dfg/DFGPhase.h:
+(JSC::DFG::runAndLog):
+* dfg/DFGPlan.cpp:
+(JSC::DFG::Plan::compileInThread):
+* tools/CompilerTimingScope.cpp: Added.
+(JSC::CompilerTimingScope::CompilerTimingScope):
+(JSC::CompilerTimingScope::~CompilerTimingScope):
+* tools/CompilerTimingScope.h: Added.
+* runtime/Options.cpp:
+(JSC::recomputeDependentOptions):
+* runtime/Options.h:
+
+2018-05-03 Filip Pizlo
+
Strings should not be allocated in a gigacage
https://bugs.webkit.org/show_bug.cgi?id=185218
Modified: trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj (231337 => 231338)
--- trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj 2018-05-04 00:40:18 UTC (rev 231337)
+++ trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj 2018-05-04 00:41:58 UTC (rev 231338)
@@ -318,6 +318,7 @@
0F4D8C751FC7A97D001D32AC /* ConstraintParallelism.h in Headers */ = {isa = PBXBuildFile; fileRef = 0F4D8C731FC7A974001D32AC /* ConstraintParallelism.h */; settings = {ATTRIBUTES = (Private, ); }; };
0F4D8C781FCA3CFA001D32AC /* SimpleMarkingConstraint.h in Headers */ = {isa = PBXBuildFile; fileRef = 0F4D8C771FCA3CF3001D32AC /* SimpleMarkingConstraint.h */; settings = {ATTRIBUTES = (Private, ); }; };
0F4DE1CF1C4C1B54004D6C11 /* AirFixObviousSpills.h in Headers */ = {isa = PBXBuildFile; fileRef = 0F4DE1CD1C4C1B54004D6C11 /* AirFixObviousSpills.h */; };
+ 0F4F11E8209BCDAB00709654 /* CompilerTimingScope.h in Headers */ = {isa = PBXBuildFile; fileRef = 0F4F11E6209BCDA100709654 /* CompilerTimingScope.h */; };
0F4F29E018B6AD1C0057BC15 /* DFGStaticExecutionCountEstimationPhase.h in Headers */ = {isa = PBXBuildFile; fileRef = 0F4F29DE18B6AD1C0057BC15 /* DFGStaticExecutionCountEstimationPhase.h */; };
0F4F82881E2FFDE00075184C /* JSSegmentedVariableObjectHeapCellType.h in Headers */ = {isa = PBXBuildFile; fileRef = 0F4
[webkit-changes] [231283] trunk
Title: [231283] trunk
Revision 231283
Author fpi...@apple.com
Date 2018-05-02 17:37:30 -0700 (Wed, 02 May 2018)
Log Message
JSC should know how to cache custom getter accesses on the prototype chain
https://bugs.webkit.org/show_bug.cgi?id=185213
Reviewed by Keith Miller.
JSTests:
* microbenchmarks/get-custom-getter.js: Added.
(test):
Source/_javascript_Core:
This was a simple fix after the work I did for bug 185174. >4x speed-up on the new get-custom-getter.js test.
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/jit/Repatch.cpp
Added Paths
trunk/JSTests/microbenchmarks/get-custom-getter.js
Diff
Modified: trunk/JSTests/ChangeLog (231282 => 231283)
--- trunk/JSTests/ChangeLog 2018-05-03 00:31:50 UTC (rev 231282)
+++ trunk/JSTests/ChangeLog 2018-05-03 00:37:30 UTC (rev 231283)
@@ -1,3 +1,13 @@
+2018-05-02 Filip Pizlo
+
+JSC should know how to cache custom getter accesses on the prototype chain
+https://bugs.webkit.org/show_bug.cgi?id=185213
+
+Reviewed by Keith Miller.
+
+* microbenchmarks/get-custom-getter.js: Added.
+(test):
+
2018-05-02 Robin Morisset
emitCodeToGetArgumentsArrayLength should not crash on PhantomNewArrayWithSpread
Added: trunk/JSTests/microbenchmarks/get-custom-getter.js (0 => 231283)
--- trunk/JSTests/microbenchmarks/get-custom-getter.js (rev 0)
+++ trunk/JSTests/microbenchmarks/get-custom-getter.js 2018-05-03 00:37:30 UTC (rev 231283)
@@ -0,0 +1,21 @@
+// RegExp.input is a handy getter
+
+var o = RegExp;
+o.input = "foo";
+
+function test(o) {
+var result = null;
+for (var i = 0; i < 3; i++)
+result = o.input;
+
+return result;
+}
+
+for (var k = 0; k < 9; k++) {
+var newResult = test(o)
+if (newResult != "foo")
+throw "Failed at " + k + " with " +newResult;
+result = newResult;
+o = {__proto__ : o }
+}
+
Modified: trunk/Source/_javascript_Core/ChangeLog (231282 => 231283)
--- trunk/Source/_javascript_Core/ChangeLog 2018-05-03 00:31:50 UTC (rev 231282)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-05-03 00:37:30 UTC (rev 231283)
@@ -1,3 +1,15 @@
+2018-05-02 Filip Pizlo
+
+JSC should know how to cache custom getter accesses on the prototype chain
+https://bugs.webkit.org/show_bug.cgi?id=185213
+
+Reviewed by Keith Miller.
+
+This was a simple fix after the work I did for bug 185174. >4x speed-up on the new get-custom-getter.js test.
+
+* jit/Repatch.cpp:
+(JSC::tryCacheGetByID):
+
2018-05-01 Filip Pizlo
JSC should be able to cache custom setter calls on the prototype chain
Modified: trunk/Source/_javascript_Core/jit/Repatch.cpp (231282 => 231283)
--- trunk/Source/_javascript_Core/jit/Repatch.cpp 2018-05-03 00:31:50 UTC (rev 231282)
+++ trunk/Source/_javascript_Core/jit/Repatch.cpp 2018-05-03 00:37:30 UTC (rev 231283)
@@ -301,13 +301,19 @@
// We use ObjectPropertyConditionSet instead for faster accesses.
prototypeAccessChain = nullptr;
+// FIXME: Maybe this `if` should be inside generateConditionsForPropertyBlah.
+// https://bugs.webkit.org/show_bug.cgi?id=185215
if (slot.isUnset()) {
conditionSet = generateConditionsForPropertyMiss(
vm, codeBlock, exec, structure, propertyName.impl());
-} else {
+} else if (!slot.isCacheableCustom()) {
conditionSet = generateConditionsForPrototypePropertyHit(
vm, codeBlock, exec, structure, slot.slotBase(),
propertyName.impl());
+} else {
+conditionSet = generateConditionsForPrototypePropertyHitCustom(
+vm, codeBlock, exec, structure, slot.slotBase(),
+propertyName.impl());
}
if (!conditionSet.isValid())
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [231250] trunk/Source/JavaScriptCore
Title: [231250] trunk/Source/_javascript_Core
Revision 231250
Author fpi...@apple.com
Date 2018-05-02 11:51:16 -0700 (Wed, 02 May 2018)
Log Message
JSC should be able to cache custom setter calls on the prototype chain
https://bugs.webkit.org/show_bug.cgi?id=185174
Reviewed by Saam Barati.
We broke custom-setter-on-the-prototype-chain caching when we fixed a bug involving the conditionSet.isEmpty()
condition being used to determine if we have an alternateBase. The fix in r222671 incorrectly tried to add
impossible-to-validate conditions to the conditionSet by calling generateConditionsForPrototypePropertyHit() instead
of generateConditionsForPrototypePropertyHitCustom(). The problem is that the former function will always fail for
custom accessors because it won't find the custom property in the structure.
The fix is to add a virtual hasAlternateBase() function and use that instead of conditionSet.isEmpty().
This is a 4x speed-up on assign-custom-setter.js.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::hasAlternateBase const):
(JSC::AccessCase::alternateBase const):
(JSC::AccessCase::generateImpl):
* bytecode/AccessCase.h:
(JSC::AccessCase::alternateBase const): Deleted.
* bytecode/GetterSetterAccessCase.cpp:
(JSC::GetterSetterAccessCase::hasAlternateBase const):
(JSC::GetterSetterAccessCase::alternateBase const):
* bytecode/GetterSetterAccessCase.h:
* bytecode/ObjectPropertyConditionSet.cpp:
(JSC::generateConditionsForPrototypePropertyHitCustom):
* bytecode/ObjectPropertyConditionSet.h:
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
(JSC::tryCachePutByID):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/AccessCase.cpp
trunk/Source/_javascript_Core/bytecode/AccessCase.h
trunk/Source/_javascript_Core/bytecode/GetterSetterAccessCase.cpp
trunk/Source/_javascript_Core/bytecode/GetterSetterAccessCase.h
trunk/Source/_javascript_Core/bytecode/ObjectPropertyConditionSet.cpp
trunk/Source/_javascript_Core/bytecode/ObjectPropertyConditionSet.h
trunk/Source/_javascript_Core/jit/Repatch.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (231249 => 231250)
--- trunk/Source/_javascript_Core/ChangeLog 2018-05-02 18:44:10 UTC (rev 231249)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-05-02 18:51:16 UTC (rev 231250)
@@ -1,3 +1,37 @@
+2018-05-01 Filip Pizlo
+
+JSC should be able to cache custom setter calls on the prototype chain
+https://bugs.webkit.org/show_bug.cgi?id=185174
+
+Reviewed by Saam Barati.
+
+We broke custom-setter-on-the-prototype-chain caching when we fixed a bug involving the conditionSet.isEmpty()
+condition being used to determine if we have an alternateBase. The fix in r222671 incorrectly tried to add
+impossible-to-validate conditions to the conditionSet by calling generateConditionsForPrototypePropertyHit() instead
+of generateConditionsForPrototypePropertyHitCustom(). The problem is that the former function will always fail for
+custom accessors because it won't find the custom property in the structure.
+
+The fix is to add a virtual hasAlternateBase() function and use that instead of conditionSet.isEmpty().
+
+This is a 4x speed-up on assign-custom-setter.js.
+
+* bytecode/AccessCase.cpp:
+(JSC::AccessCase::hasAlternateBase const):
+(JSC::AccessCase::alternateBase const):
+(JSC::AccessCase::generateImpl):
+* bytecode/AccessCase.h:
+(JSC::AccessCase::alternateBase const): Deleted.
+* bytecode/GetterSetterAccessCase.cpp:
+(JSC::GetterSetterAccessCase::hasAlternateBase const):
+(JSC::GetterSetterAccessCase::alternateBase const):
+* bytecode/GetterSetterAccessCase.h:
+* bytecode/ObjectPropertyConditionSet.cpp:
+(JSC::generateConditionsForPrototypePropertyHitCustom):
+* bytecode/ObjectPropertyConditionSet.h:
+* jit/Repatch.cpp:
+(JSC::tryCacheGetByID):
+(JSC::tryCachePutByID):
+
2018-05-02 Dominik Infuehr
[MIPS] Implement and16 and store16 for MacroAssemblerMIPS
Modified: trunk/Source/_javascript_Core/bytecode/AccessCase.cpp (231249 => 231250)
--- trunk/Source/_javascript_Core/bytecode/AccessCase.cpp 2018-05-02 18:44:10 UTC (rev 231249)
+++ trunk/Source/_javascript_Core/bytecode/AccessCase.cpp 2018-05-02 18:51:16 UTC (rev 231250)
@@ -121,6 +121,16 @@
}
}
+bool AccessCase::hasAlternateBase() const
+{
+return !conditionSet().isEmpty();
+}
+
+JSObject* AccessCase::alternateBase() const
+{
+return conditionSet().slotBaseCondition().object();
+}
+
std::unique_ptr AccessCase::clone() const
{
std::unique_ptr result(new AccessCase(*this));
@@ -572,10 +582,10 @@
if (isValidOffset(m_offset)) {
Structure* currStructure;
-if (m_conditionSet.isEmpty())
+if (!hasAlternateBase())
currStructure = structure();
else
-
[webkit-changes] [231204] trunk/Source/JavaScriptCore
Title: [231204] trunk/Source/_javascript_Core Revision 231204 Author fpi...@apple.com Date 2018-05-01 12:55:59 -0700 (Tue, 01 May 2018) Log Message B3::demoteValues should be able to handle patchpoint terminals https://bugs.webkit.org/show_bug.cgi?id=185151 Reviewed by Saam Barati. If we try to demote a patchpoint terminal then prior to this change we would append a Set to the basic block that the patchpoint terminated. That's wrong because then the terminal is no longer the last thing in the block. Air encounters this problem in spilling and solves it by doing a fixup afterwards. We can't really do that because demotion happens as a prerequisite to other transformations. One solution might have been to make demoteValues insert a basic block whenever it encounters this problem. But that would break clients that do CFG analysis before demoteValues and use the results of the CFG analysis after demoteValues. Taildup does this. Fortunately, taildup also runs breakCriticalEdges. Probably anyone using demoteValues will use breakCriticalEdges, so it's not bad to introduce that requirement. So, this patch solves the problem by ensuring that breakCriticalEdges treats any patchpoint terminal as if it had multiple successors. This means that a patchpoint terminal's successors will only have it as their predecessor. Then, demoteValues just prepends the Set to the successors of the patchpoint terminal. This was probably asymptomatic. It's hard to write a JS test that triggers this, so I added a unit test in testb3. * b3/B3BreakCriticalEdges.cpp: (JSC::B3::breakCriticalEdges): * b3/B3BreakCriticalEdges.h: * b3/B3FixSSA.cpp: (JSC::B3::demoteValues): (JSC::B3::fixSSA): * b3/B3FixSSA.h: * b3/B3Value.cpp: (JSC::B3::Value::foldIdentity const): (JSC::B3::Value::performSubstitution): * b3/B3Value.h: * b3/testb3.cpp: (JSC::B3::testDemotePatchpointTerminal): (JSC::B3::run): Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/b3/B3BreakCriticalEdges.cpp trunk/Source/_javascript_Core/b3/B3BreakCriticalEdges.h trunk/Source/_javascript_Core/b3/B3FixSSA.cpp trunk/Source/_javascript_Core/b3/B3FixSSA.h trunk/Source/_javascript_Core/b3/B3Value.cpp trunk/Source/_javascript_Core/b3/B3Value.h trunk/Source/_javascript_Core/b3/testb3.cpp Diff Modified: trunk/Source/_javascript_Core/ChangeLog (231203 => 231204) --- trunk/Source/_javascript_Core/ChangeLog 2018-05-01 19:45:34 UTC (rev 231203) +++ trunk/Source/_javascript_Core/ChangeLog 2018-05-01 19:55:59 UTC (rev 231204) @@ -1,3 +1,46 @@ +2018-04-30 Filip Pizlo + +B3::demoteValues should be able to handle patchpoint terminals +https://bugs.webkit.org/show_bug.cgi?id=185151 + +Reviewed by Saam Barati. + +If we try to demote a patchpoint terminal then prior to this change we would append a Set to +the basic block that the patchpoint terminated. That's wrong because then the terminal is no +longer the last thing in the block. + +Air encounters this problem in spilling and solves it by doing a fixup afterwards. We can't +really do that because demotion happens as a prerequisite to other transformations. + +One solution might have been to make demoteValues insert a basic block whenever it encounters +this problem. But that would break clients that do CFG analysis before demoteValues and use +the results of the CFG analysis after demoteValues. Taildup does this. Fortunately, taildup +also runs breakCriticalEdges. Probably anyone using demoteValues will use breakCriticalEdges, +so it's not bad to introduce that requirement. + +So, this patch solves the problem by ensuring that breakCriticalEdges treats any patchpoint +terminal as if it had multiple successors. This means that a patchpoint terminal's successors +will only have it as their predecessor. Then, demoteValues just prepends the Set to the +successors of the patchpoint terminal. + +This was probably asymptomatic. It's hard to write a JS test that triggers this, so I added +a unit test in testb3. + +* b3/B3BreakCriticalEdges.cpp: +(JSC::B3::breakCriticalEdges): +* b3/B3BreakCriticalEdges.h: +* b3/B3FixSSA.cpp: +(JSC::B3::demoteValues): +(JSC::B3::fixSSA): +* b3/B3FixSSA.h: +* b3/B3Value.cpp: +(JSC::B3::Value::foldIdentity const): +(JSC::B3::Value::performSubstitution): +* b3/B3Value.h: +* b3/testb3.cpp: +(JSC::B3::testDemotePatchpointTerminal): +(JSC::B3::run): + 2018-05-01 Robin Morisset Use CheckedArithmetic for length computation in JSArray::unshiftCountWithAnyIndexingType Modified: trunk/Source/_javascript_Core/b3/B3BreakCriticalEdges.cpp (231203 => 231204) --- trunk/Source/_javascript_Core/b3/B3BreakCriticalEdges.cpp 2018-0
[webkit-changes] [231185] trunk
Title: [231185] trunk
Revision 231185
Author fpi...@apple.com
Date 2018-04-30 17:04:44 -0700 (Mon, 30 Apr 2018)
Log Message
LICM shouldn't hoist nodes if hoisted nodes exited in that code block
https://bugs.webkit.org/show_bug.cgi?id=185126
Reviewed by Saam Barati.
JSTests:
I found this bug by accident when I was writing this test for something else.
This change also speeds up other benchmarks of this case that we already had. They are all called
the licm-dragons tests.
* microbenchmarks/licm-dragons-two-structures.js: Added.
(foo):
Source/_javascript_Core:
This change is just restoring functionality that we've already had for a while. It had been
accidentally broken due to an unrelated CodeBlock refactoring.
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::attemptHoist):
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGLICMPhase.cpp
Added Paths
trunk/JSTests/microbenchmarks/licm-dragons-two-structures.js
Diff
Modified: trunk/JSTests/ChangeLog (231184 => 231185)
--- trunk/JSTests/ChangeLog 2018-05-01 00:03:33 UTC (rev 231184)
+++ trunk/JSTests/ChangeLog 2018-05-01 00:04:44 UTC (rev 231185)
@@ -1,3 +1,18 @@
+2018-04-29 Filip Pizlo
+
+LICM shouldn't hoist nodes if hoisted nodes exited in that code block
+https://bugs.webkit.org/show_bug.cgi?id=185126
+
+Reviewed by Saam Barati.
+
+I found this bug by accident when I was writing this test for something else.
+
+This change also speeds up other benchmarks of this case that we already had. They are all called
+the licm-dragons tests.
+
+* microbenchmarks/licm-dragons-two-structures.js: Added.
+(foo):
+
2018-04-29 Commit Queue
Unreviewed, rolling out r231137.
Added: trunk/JSTests/microbenchmarks/licm-dragons-two-structures.js (0 => 231185)
--- trunk/JSTests/microbenchmarks/licm-dragons-two-structures.js (rev 0)
+++ trunk/JSTests/microbenchmarks/licm-dragons-two-structures.js 2018-05-01 00:04:44 UTC (rev 231185)
@@ -0,0 +1,24 @@
+function foo(o)
+{
+var result = 0;
+for (var i = 0; i < 100; ++i) {
+if (o.p)
+result += o.f;
+else
+result += o.g;
+if (o.p)
+o.f = i;
+else
+o.g = i;
+}
+return result;
+}
+
+noInline(foo);
+
+for (var i = 0; i < 10; ++i) {
+var result = foo(i & 1 ? {p:true, f:42} : {p:false, g:42});
+if (result != (99 * 98) / 2 + 42)
+throw "Error: bad result: " + result;
+}
+
Modified: trunk/Source/_javascript_Core/ChangeLog (231184 => 231185)
--- trunk/Source/_javascript_Core/ChangeLog 2018-05-01 00:03:33 UTC (rev 231184)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-05-01 00:04:44 UTC (rev 231185)
@@ -1,3 +1,16 @@
+2018-04-29 Filip Pizlo
+
+LICM shouldn't hoist nodes if hoisted nodes exited in that code block
+https://bugs.webkit.org/show_bug.cgi?id=185126
+
+Reviewed by Saam Barati.
+
+This change is just restoring functionality that we've already had for a while. It had been
+accidentally broken due to an unrelated CodeBlock refactoring.
+
+* dfg/DFGLICMPhase.cpp:
+(JSC::DFG::LICMPhase::attemptHoist):
+
2018-04-30 Mark Lam
Apply PtrTags to the MetaAllocator and friends.
Modified: trunk/Source/_javascript_Core/dfg/DFGLICMPhase.cpp (231184 => 231185)
--- trunk/Source/_javascript_Core/dfg/DFGLICMPhase.cpp 2018-05-01 00:03:33 UTC (rev 231184)
+++ trunk/Source/_javascript_Core/dfg/DFGLICMPhase.cpp 2018-05-01 00:04:44 UTC (rev 231185)
@@ -281,7 +281,7 @@
&& !m_graph.m_controlEquivalenceAnalysis->dominatesEquivalently(data.preHeader, fromBlock);
if (addsBlindSpeculation
-&& m_graph.hasExitSite(originalOrigin.semantic, HoistingFailed)) {
+&& m_graph.hasGlobalExitSite(originalOrigin.semantic, HoistingFailed)) {
if (verbose) {
dataLog(
"Not hoisting ", node, " because it may exit and the pre-header (",
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [231154] trunk/Source/JavaScriptCore
Title: [231154] trunk/Source/_javascript_Core
Revision 231154
Author fpi...@apple.com
Date 2018-04-29 16:41:55 -0700 (Sun, 29 Apr 2018)
Log Message
B3 should run tail duplication at the bitter end
https://bugs.webkit.org/show_bug.cgi?id=185123
Reviewed by Geoffrey Garen.
Also added an option to disable taildup. This appears to be a 1% AsmBench speed-up. It's neutral
everywhere else.
The goal of this change is to allow us to run path specialization after switch lowering but
before tail duplication.
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* runtime/Options.h:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/b3/B3Generate.cpp
trunk/Source/_javascript_Core/runtime/Options.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (231153 => 231154)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-29 17:30:35 UTC (rev 231153)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-29 23:41:55 UTC (rev 231154)
@@ -1,3 +1,20 @@
+2018-04-29 Filip Pizlo
+
+B3 should run tail duplication at the bitter end
+https://bugs.webkit.org/show_bug.cgi?id=185123
+
+Reviewed by Geoffrey Garen.
+
+Also added an option to disable taildup. This appears to be a 1% AsmBench speed-up. It's neutral
+everywhere else.
+
+The goal of this change is to allow us to run path specialization after switch lowering but
+before tail duplication.
+
+* b3/B3Generate.cpp:
+(JSC::B3::generateToAir):
+* runtime/Options.h:
+
2018-04-29 Commit Queue
Unreviewed, rolling out r231137.
Modified: trunk/Source/_javascript_Core/b3/B3Generate.cpp (231153 => 231154)
--- trunk/Source/_javascript_Core/b3/B3Generate.cpp 2018-04-29 17:30:35 UTC (rev 231153)
+++ trunk/Source/_javascript_Core/b3/B3Generate.cpp 2018-04-29 23:41:55 UTC (rev 231154)
@@ -80,7 +80,7 @@
if (shouldValidateIR())
validate(procedure);
-
+
if (procedure.optLevel() >= 2) {
reduceDoubleToFloat(procedure);
reduceStrength(procedure);
@@ -87,12 +87,7 @@
hoistLoopInvariantValues(procedure);
if (eliminateCommonSubexpressions(procedure))
eliminateCommonSubexpressions(procedure);
-foldPathConstants(procedure);
-reduceStrength(procedure);
inferSwitches(procedure);
-duplicateTails(procedure);
-fixSSA(procedure);
-foldPathConstants(procedure);
// FIXME: Add more optimizations here.
// https://bugs.webkit.org/show_bug.cgi?id=150507
@@ -106,6 +101,11 @@
if (procedure.optLevel() >= 2) {
reduceStrength(procedure);
+if (Options::useB3TailDup())
+duplicateTails(procedure);
+fixSSA(procedure);
+foldPathConstants(procedure);
+reduceStrength(procedure);
// FIXME: Add more optimizations here.
// https://bugs.webkit.org/show_bug.cgi?id=150507
Modified: trunk/Source/_javascript_Core/runtime/Options.h (231153 => 231154)
--- trunk/Source/_javascript_Core/runtime/Options.h 2018-04-29 17:30:35 UTC (rev 231153)
+++ trunk/Source/_javascript_Core/runtime/Options.h 2018-04-29 23:41:55 UTC (rev 231154)
@@ -437,6 +437,7 @@
v(bool, airRandomizeRegs, false, Normal, nullptr) \
v(bool, coalesceSpillSlots, true, Normal, nullptr) \
v(bool, logAirRegisterPressure, false, Normal, nullptr) \
+v(bool, useB3TailDup, true, Normal, nullptr) \
v(unsigned, maxB3TailDupBlockSize, 3, Normal, nullptr) \
v(unsigned, maxB3TailDupBlockSuccessors, 3, Normal, nullptr) \
\
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [231116] trunk/Source/JavaScriptCore
Title: [231116] trunk/Source/_javascript_Core Revision 231116 Author fpi...@apple.com Date 2018-04-27 16:43:30 -0700 (Fri, 27 Apr 2018) Log Message Also run foldPathConstants before mussing up SSA https://bugs.webkit.org/show_bug.cgi?id=185069 Reviewed by Saam Barati. This isn't needed now, but will be once I implement the phase in bug 185060. This could be a speed-up, or a slow-down, independent of that phase. Most likely it's neutral. Local testing seems to suggest that it's neutral. Anyway, whatever it ends up being, I want it to be landed separately and measured separately from that phase. It's probably nice for sanity to have this and reduceStrength run before tail duplication and another round of reduceStrength, since that make for something that is closer to a fixpoint. But it will increase FTL compile times. So, there's no way to guess if this change is good, bad, or neutral. It all depends on what programs typically look like. * b3/B3Generate.cpp: (JSC::B3::generateToAir): Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/b3/B3Generate.cpp Diff Modified: trunk/Source/_javascript_Core/ChangeLog (231115 => 231116) --- trunk/Source/_javascript_Core/ChangeLog 2018-04-27 22:30:43 UTC (rev 231115) +++ trunk/Source/_javascript_Core/ChangeLog 2018-04-27 23:43:30 UTC (rev 231116) @@ -1,3 +1,24 @@ +2018-04-26 Filip Pizlo + +Also run foldPathConstants before mussing up SSA +https://bugs.webkit.org/show_bug.cgi?id=185069 + +Reviewed by Saam Barati. + +This isn't needed now, but will be once I implement the phase in bug 185060. + +This could be a speed-up, or a slow-down, independent of that phase. Most likely it's neutral. +Local testing seems to suggest that it's neutral. Anyway, whatever it ends up being, I want it to +be landed separately and measured separately from that phase. + +It's probably nice for sanity to have this and reduceStrength run before tail duplication and +another round of reduceStrength, since that make for something that is closer to a fixpoint. But +it will increase FTL compile times. So, there's no way to guess if this change is good, bad, or +neutral. It all depends on what programs typically look like. + +* b3/B3Generate.cpp: +(JSC::B3::generateToAir): + 2018-04-27 Ryan Haddad Unreviewed, rolling out r231086. Modified: trunk/Source/_javascript_Core/b3/B3Generate.cpp (231115 => 231116) --- trunk/Source/_javascript_Core/b3/B3Generate.cpp 2018-04-27 22:30:43 UTC (rev 231115) +++ trunk/Source/_javascript_Core/b3/B3Generate.cpp 2018-04-27 23:43:30 UTC (rev 231116) @@ -1,5 +1,5 @@ /* - * Copyright (C) 2015-2017 Apple Inc. All rights reserved. + * Copyright (C) 2015-2018 Apple Inc. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions @@ -87,6 +87,8 @@ hoistLoopInvariantValues(procedure); if (eliminateCommonSubexpressions(procedure)) eliminateCommonSubexpressions(procedure); +foldPathConstants(procedure); +reduceStrength(procedure); inferSwitches(procedure); duplicateTails(procedure); fixSSA(procedure); ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [230975] trunk/Source/JavaScriptCore
Title: [230975] trunk/Source/_javascript_Core
Revision 230975
Author fpi...@apple.com
Date 2018-04-24 15:29:39 -0700 (Tue, 24 Apr 2018)
Log Message
MultiByOffset should emit one fewer branches in the case that the set of structures is proved already
https://bugs.webkit.org/show_bug.cgi?id=184923
Reviewed by Saam Barati.
If we have a MultiGetByOffset or MultiPutByOffset over a structure set that we've already proved
(i.e. we know that the object has one of those structures), then previously we would still emit a
switch with a case per structure along with a default case. That would mean one extra redundant
branch to check that whatever structure we wound up with belongs to the set. In that case, we
were already making the default case be an Oops.
One possible solution would be to say that the default case being Oops means that B3 doesn't need
to emit the extra branch. But that would require having B3 exploit the fact that Oops is known to
be unreachable. Although B3 IR semantics (webkit.org/docs/b3/intermediate-representation.html)
seem to allow this, I don't particularly like that style of optimization. I like Oops to mean
trap.
So, this patch makes FTL lowering turn one of the cases into the default, explicitly removing the
extra branch.
This is not a speed-up. But it makes the B3 IR for MultiByOffset a lot simpler, which should make
it easier to implement B3-level optimizations for MultiByOffset. It also makes the IR easier to
read.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
(JSC::FTL::DFG::LowerDFGToB3::emitSwitchForMultiByOffset):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (230974 => 230975)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-24 22:11:53 UTC (rev 230974)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-24 22:29:39 UTC (rev 230975)
@@ -1,5 +1,36 @@
2018-04-24 Filip Pizlo
+MultiByOffset should emit one fewer branches in the case that the set of structures is proved already
+https://bugs.webkit.org/show_bug.cgi?id=184923
+
+Reviewed by Saam Barati.
+
+If we have a MultiGetByOffset or MultiPutByOffset over a structure set that we've already proved
+(i.e. we know that the object has one of those structures), then previously we would still emit a
+switch with a case per structure along with a default case. That would mean one extra redundant
+branch to check that whatever structure we wound up with belongs to the set. In that case, we
+were already making the default case be an Oops.
+
+One possible solution would be to say that the default case being Oops means that B3 doesn't need
+to emit the extra branch. But that would require having B3 exploit the fact that Oops is known to
+be unreachable. Although B3 IR semantics (webkit.org/docs/b3/intermediate-representation.html)
+seem to allow this, I don't particularly like that style of optimization. I like Oops to mean
+trap.
+
+So, this patch makes FTL lowering turn one of the cases into the default, explicitly removing the
+extra branch.
+
+This is not a speed-up. But it makes the B3 IR for MultiByOffset a lot simpler, which should make
+it easier to implement B3-level optimizations for MultiByOffset. It also makes the IR easier to
+read.
+
+* ftl/FTLLowerDFGToB3.cpp:
+(JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
+(JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
+(JSC::FTL::DFG::LowerDFGToB3::emitSwitchForMultiByOffset):
+
+2018-04-24 Filip Pizlo
+
DFG CSE should know how to decay a MultiGetByOffset
https://bugs.webkit.org/show_bug.cgi?id=159859
Modified: trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp (230974 => 230975)
--- trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp 2018-04-24 22:11:53 UTC (rev 230974)
+++ trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp 2018-04-24 22:29:39 UTC (rev 230975)
@@ -6438,14 +6438,6 @@
MultiGetByOffsetData& data = ""
-if (data.cases.isEmpty()) {
-// Protect against creating a Phi function with zero inputs. LLVM didn't like that.
-// It's not clear if this is needed anymore.
-// FIXME: https://bugs.webkit.org/show_bug.cgi?id=154382
-terminate(BadCache);
-return;
-}
-
Vector blocks(data.cases.size());
for (unsigned i = data.cases.size(); i--;)
blocks[i] = m_out.newBlock();
@@ -6462,8 +6454,8 @@
cases.append(SwitchCase(weakStructureID(structure), blocks[i], Weight(1)));
}
}
-m_out.switchInst
[webkit-changes] [230964] trunk/Source/JavaScriptCore
Title: [230964] trunk/Source/_javascript_Core
Revision 230964
Author fpi...@apple.com
Date 2018-04-24 11:54:47 -0700 (Tue, 24 Apr 2018)
Log Message
DFG CSE should know how to decay a MultiGetByOffset
https://bugs.webkit.org/show_bug.cgi?id=159859
Reviewed by Keith Miller.
This teaches Node::remove() how to decay a MultiGetByOffset to a CheckStructure, so that
clobberize() can report a def() for MultiGetByOffset.
This is a slight improvement to codegen in splay because splay is a heavy user of
MultiGetByOffset. It uses it redundantly in one of its hot functions (the function called
"splay_"). I don't see a net speed-up in the benchmark. However, this is just a first step to
removing MultiXByOffset-related redundancies, which by my estimates account for 16% of
splay's time.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGNode.cpp:
(JSC::DFG::Node::remove):
(JSC::DFG::Node::removeWithoutChecks):
(JSC::DFG::Node::replaceWith):
(JSC::DFG::Node::replaceWithWithoutChecks):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToMultiGetByOffset):
(JSC::DFG::Node::replaceWith): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGClobberize.h
trunk/Source/_javascript_Core/dfg/DFGNode.cpp
trunk/Source/_javascript_Core/dfg/DFGNode.h
trunk/Source/_javascript_Core/dfg/DFGNodeType.h
trunk/Source/_javascript_Core/dfg/DFGObjectAllocationSinkingPhase.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (230963 => 230964)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-24 18:15:48 UTC (rev 230963)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-24 18:54:47 UTC (rev 230964)
@@ -1,3 +1,32 @@
+2018-04-24 Filip Pizlo
+
+DFG CSE should know how to decay a MultiGetByOffset
+https://bugs.webkit.org/show_bug.cgi?id=159859
+
+Reviewed by Keith Miller.
+
+This teaches Node::remove() how to decay a MultiGetByOffset to a CheckStructure, so that
+clobberize() can report a def() for MultiGetByOffset.
+
+This is a slight improvement to codegen in splay because splay is a heavy user of
+MultiGetByOffset. It uses it redundantly in one of its hot functions (the function called
+"splay_"). I don't see a net speed-up in the benchmark. However, this is just a first step to
+removing MultiXByOffset-related redundancies, which by my estimates account for 16% of
+splay's time.
+
+* dfg/DFGClobberize.h:
+(JSC::DFG::clobberize):
+* dfg/DFGNode.cpp:
+(JSC::DFG::Node::remove):
+(JSC::DFG::Node::removeWithoutChecks):
+(JSC::DFG::Node::replaceWith):
+(JSC::DFG::Node::replaceWithWithoutChecks):
+* dfg/DFGNode.h:
+(JSC::DFG::Node::convertToMultiGetByOffset):
+(JSC::DFG::Node::replaceWith): Deleted.
+* dfg/DFGNodeType.h:
+* dfg/DFGObjectAllocationSinkingPhase.cpp:
+
2018-04-24 Keith Miller
Update API docs with information on which run loop the VM will use
Modified: trunk/Source/_javascript_Core/dfg/DFGClobberize.h (230963 => 230964)
--- trunk/Source/_javascript_Core/dfg/DFGClobberize.h 2018-04-24 18:15:48 UTC (rev 230963)
+++ trunk/Source/_javascript_Core/dfg/DFGClobberize.h 2018-04-24 18:54:47 UTC (rev 230964)
@@ -1188,9 +1188,7 @@
read(JSObject_butterflyMask);
AbstractHeap heap(NamedProperties, node->multiGetByOffsetData().identifierNumber);
read(heap);
-// FIXME: We cannot def() for MultiGetByOffset because CSE is not smart enough to decay it
-// to a CheckStructure.
-// https://bugs.webkit.org/show_bug.cgi?id=159859
+def(HeapLocation(NamedPropertyLoc, heap, node->child1()), LazyNode(node));
return;
}
Modified: trunk/Source/_javascript_Core/dfg/DFGNode.cpp (230963 => 230964)
--- trunk/Source/_javascript_Core/dfg/DFGNode.cpp 2018-04-24 18:15:48 UTC (rev 230963)
+++ trunk/Source/_javascript_Core/dfg/DFGNode.cpp 2018-04-24 18:54:47 UTC (rev 230964)
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2013, 2014, 2016 Apple Inc. All rights reserved.
+ * Copyright (C) 2013-2018 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -83,27 +83,62 @@
void Node::remove(Graph& graph)
{
-if (flags() & NodeHasVarArgs) {
-unsigned targetIndex = 0;
-for (unsigned i = 0; i < numChildren(); ++i) {
-Edge& edge = graph.varArgChild(this, i);
-if (!edge)
-continue;
-if (edge.willHaveCheck()) {
-Edge& dst = graph.varArgChild(this, targetIndex++);
-std::swap(dst, edge);
-continue;
+switch (op()) {
+case MultiGetByOffset: {
+MultiGetByOffsetData& data = ""
+StructureSet
[webkit-changes] [230956] trunk/Source/JavaScriptCore
Title: [230956] trunk/Source/_javascript_Core
Revision 230956
Author fpi...@apple.com
Date 2018-04-24 08:53:15 -0700 (Tue, 24 Apr 2018)
Log Message
$vm.totalGCTime() should be a thing
https://bugs.webkit.org/show_bug.cgi?id=184916
Reviewed by Sam Weinig.
When debugging regressions in tests that are GC heavy, it's nice to be able to query the total
time spent in GC to determine if the regression is because the GC got slower.
This adds $vm.totalGCTime(), which tells you the total time spent in GC, in seconds.
* heap/Heap.cpp:
(JSC::Heap::runEndPhase):
* heap/Heap.h:
(JSC::Heap::totalGCTime const):
* tools/JSDollarVM.cpp:
(JSC::functionTotalGCTime):
(JSC::JSDollarVM::finishCreation):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/heap/Heap.cpp
trunk/Source/_javascript_Core/heap/Heap.h
trunk/Source/_javascript_Core/tools/JSDollarVM.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (230955 => 230956)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-24 15:27:46 UTC (rev 230955)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-24 15:53:15 UTC (rev 230956)
@@ -1,3 +1,23 @@
+2018-04-24 Filip Pizlo
+
+$vm.totalGCTime() should be a thing
+https://bugs.webkit.org/show_bug.cgi?id=184916
+
+Reviewed by Sam Weinig.
+
+When debugging regressions in tests that are GC heavy, it's nice to be able to query the total
+time spent in GC to determine if the regression is because the GC got slower.
+
+This adds $vm.totalGCTime(), which tells you the total time spent in GC, in seconds.
+
+* heap/Heap.cpp:
+(JSC::Heap::runEndPhase):
+* heap/Heap.h:
+(JSC::Heap::totalGCTime const):
+* tools/JSDollarVM.cpp:
+(JSC::functionTotalGCTime):
+(JSC::JSDollarVM::finishCreation):
+
2018-04-23 Zalan Bujtas
[LayoutFormattingContext] Initial commit.
Modified: trunk/Source/_javascript_Core/heap/Heap.cpp (230955 => 230956)
--- trunk/Source/_javascript_Core/heap/Heap.cpp 2018-04-24 15:27:46 UTC (rev 230955)
+++ trunk/Source/_javascript_Core/heap/Heap.cpp 2018-04-24 15:53:15 UTC (rev 230956)
@@ -1512,6 +1512,7 @@
m_lastGCStartTime = m_currentGCStartTime;
m_lastGCEndTime = MonotonicTime::now();
+m_totalGCTime += m_lastGCEndTime - m_lastGCStartTime;
return changePhase(conn, CollectorPhase::NotRunning);
}
Modified: trunk/Source/_javascript_Core/heap/Heap.h (230955 => 230956)
--- trunk/Source/_javascript_Core/heap/Heap.h 2018-04-24 15:27:46 UTC (rev 230955)
+++ trunk/Source/_javascript_Core/heap/Heap.h 2018-04-24 15:53:15 UTC (rev 230956)
@@ -382,6 +382,8 @@
void forEachSlotVisitor(const Func&);
ThreadLocalCacheLayout& threadLocalCacheLayout() { return *m_threadLocalCacheLayout; }
+
+Seconds totalGCTime() const { return m_totalGCTime; }
private:
friend class AllocatingScope;
@@ -723,6 +725,7 @@
MonotonicTime m_lastGCStartTime;
MonotonicTime m_lastGCEndTime;
MonotonicTime m_currentGCStartTime;
+Seconds m_totalGCTime;
uintptr_t m_barriersExecuted { 0 };
Modified: trunk/Source/_javascript_Core/tools/JSDollarVM.cpp (230955 => 230956)
--- trunk/Source/_javascript_Core/tools/JSDollarVM.cpp 2018-04-24 15:27:46 UTC (rev 230955)
+++ trunk/Source/_javascript_Core/tools/JSDollarVM.cpp 2018-04-24 15:53:15 UTC (rev 230956)
@@ -1763,6 +1763,12 @@
return JSValue::encode(jsNumber(static_cast(delta)));
}
+static EncodedJSValue JSC_HOST_CALL functionTotalGCTime(ExecState* exec)
+{
+VM& vm = exec->vm();
+return JSValue::encode(jsNumber(vm.heap.totalGCTime().seconds()));
+}
+
void JSDollarVM::finishCreation(VM& vm)
{
Base::finishCreation(vm);
@@ -1850,6 +1856,8 @@
addFunction(vm, "createCustomTestGetterSetter", functionCreateCustomTestGetterSetter, 1);
addFunction(vm, "deltaBetweenButterflies", functionDeltaBetweenButterflies, 2);
+
+addFunction(vm, "totalGCTime", functionTotalGCTime, 0);
}
void JSDollarVM::addFunction(VM& vm, JSGlobalObject* globalObject, const char* name, NativeFunction function, unsigned arguments)
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [230929] trunk/Source/JavaScriptCore
Title: [230929] trunk/Source/_javascript_Core
Revision 230929
Author fpi...@apple.com
Date 2018-04-23 15:26:50 -0700 (Mon, 23 Apr 2018)
Log Message
Unreviewed, revert accidental change to verbose flag.
* dfg/DFGByteCodeParser.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (230928 => 230929)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-23 22:25:29 UTC (rev 230928)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-23 22:26:50 UTC (rev 230929)
@@ -1,5 +1,11 @@
2018-04-23 Filip Pizlo
+Unreviewed, revert accidental change to verbose flag.
+
+* dfg/DFGByteCodeParser.cpp:
+
+2018-04-23 Filip Pizlo
+
Roll out r226655 because it broke OSR entry when the pre-header is inadequately profiled.
Rubber stamped by Saam Barati.
Modified: trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp (230928 => 230929)
--- trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp 2018-04-23 22:25:29 UTC (rev 230928)
+++ trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp 2018-04-23 22:26:50 UTC (rev 230929)
@@ -71,7 +71,7 @@
namespace DFGByteCodeParserInternal {
#ifdef NDEBUG
-static const bool verbose = true;
+static const bool verbose = false;
#else
static const bool verbose = true;
#endif
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [230928] trunk/Source/JavaScriptCore
Title: [230928] trunk/Source/_javascript_Core
Revision 230928
Author fpi...@apple.com
Date 2018-04-23 15:25:29 -0700 (Mon, 23 Apr 2018)
Log Message
Roll out r226655 because it broke OSR entry when the pre-header is inadequately profiled.
Rubber stamped by Saam Barati.
This is a >2x speed-up in SunSpider/bitops-bitwise-and. We don't really care about SunSpider
anymore, but r226655 didn't result in any benchmark wins and just regressed this test by a lot.
Seems sensible to just roll it out.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addToGraph):
(JSC::DFG::ByteCodeParser::parse):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (230927 => 230928)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-23 21:59:46 UTC (rev 230927)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-23 22:25:29 UTC (rev 230928)
@@ -1,3 +1,17 @@
+2018-04-23 Filip Pizlo
+
+Roll out r226655 because it broke OSR entry when the pre-header is inadequately profiled.
+
+Rubber stamped by Saam Barati.
+
+This is a >2x speed-up in SunSpider/bitops-bitwise-and. We don't really care about SunSpider
+anymore, but r226655 didn't result in any benchmark wins and just regressed this test by a lot.
+Seems sensible to just roll it out.
+
+* dfg/DFGByteCodeParser.cpp:
+(JSC::DFG::ByteCodeParser::addToGraph):
+(JSC::DFG::ByteCodeParser::parse):
+
2018-04-22 Yusuke Suzuki
[JSC] Remove ModuleLoaderPrototype
Modified: trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp (230927 => 230928)
--- trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp 2018-04-23 21:59:46 UTC (rev 230927)
+++ trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp 2018-04-23 22:25:29 UTC (rev 230928)
@@ -71,7 +71,7 @@
namespace DFGByteCodeParserInternal {
#ifdef NDEBUG
-static const bool verbose = false;
+static const bool verbose = true;
#else
static const bool verbose = true;
#endif
@@ -692,10 +692,7 @@
Node* addToGraph(Node* node)
{
-m_hasAnyForceOSRExits |= (node->op() == ForceOSRExit);
-
VERBOSE_LOG("appended ", node, " ", Graph::opName(node->op()), "\n");
-
m_currentBlock->append(node);
if (clobbersExitState(m_graph, node))
m_exitOK = false;
@@ -1152,7 +1149,6 @@
Instruction* m_currentInstruction;
bool m_hasDebuggerEnabled;
-bool m_hasAnyForceOSRExits { false };
};
BasicBlock* ByteCodeParser::allocateTargetableBlock(unsigned bytecodeIndex)
@@ -6694,78 +6690,6 @@
parseCodeBlock();
linkBlocks(inlineStackEntry.m_unlinkedBlocks, inlineStackEntry.m_blockLinkingTargets);
-if (m_hasAnyForceOSRExits) {
-InsertionSet insertionSet(m_graph);
-Operands mapping(OperandsLike, m_graph.block(0)->variablesAtHead);
-
-for (BasicBlock* block : m_graph.blocksInNaturalOrder()) {
-mapping.fill(nullptr);
-if (validationEnabled()) {
-// Verify that it's correct to fill mapping with nullptr.
-for (unsigned i = 0; i < block->variablesAtHead.size(); ++i) {
-Node* node = block->variablesAtHead.at(i);
-RELEASE_ASSERT(!node);
-}
-}
-
-for (unsigned nodeIndex = 0; nodeIndex < block->size(); ++nodeIndex) {
-Node* node = block->at(nodeIndex);
-
-if (node->hasVariableAccessData(m_graph))
-mapping.operand(node->local()) = node->variableAccessData();
-
-if (node->op() == ForceOSRExit) {
-NodeOrigin endOrigin = node->origin.withExitOK(true);
-
-if (validationEnabled()) {
-// This verifies that we don't need to change any of the successors's predecessor
-// list after planting the Unreachable below. At this point in the bytecode
-// parser, we haven't linked up the predecessor lists yet.
-for (BasicBlock* successor : block->successors())
-RELEASE_ASSERT(successor->predecessors.isEmpty());
-}
-
-block->resize(nodeIndex + 1);
-
-insertionSet.insertNode(block->size(), SpecNone, ExitOK, endOrigin);
-
-auto insertLivenessPreservingOp = [&] (InlineCallFrame* inlineCallFrame, NodeType op, VirtualRegister operand) {
-VariableAccessData* variable = mapping.operand(operand);
-if (!variable) {
-variable = newVariableAccessData(operand);
-mapping.operand(operand) = variable;
-}
-
-VirtualRegister argument = operand - (inlineCallFrame ? inl
[webkit-changes] [230813] trunk/Source
Title: [230813] trunk/Source Revision 230813 Author fpi...@apple.com Date 2018-04-19 12:33:03 -0700 (Thu, 19 Apr 2018) Log Message The InternalFunction hierarchy should be in IsoSubspaces https://bugs.webkit.org/show_bug.cgi?id=184721 Reviewed by Saam Barati. Source/_javascript_Core: This moves InternalFunction into a IsoSubspace. It also moves all subclasses into IsoSubspaces, but subclasses that are the same size as InternalFunction share its subspace. I did this because the subclasses appear to just override methods, which are called dynamically via the structure or class of the object. So, I don't see a type confusion risk if UAF is used to allocate one kind of InternalFunction over another. * API/JSBase.h: * API/JSCallbackFunction.h: * API/ObjCCallbackFunction.h: (JSC::ObjCCallbackFunction::subspaceFor): * CMakeLists.txt: * _javascript_Core.xcodeproj/project.pbxproj: * Sources.txt: * heap/IsoSubspacePerVM.cpp: Added. (JSC::IsoSubspacePerVM::AutoremovingIsoSubspace::AutoremovingIsoSubspace): (JSC::IsoSubspacePerVM::AutoremovingIsoSubspace::~AutoremovingIsoSubspace): (JSC::IsoSubspacePerVM::IsoSubspacePerVM): (JSC::IsoSubspacePerVM::~IsoSubspacePerVM): (JSC::IsoSubspacePerVM::forVM): * heap/IsoSubspacePerVM.h: Added. (JSC::IsoSubspacePerVM::SubspaceParameters::SubspaceParameters): * runtime/Error.h: * runtime/ErrorConstructor.h: * runtime/InternalFunction.h: (JSC::InternalFunction::subspaceFor): * runtime/IntlCollatorConstructor.h: * runtime/IntlDateTimeFormatConstructor.h: * runtime/IntlNumberFormatConstructor.h: * runtime/JSArrayBufferConstructor.h: * runtime/NativeErrorConstructor.h: * runtime/ProxyRevoke.h: * runtime/RegExpConstructor.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: Source/WebCore: No new tests because no new behavior. * bindings/js/WebCoreJSClientData.cpp: (WebCore::JSVMClientData::JSVMClientData): * bindings/js/WebCoreJSClientData.h: (WebCore::JSVMClientData::runtimeMethodSpace): * bridge/runtime_method.cpp: (JSC::RuntimeMethod::subspaceForImpl): * bridge/runtime_method.h: Source/WebKit: * WebProcess/Plugins/Netscape/JSNPMethod.cpp: (WebKit::JSNPMethod::subspaceForImpl): * WebProcess/Plugins/Netscape/JSNPMethod.h: (WebKit::JSNPMethod::create): Deleted. (WebKit::JSNPMethod::npIdentifier const): Deleted. (WebKit::JSNPMethod::createStructure): Deleted. * WebProcess/Plugins/Netscape/JSNPObject.cpp: (WebKit::JSNPObject::subspaceForImpl): * WebProcess/Plugins/Netscape/JSNPObject.h: (WebKit::JSNPObject::create): Deleted. (WebKit::JSNPObject::npObject const): Deleted. (WebKit::JSNPObject::createStructure): Deleted. Modified Paths trunk/Source/_javascript_Core/API/JSBase.h trunk/Source/_javascript_Core/API/JSCallbackFunction.h trunk/Source/_javascript_Core/API/ObjCCallbackFunction.h trunk/Source/_javascript_Core/API/glib/JSCCallbackFunction.cpp trunk/Source/_javascript_Core/API/glib/JSCCallbackFunction.h trunk/Source/_javascript_Core/CMakeLists.txt trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj trunk/Source/_javascript_Core/Sources.txt trunk/Source/_javascript_Core/runtime/Error.h trunk/Source/_javascript_Core/runtime/ErrorConstructor.h trunk/Source/_javascript_Core/runtime/InternalFunction.h trunk/Source/_javascript_Core/runtime/IntlCollatorConstructor.h trunk/Source/_javascript_Core/runtime/IntlDateTimeFormatConstructor.h trunk/Source/_javascript_Core/runtime/IntlNumberFormatConstructor.h trunk/Source/_javascript_Core/runtime/JSArrayBufferConstructor.h trunk/Source/_javascript_Core/runtime/NativeErrorConstructor.h trunk/Source/_javascript_Core/runtime/ProxyRevoke.h trunk/Source/_javascript_Core/runtime/RegExpConstructor.h trunk/Source/_javascript_Core/runtime/VM.cpp trunk/Source/_javascript_Core/runtime/VM.h trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/bindings/js/WebCoreJSClientData.cpp trunk/Source/WebCore/bindings/js/WebCoreJSClientData.h trunk/Source/WebCore/bridge/runtime_method.cpp trunk/Source/WebCore/bridge/runtime_method.h trunk/Source/WebKit/ChangeLog trunk/Source/WebKit/WebProcess/Plugins/Netscape/JSNPMethod.cpp trunk/Source/WebKit/WebProcess/Plugins/Netscape/JSNPMethod.h trunk/Source/WebKit/WebProcess/Plugins/Netscape/JSNPObject.cpp trunk/Source/WebKit/WebProcess/Plugins/Netscape/JSNPObject.h Added Paths trunk/Source/_javascript_Core/heap/IsoSubspacePerVM.cpp trunk/Source/_javascript_Core/heap/IsoSubspacePerVM.h Diff Modified: trunk/Source/_javascript_Core/API/JSBase.h (230812 => 230813) --- trunk/Source/_javascript_Core/API/JSBase.h 2018-04-19 18:45:40 UTC (rev 230812) +++ trunk/Source/_javascript_Core/API/JSBase.h 2018-04-19 19:33:03 UTC (rev 230813) @@ -143,7 +143,7 @@ } #endif -/* Enable the Objective-C API for platforms with a modern runtime. */ +/* Enable the Objective-C API for platforms with a modern runtime. NOTE: This is duplicated in VM.h. */ #if !defined(JSC_OBJC_API_ENABLED) #if (defined(__clang__) && defined(__APPLE__) && ((defined(__MAC_OS_X
[webkit-changes] [230726] trunk/Source/JavaScriptCore
Title: [230726] trunk/Source/_javascript_Core
Revision 230726
Author fpi...@apple.com
Date 2018-04-17 12:56:33 -0700 (Tue, 17 Apr 2018)
Log Message
JSGenericTypedArrayView<>::visitChildren has a race condition reading m_mode and m_vector
https://bugs.webkit.org/show_bug.cgi?id=184705
Reviewed by Michael Saboff.
My old multisocket Mac Pro is amazing at catching race conditions in the GC. Earlier today
while testing an unrelated patch, a concurrent GC thread crashed inside
JSGenericTypedArrayView<>::visitChildren() calling markAuxiliary(). I'm pretty sure it's
because a typed array became wasteful concurrently to the GC. So, visitChildren() read one
mode and another vector.
The fix is to lock inside visitChildren and anyone who changes those fields.
I'm not even going to try to write a test. I think it's super lucky that my Mac Pro caught
this.
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::neuter):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView::visitChildren):
(JSC::JSGenericTypedArrayView::slowDownAndWasteMemory):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/JSArrayBufferView.cpp
trunk/Source/_javascript_Core/runtime/JSGenericTypedArrayViewInlines.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (230725 => 230726)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-17 19:53:30 UTC (rev 230725)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-17 19:56:33 UTC (rev 230726)
@@ -1,3 +1,27 @@
+2018-04-17 Filip Pizlo
+
+JSGenericTypedArrayView<>::visitChildren has a race condition reading m_mode and m_vector
+https://bugs.webkit.org/show_bug.cgi?id=184705
+
+Reviewed by Michael Saboff.
+
+My old multisocket Mac Pro is amazing at catching race conditions in the GC. Earlier today
+while testing an unrelated patch, a concurrent GC thread crashed inside
+JSGenericTypedArrayView<>::visitChildren() calling markAuxiliary(). I'm pretty sure it's
+because a typed array became wasteful concurrently to the GC. So, visitChildren() read one
+mode and another vector.
+
+The fix is to lock inside visitChildren and anyone who changes those fields.
+
+I'm not even going to try to write a test. I think it's super lucky that my Mac Pro caught
+this.
+
+* runtime/JSArrayBufferView.cpp:
+(JSC::JSArrayBufferView::neuter):
+* runtime/JSGenericTypedArrayViewInlines.h:
+(JSC::JSGenericTypedArrayView::visitChildren):
+(JSC::JSGenericTypedArrayView::slowDownAndWasteMemory):
+
2018-04-16 Filip Pizlo
PutStackSinkingPhase should know that KillStack means ConflictingFlush
Modified: trunk/Source/_javascript_Core/runtime/JSArrayBufferView.cpp (230725 => 230726)
--- trunk/Source/_javascript_Core/runtime/JSArrayBufferView.cpp 2018-04-17 19:53:30 UTC (rev 230725)
+++ trunk/Source/_javascript_Core/runtime/JSArrayBufferView.cpp 2018-04-17 19:56:33 UTC (rev 230726)
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2013-2017 Apple Inc. All rights reserved.
+ * Copyright (C) 2013-2018 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -209,6 +209,7 @@
void JSArrayBufferView::neuter()
{
+auto locker = holdLock(cellLock());
RELEASE_ASSERT(hasArrayBuffer());
RELEASE_ASSERT(!isShared());
m_length = 0;
Modified: trunk/Source/_javascript_Core/runtime/JSGenericTypedArrayViewInlines.h (230725 => 230726)
--- trunk/Source/_javascript_Core/runtime/JSGenericTypedArrayViewInlines.h 2018-04-17 19:53:30 UTC (rev 230725)
+++ trunk/Source/_javascript_Core/runtime/JSGenericTypedArrayViewInlines.h 2018-04-17 19:56:33 UTC (rev 230726)
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2013, 2016 Apple Inc. All rights reserved.
+ * Copyright (C) 2013-2018 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -515,15 +515,26 @@
{
JSGenericTypedArrayView* thisObject = jsCast(cell);
-switch (thisObject->m_mode) {
+TypedArrayMode mode;
+void* vector;
+size_t byteSize;
+
+{
+auto locker = holdLock(thisObject->cellLock());
+mode = thisObject->m_mode;
+vector = thisObject->m_vector.getMayBeNull();
+byteSize = thisObject->byteSize();
+}
+
+switch (mode) {
case FastTypedArray: {
-if (void* vector = thisObject->m_vector.getMayBeNull())
+if (vector)
visitor.markAuxiliary(vector);
break;
}
case OversizeTypedArray: {
-visitor.reportExtraMemoryVisited(thisObject->byteSize());
+visitor.reportExtraMemoryVisited(byteSize);
break;
}
@@ -583,10 +59
[webkit-changes] [230725] trunk
Title: [230725] trunk
Revision 230725
Author fpi...@apple.com
Date 2018-04-17 12:53:30 -0700 (Tue, 17 Apr 2018)
Log Message
PutStackSinkingPhase should know that KillStack means ConflictingFlush
https://bugs.webkit.org/show_bug.cgi?id=184672
Reviewed by Michael Saboff.
JSTests:
* stress/sink-put-stack-over-kill-stack.js: Added.
(avocado_1):
(apricot_0):
(__c_0):
(banana_2):
Source/_javascript_Core:
We've had a long history of KillStack and PutStackSinkingPhase having problems. We kept changing the meaning of
KillStack, and at some point we removed reasoning about KillStack from PutStackSinkingPhase. I tried doing some
archeology - but I'm still not sure why that phase ignores KillStack entirely. Maybe it's an oversight or maybe it's
intentional - I don't know.
Whatever the history, it's clear from the attached test case that ignoring KillStack is not correct. The outcome of
doing so is that we will sometimes sink a PutStack below a KillStack. That's wrong because then, OSR exit will use
the value from the PutStack instead of using the value from the MovHint that is associated with the KillStack. So,
KillStack must be seen as a special kind of clobber of the stack slot. OSRAvailabiity uses ConflictingFlush. I think
that's correct here, too. If we used DeadFlush and that was merged with another control flow path that had a
specific flush format, then we would think that we could sink the flush from that path. That's not right, since that
could still lead to sinking a PutStack past the KillStack in the sense that a PutStack will appear after the
KillStack along one path through the CFG. Also, the definition of DeadFlush and ConflictingFlush in the comment
inside PutStackSinkingPhase seems to suggest that KillStack is a ConflictingFlush, since DeadFlush means that we
have done some PutStack and their values are still valid. KillStack is not a PutStack and it means that previous
values are not valid. The definition of ConflictingFlush is that "we know, via forward flow, that there isn't any
value in the given local that anyone should have been relying on" - which exactly matches KillStack's definition.
This also means that we cannot eliminate arguments allocations that are live over KillStacks, since if we eliminated
them then we would have a GetStack after a KillStack. One easy way to fix this is to say that KillStack writes to
its stack slot for the purpose of clobberize.
* dfg/DFGClobberize.h: KillStack "writes" to its stack slot.
* dfg/DFGPutStackSinkingPhase.cpp: Fix the bug.
* ftl/FTLLowerDFGToB3.cpp: Add better assertion failure.
(JSC::FTL::DFG::LowerDFGToB3::buildExitArguments):
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGClobberize.h
trunk/Source/_javascript_Core/dfg/DFGPutStackSinkingPhase.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
Added Paths
trunk/JSTests/stress/sink-put-stack-over-kill-stack.js
Diff
Modified: trunk/JSTests/ChangeLog (230724 => 230725)
--- trunk/JSTests/ChangeLog 2018-04-17 19:13:10 UTC (rev 230724)
+++ trunk/JSTests/ChangeLog 2018-04-17 19:53:30 UTC (rev 230725)
@@ -1,3 +1,16 @@
+2018-04-16 Filip Pizlo
+
+PutStackSinkingPhase should know that KillStack means ConflictingFlush
+https://bugs.webkit.org/show_bug.cgi?id=184672
+
+Reviewed by Michael Saboff.
+
+* stress/sink-put-stack-over-kill-stack.js: Added.
+(avocado_1):
+(apricot_0):
+(__c_0):
+(banana_2):
+
2018-04-17 Yusuke Suzuki
[JSC] Rename runWebAssembly to runWebAssemblySuite
Added: trunk/JSTests/stress/sink-put-stack-over-kill-stack.js (0 => 230725)
--- trunk/JSTests/stress/sink-put-stack-over-kill-stack.js (rev 0)
+++ trunk/JSTests/stress/sink-put-stack-over-kill-stack.js 2018-04-17 19:53:30 UTC (rev 230725)
@@ -0,0 +1,16 @@
+function* avocado_1() {}
+
+function apricot_0(alpaca_0) {
+ if (alpaca_0) {}
+}
+
+class __c_0 extends null {}
+
+function banana_2() {
+ apricot_0();
+ avocado_1(() => null);
+}
+
+for (let i = 0; i < 10; i++) {
+ banana_2();
+}
Modified: trunk/Source/_javascript_Core/ChangeLog (230724 => 230725)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-17 19:13:10 UTC (rev 230724)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-17 19:53:30 UTC (rev 230725)
@@ -1,3 +1,37 @@
+2018-04-16 Filip Pizlo
+
+PutStackSinkingPhase should know that KillStack means ConflictingFlush
+https://bugs.webkit.org/show_bug.cgi?id=184672
+
+Reviewed by Michael Saboff.
+
+We've had a long history of KillStack and PutStackSinkingPhase having problems. We kept changing the meaning of
+KillStack, and at some point we removed reasoning about KillStack from PutStackSinkingPhase. I tried doing some
+archeology - but I'm still not sure why that phase ignores KillStack entirely. Maybe it's an oversight or maybe it's
+intentional - I don't kno
[webkit-changes] [230723] trunk/Source/JavaScriptCore
Title: [230723] trunk/Source/_javascript_Core
Revision 230723
Author fpi...@apple.com
Date 2018-04-17 11:59:00 -0700 (Tue, 17 Apr 2018)
Log Message
JSWebAssemblyCodeBlock should be in an IsoSubspace
https://bugs.webkit.org/show_bug.cgi?id=184704
Reviewed by Mark Lam.
Previously it was in a CompleteSubspace, which is pretty good, but also quite wasteful.
CompleteSubspace means about 4KB of data to track the size-allocator mapping. IsoSubspace
shortcircuits this. Also, IsoSubspace uses the iso allocator, so it provides stronger UAF
protection.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* wasm/js/JSWebAssemblyCodeBlock.h:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/VM.cpp
trunk/Source/_javascript_Core/runtime/VM.h
trunk/Source/_javascript_Core/wasm/js/JSWebAssemblyCodeBlock.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (230722 => 230723)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-17 18:33:36 UTC (rev 230722)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-17 18:59:00 UTC (rev 230723)
@@ -1,3 +1,20 @@
+2018-04-17 Filip Pizlo
+
+JSWebAssemblyCodeBlock should be in an IsoSubspace
+https://bugs.webkit.org/show_bug.cgi?id=184704
+
+Reviewed by Mark Lam.
+
+Previously it was in a CompleteSubspace, which is pretty good, but also quite wasteful.
+CompleteSubspace means about 4KB of data to track the size-allocator mapping. IsoSubspace
+shortcircuits this. Also, IsoSubspace uses the iso allocator, so it provides stronger UAF
+protection.
+
+* runtime/VM.cpp:
+(JSC::VM::VM):
+* runtime/VM.h:
+* wasm/js/JSWebAssemblyCodeBlock.h:
+
2018-04-17 Jer Noble
Only enable useSeparatedWXHeap on ARM64.
Modified: trunk/Source/_javascript_Core/runtime/VM.cpp (230722 => 230723)
--- trunk/Source/_javascript_Core/runtime/VM.cpp 2018-04-17 18:33:36 UTC (rev 230722)
+++ trunk/Source/_javascript_Core/runtime/VM.cpp 2018-04-17 18:59:00 UTC (rev 230723)
@@ -94,6 +94,7 @@
#include "JSWeakMap.h"
#include "JSWeakSet.h"
#include "JSWebAssembly.h"
+#include "JSWebAssemblyCodeBlock.h"
#include "JSWebAssemblyCodeBlockHeapCellType.h"
#include "JSWithScope.h"
#include "LLIntData.h"
@@ -253,9 +254,6 @@
, destructibleObjectSpace("JSDestructibleObject", heap, destructibleObjectHeapCellType.get(), fastMallocAllocator.get())
, eagerlySweptDestructibleObjectSpace("Eagerly Swept JSDestructibleObject", heap, destructibleObjectHeapCellType.get(), fastMallocAllocator.get())
, segmentedVariableObjectSpace("JSSegmentedVariableObjectSpace", heap, segmentedVariableObjectHeapCellType.get(), fastMallocAllocator.get())
-#if ENABLE(WEBASSEMBLY)
-, webAssemblyCodeBlockSpace("JSWebAssemblyCodeBlockSpace", heap, webAssemblyCodeBlockHeapCellType.get(), fastMallocAllocator.get())
-#endif
, asyncFunctionSpace ISO_SUBSPACE_INIT(heap, cellJSValueOOBHeapCellType.get(), JSAsyncFunction)
, asyncGeneratorFunctionSpace ISO_SUBSPACE_INIT(heap, cellJSValueOOBHeapCellType.get(), JSAsyncGeneratorFunction)
, boundFunctionSpace ISO_SUBSPACE_INIT(heap, cellJSValueOOBHeapCellType.get(), JSBoundFunction)
@@ -278,6 +276,7 @@
, weakSetSpace ISO_SUBSPACE_INIT(heap, destructibleObjectHeapCellType.get(), JSWeakSet)
, weakMapSpace ISO_SUBSPACE_INIT(heap, destructibleObjectHeapCellType.get(), JSWeakMap)
#if ENABLE(WEBASSEMBLY)
+, webAssemblyCodeBlockSpace ISO_SUBSPACE_INIT(heap, webAssemblyCodeBlockHeapCellType.get(), JSWebAssemblyCodeBlock)
, webAssemblyFunctionSpace ISO_SUBSPACE_INIT(heap, cellJSValueOOBHeapCellType.get(), WebAssemblyFunction)
, webAssemblyWrapperFunctionSpace ISO_SUBSPACE_INIT(heap, cellJSValueOOBHeapCellType.get(), WebAssemblyWrapperFunction)
#endif
Modified: trunk/Source/_javascript_Core/runtime/VM.h (230722 => 230723)
--- trunk/Source/_javascript_Core/runtime/VM.h 2018-04-17 18:33:36 UTC (rev 230722)
+++ trunk/Source/_javascript_Core/runtime/VM.h 2018-04-17 18:59:00 UTC (rev 230723)
@@ -336,9 +336,6 @@
CompleteSubspace destructibleObjectSpace;
CompleteSubspace eagerlySweptDestructibleObjectSpace;
CompleteSubspace segmentedVariableObjectSpace;
-#if ENABLE(WEBASSEMBLY)
-CompleteSubspace webAssemblyCodeBlockSpace;
-#endif
IsoSubspace asyncFunctionSpace;
IsoSubspace asyncGeneratorFunctionSpace;
@@ -362,6 +359,7 @@
IsoSubspace weakSetSpace;
IsoSubspace weakMapSpace;
#if ENABLE(WEBASSEMBLY)
+IsoSubspace webAssemblyCodeBlockSpace;
IsoSubspace webAssemblyFunctionSpace;
IsoSubspace webAssemblyWrapperFunctionSpace;
#endif
Modified: trunk/Source/_javascript_Core/wasm/js/JSWebAssemblyCodeBlock.h (230722 => 230723)
--- trunk/Source/_javascript_Core/wasm/js/JSWebAssemblyCodeBlock.h 2018-04-17 18:33:36 UTC (rev 230722)
+++ trunk/Source/_javascript_Core/wasm/js/JSWebAssemblyCodeBlock.h 2018-04-17 18:59:00 UTC (rev 230723)
@@ -61,7 +61,7
[webkit-changes] [230695] trunk/Source/WebCore
Title: [230695] trunk/Source/WebCore
Revision 230695
Author fpi...@apple.com
Date 2018-04-16 18:56:15 -0700 (Mon, 16 Apr 2018)
Log Message
MutationObserver should be in an IsoHeap
https://bugs.webkit.org/show_bug.cgi?id=184671
Reviewed by Sam Weinig.
No new tests because no new behavior.
* dom/MutationObserver.cpp:
* dom/MutationObserver.h:
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/dom/MutationObserver.cpp
trunk/Source/WebCore/dom/MutationObserver.h
Diff
Modified: trunk/Source/WebCore/ChangeLog (230694 => 230695)
--- trunk/Source/WebCore/ChangeLog 2018-04-17 01:20:43 UTC (rev 230694)
+++ trunk/Source/WebCore/ChangeLog 2018-04-17 01:56:15 UTC (rev 230695)
@@ -1,3 +1,16 @@
+2018-04-16 Filip Pizlo
+
+MutationObserver should be in an IsoHeap
+https://bugs.webkit.org/show_bug.cgi?id=184671
+
+
+Reviewed by Sam Weinig.
+
+No new tests because no new behavior.
+
+* dom/MutationObserver.cpp:
+* dom/MutationObserver.h:
+
2018-04-16 Youenn Fablet
Use NetworkLoadChecker to handle synchronous HTTP loads
Modified: trunk/Source/WebCore/dom/MutationObserver.cpp (230694 => 230695)
--- trunk/Source/WebCore/dom/MutationObserver.cpp 2018-04-17 01:20:43 UTC (rev 230694)
+++ trunk/Source/WebCore/dom/MutationObserver.cpp 2018-04-17 01:56:15 UTC (rev 230695)
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2011 Google Inc. All rights reserved.
+ * Copyright (C) 2018 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are
@@ -39,11 +40,14 @@
#include "MutationObserverRegistration.h"
#include "MutationRecord.h"
#include
+#include
#include
#include
namespace WebCore {
+WTF_MAKE_ISO_ALLOCATED_IMPL(MutationObserver);
+
static unsigned s_observerPriority = 0;
Ref MutationObserver::create(Ref&& callback)
Modified: trunk/Source/WebCore/dom/MutationObserver.h (230694 => 230695)
--- trunk/Source/WebCore/dom/MutationObserver.h 2018-04-17 01:20:43 UTC (rev 230694)
+++ trunk/Source/WebCore/dom/MutationObserver.h 2018-04-17 01:56:15 UTC (rev 230695)
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2011 Google Inc. All rights reserved.
+ * Copyright (C) 2018 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are
@@ -33,6 +34,7 @@
#include "ExceptionOr.h"
#include
#include
+#include
#include
namespace WebCore {
@@ -46,7 +48,8 @@
using MutationObserverOptions = unsigned char;
using MutationRecordDeliveryOptions = unsigned char;
-class MutationObserver : public RefCounted {
+class MutationObserver final : public RefCounted {
+WTF_MAKE_ISO_ALLOCATED(MutationObserver);
friend class MutationObserverMicrotask;
public:
enum MutationType {
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [230662] trunk
Title: [230662] trunk
Revision 230662
Author fpi...@apple.com
Date 2018-04-15 10:38:01 -0700 (Sun, 15 Apr 2018)
Log Message
Function.prototype.caller shouldn't return generator bodies
https://bugs.webkit.org/show_bug.cgi?id=184630
Reviewed by Yusuke Suzuki.
JSTests:
* stress/function-caller-async-arrow-function-body.js: Added.
* stress/function-caller-async-function-body.js: Added.
* stress/function-caller-async-generator-body.js: Added.
* stress/function-caller-generator-body.js: Added.
* stress/function-caller-generator-method-body.js: Added.
Source/_javascript_Core:
Function.prototype.caller no longer returns generator bodies. Those are meant to be
private.
Also added some builtin debugging tools so that it's easier to do the investigation that I
did.
* builtins/BuiltinNames.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::callerGetter):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncBuiltinDescribe):
* runtime/JSGlobalObjectFunctions.h:
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/builtins/BuiltinNames.h
trunk/Source/_javascript_Core/runtime/JSFunction.cpp
trunk/Source/_javascript_Core/runtime/JSGlobalObject.cpp
trunk/Source/_javascript_Core/runtime/JSGlobalObjectFunctions.cpp
trunk/Source/_javascript_Core/runtime/JSGlobalObjectFunctions.h
Added Paths
trunk/JSTests/stress/function-caller-async-arrow-function-body.js
trunk/JSTests/stress/function-caller-async-function-body.js
trunk/JSTests/stress/function-caller-async-generator-body.js
trunk/JSTests/stress/function-caller-generator-body.js
trunk/JSTests/stress/function-caller-generator-method-body.js
Diff
Modified: trunk/JSTests/ChangeLog (230661 => 230662)
--- trunk/JSTests/ChangeLog 2018-04-15 16:32:26 UTC (rev 230661)
+++ trunk/JSTests/ChangeLog 2018-04-15 17:38:01 UTC (rev 230662)
@@ -1,3 +1,16 @@
+2018-04-14 Filip Pizlo
+
+Function.prototype.caller shouldn't return generator bodies
+https://bugs.webkit.org/show_bug.cgi?id=184630
+
+Reviewed by Yusuke Suzuki.
+
+* stress/function-caller-async-arrow-function-body.js: Added.
+* stress/function-caller-async-function-body.js: Added.
+* stress/function-caller-async-generator-body.js: Added.
+* stress/function-caller-generator-body.js: Added.
+* stress/function-caller-generator-method-body.js: Added.
+
2018-04-12 Tomas Popela
Unreviewed, skip JIT tests if it isn't enabled
Added: trunk/JSTests/stress/function-caller-async-arrow-function-body.js (0 => 230662)
--- trunk/JSTests/stress/function-caller-async-arrow-function-body.js (rev 0)
+++ trunk/JSTests/stress/function-caller-async-arrow-function-body.js 2018-04-15 17:38:01 UTC (rev 230662)
@@ -0,0 +1,26 @@
+//@ runDefault
+
+(function thingy() {
+function bar()
+{
+return bar.caller;
+}
+
+var ok = false;
+var badError = null;
+var foo = async () => {
+try {
+bar();
+ok = true;
+} catch (e) {
+if (e.toString() != "TypeError: Function.caller used to retrieve async function body")
+badError = e;
+}
+}
+
+foo();
+if (ok)
+throw "Error: did not throw error";
+if (badError)
+throw "Bad error: " + badError;
+})();
Added: trunk/JSTests/stress/function-caller-async-function-body.js (0 => 230662)
--- trunk/JSTests/stress/function-caller-async-function-body.js (rev 0)
+++ trunk/JSTests/stress/function-caller-async-function-body.js 2018-04-15 17:38:01 UTC (rev 230662)
@@ -0,0 +1,27 @@
+//@ runDefault
+
+(function thingy() {
+function bar()
+{
+return bar.caller;
+}
+
+var ok = false;
+var badError = null;
+async function foo()
+{
+try {
+bar();
+ok = true;
+} catch (e) {
+if (e.toString() != "TypeError: Function.caller used to retrieve async function body")
+badError = e;
+}
+}
+
+foo();
+if (ok)
+throw "Error: did not throw error";
+if (badError)
+throw "Bad error: " + badError;
+})();
Added: trunk/JSTests/stress/function-caller-async-generator-body.js (0 => 230662)
--- trunk/JSTests/stress/function-caller-async-generator-body.js (rev 0)
+++ trunk/JSTests/stress/function-caller-async-generator-body.js 2018-04-15 17:38:01 UTC (rev 230662)
@@ -0,0 +1,27 @@
+//@ runDefault
+
+(function thingy() {
+function bar()
+{
+return bar.caller;
+}
+
+var ok = false;
+var badError = null;
+async function* foo()
+{
+try {
+bar();
+ok = true;
+} catch (e) {
+if (e.toString() != "TypeError: Function.caller used to retrieve generator body")
+badError =
[webkit-changes] [230494] trunk/Source/JavaScriptCore
Title: [230494] trunk/Source/_javascript_Core
Revision 230494
Author fpi...@apple.com
Date 2018-04-10 14:16:21 -0700 (Tue, 10 Apr 2018)
Log Message
Unreviewed, fix cloop build.
* dfg/DFGAbstractInterpreterClobberState.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterClobberState.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (230493 => 230494)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-10 21:13:55 UTC (rev 230493)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-10 21:16:21 UTC (rev 230494)
@@ -1,3 +1,9 @@
+2018-04-10 Filip Pizlo
+
+Unreviewed, fix cloop build.
+
+* dfg/DFGAbstractInterpreterClobberState.cpp:
+
2018-04-10 Mark Lam
Make the ASSERT in MarkedSpace::sizeClassToIndex() a RELEASE_ASSERT.
Modified: trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterClobberState.cpp (230493 => 230494)
--- trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterClobberState.cpp 2018-04-10 21:13:55 UTC (rev 230493)
+++ trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterClobberState.cpp 2018-04-10 21:16:21 UTC (rev 230494)
@@ -26,6 +26,8 @@
#include "config.h"
#include "DFGAbstractInterpreterClobberState.h"
+#if ENABLE(DFG_JIT)
+
#include
namespace WTF {
@@ -51,3 +53,4 @@
} // namespace WTF
+#endif // ENABLE(DFG_JIT)
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [230488] trunk
Title: [230488] trunk Revision 230488 Author fpi...@apple.com Date 2018-04-10 12:45:54 -0700 (Tue, 10 Apr 2018) Log Message DFG AI and clobberize should agree with each other https://bugs.webkit.org/show_bug.cgi?id=184440 Reviewed by Saam Barati. JSTests: Add tests for all of the bugs I fixed. * stress/direct-arguments-out-of-bounds-change-structure.js: Added. (foo): * stress/new-typed-array-cse-effects.js: Added. (foo): * stress/scoped-arguments-out-of-bounds-change-structure.js: Added. (foo.theO): (foo): * stress/string-from-char-code-change-structure-not-dead.js: Added. (foo): (i.valueOf): (weirdValue.valueOf): * stress/string-from-char-code-change-structure.js: Added. (foo): (i.valueOf): (weirdValue.valueOf): Source/_javascript_Core: One way to fix bugs involving underapproximation in AI or clobberize is to assert that they agree with each other. That's what this patch does: it adds an assertion that AI's structure state tracking must be equivalent to JSCell_structureID being clobbered. One subtlety is that AI sometimes folds away structure clobbering using information that clobberize doesn't have. So, we track this wuth special kinds of AI states (FoldedClobber and ObservedTransitions). This fixes a bunch of cases of AI missing clobberStructures/clobberWorld and one case of clobberize missing a write(Heap). This also makes some cases more precise in order to appease the assertion. Making things more precise might make things faster, but I didn't measure it because that wasn't the goal. * _javascript_Core.xcodeproj/project.pbxproj: * Sources.txt: * dfg/DFGAbstractInterpreter.h: * dfg/DFGAbstractInterpreterClobberState.cpp: Added. (WTF::printInternal): * dfg/DFGAbstractInterpreterClobberState.h: Added. (JSC::DFG::mergeClobberStates): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::startExecuting): (JSC::DFG::AbstractInterpreter::executeEffects): (JSC::DFG::AbstractInterpreter::didFoldClobberWorld): (JSC::DFG::AbstractInterpreter::clobberStructures): (JSC::DFG::AbstractInterpreter::didFoldClobberStructures): (JSC::DFG::AbstractInterpreter::observeTransition): (JSC::DFG::AbstractInterpreter::observeTransitions): (JSC::DFG::AbstractInterpreter::setDidClobber): Deleted. * dfg/DFGAtTailAbstractState.h: (JSC::DFG::AtTailAbstractState::setClobberState): (JSC::DFG::AtTailAbstractState::mergeClobberState): (JSC::DFG::AtTailAbstractState::setDidClobber): Deleted. * dfg/DFGCFAPhase.cpp: (JSC::DFG::CFAPhase::performBlockCFA): * dfg/DFGClobberSet.cpp: (JSC::DFG::writeSet): * dfg/DFGClobberSet.h: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGInPlaceAbstractState.h: (JSC::DFG::InPlaceAbstractState::clobberState const): (JSC::DFG::InPlaceAbstractState::didClobberOrFolded const): (JSC::DFG::InPlaceAbstractState::didClobber const): (JSC::DFG::InPlaceAbstractState::setClobberState): (JSC::DFG::InPlaceAbstractState::mergeClobberState): (JSC::DFG::InPlaceAbstractState::setDidClobber): Deleted. Modified Paths trunk/JSTests/ChangeLog trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj trunk/Source/_javascript_Core/Sources.txt trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreter.h trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h trunk/Source/_javascript_Core/dfg/DFGAtTailAbstractState.h trunk/Source/_javascript_Core/dfg/DFGCFAPhase.cpp trunk/Source/_javascript_Core/dfg/DFGClobberSet.cpp trunk/Source/_javascript_Core/dfg/DFGClobberSet.h trunk/Source/_javascript_Core/dfg/DFGClobberize.h trunk/Source/_javascript_Core/dfg/DFGConstantFoldingPhase.cpp trunk/Source/_javascript_Core/dfg/DFGFixupPhase.cpp trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.h trunk/Source/_javascript_Core/dfg/DFGNodeType.h Added Paths trunk/JSTests/stress/direct-arguments-out-of-bounds-change-structure.js trunk/JSTests/stress/new-typed-array-cse-effects.js trunk/JSTests/stress/scoped-arguments-out-of-bounds-change-structure.js trunk/JSTests/stress/string-from-char-code-change-structure-not-dead.js trunk/JSTests/stress/string-from-char-code-change-structure.js trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterClobberState.cpp trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterClobberState.h Diff Modified: trunk/JSTests/ChangeLog (230487 => 230488) --- trunk/JSTests/ChangeLog 2018-04-10 19:42:35 UTC (rev 230487) +++ trunk/JSTests/ChangeLog 2018-04-10 19:45:54 UTC (rev 230488) @@ -1,3 +1,28 @@ +2018-04-10 Filip Pizlo + +DFG AI and clobberize should agree with each other +https://bugs.webkit.org/show_bug.cgi?id=184440 + +Reviewed by Saam Barati. + +Add tests for all of the bugs I fixed. + +* stress/direct-arguments-out-of-bounds-change-structure.js: Added. +(foo): +* stress/new-typed-array-cse-effects.js: Added. +
[webkit-changes] [230486] trunk/Source/JavaScriptCore
Title: [230486] trunk/Source/_javascript_Core
Revision 230486
Author fpi...@apple.com
Date 2018-04-10 11:04:07 -0700 (Tue, 10 Apr 2018)
Log Message
ExecutableToCodeBlockEdge::visitChildren() should be cool with m_codeBlock being null since we clear it in finalizeUnconditionally()
https://bugs.webkit.org/show_bug.cgi?id=184460
Reviewed by Mark Lam.
* bytecode/ExecutableToCodeBlockEdge.cpp:
(JSC::ExecutableToCodeBlockEdge::visitChildren):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/ExecutableToCodeBlockEdge.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (230485 => 230486)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-10 17:57:29 UTC (rev 230485)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-10 18:04:07 UTC (rev 230486)
@@ -1,5 +1,16 @@
2018-04-10 Filip Pizlo
+ExecutableToCodeBlockEdge::visitChildren() should be cool with m_codeBlock being null since we clear it in finalizeUnconditionally()
+https://bugs.webkit.org/show_bug.cgi?id=184460
+
+
+Reviewed by Mark Lam.
+
+* bytecode/ExecutableToCodeBlockEdge.cpp:
+(JSC::ExecutableToCodeBlockEdge::visitChildren):
+
+2018-04-10 Filip Pizlo
+
REGRESSION(r227341 and r227742): AI and clobberize should be precise and consistent about the effectfulness of CompareEq
https://bugs.webkit.org/show_bug.cgi?id=184455
Modified: trunk/Source/_javascript_Core/bytecode/ExecutableToCodeBlockEdge.cpp (230485 => 230486)
--- trunk/Source/_javascript_Core/bytecode/ExecutableToCodeBlockEdge.cpp 2018-04-10 17:57:29 UTC (rev 230485)
+++ trunk/Source/_javascript_Core/bytecode/ExecutableToCodeBlockEdge.cpp 2018-04-10 18:04:07 UTC (rev 230486)
@@ -50,6 +50,13 @@
ExecutableToCodeBlockEdge* edge = jsCast(cell);
CodeBlock* codeBlock = edge->m_codeBlock.get();
+// It's possible for someone to hold a pointer to the edge after the edge has cleared its weak
+// reference to the codeBlock. In a conservative GC like ours, that could happen at random for
+// no good reason and it's Totally OK (TM). See finalizeUnconditionally() for where we clear
+// m_codeBlock.
+if (!codeBlock)
+return;
+
if (!edge->m_isActive) {
visitor.appendUnbarriered(codeBlock);
return;
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [230485] trunk/Source/JavaScriptCore
Title: [230485] trunk/Source/_javascript_Core
Revision 230485
Author fpi...@apple.com
Date 2018-04-10 10:57:29 -0700 (Tue, 10 Apr 2018)
Log Message
REGRESSION(r227341 and r227742): AI and clobberize should be precise and consistent about the effectfulness of CompareEq
https://bugs.webkit.org/show_bug.cgi?id=184455
Reviewed by Michael Saboff.
LICM is sort of an assertion that AI is as precise as clobberize about effects. If clobberize
says that something is not effectful, then LICM will try to hoist it. But LICM's AI hack
(AtTailAbstractState) cannot handle hoisting of things that have effects. So, if AI thinks that
the thing being hoisted does have effects, then we get a crash.
In r227341, we incorrectly told AI that CompareEq(Untyped:, _) is effectful. In fact, only
ComapreEq(Untyped:, Untyped:) is effectful, and clobberize knew this already. As a result, LICM
would blow up if we hoisted CompareEq(Untyped:, Other:), which clobberize knew wasn't
effectful.
Instead of fixing this by making AI precise, in r227742 we made matters worse by then breaking
clobberize to also think that CompareEq(Untyped:, _) is effectful.
This fixes the whole situation by teaching both clobberize and AI that the only effectful form
of CompareEq is ComapreEq(Untyped:, Untyped:).
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h
trunk/Source/_javascript_Core/dfg/DFGClobberize.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (230484 => 230485)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-10 17:21:50 UTC (rev 230484)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-10 17:57:29 UTC (rev 230485)
@@ -1,3 +1,31 @@
+2018-04-10 Filip Pizlo
+
+REGRESSION(r227341 and r227742): AI and clobberize should be precise and consistent about the effectfulness of CompareEq
+https://bugs.webkit.org/show_bug.cgi?id=184455
+
+Reviewed by Michael Saboff.
+
+LICM is sort of an assertion that AI is as precise as clobberize about effects. If clobberize
+says that something is not effectful, then LICM will try to hoist it. But LICM's AI hack
+(AtTailAbstractState) cannot handle hoisting of things that have effects. So, if AI thinks that
+the thing being hoisted does have effects, then we get a crash.
+
+In r227341, we incorrectly told AI that CompareEq(Untyped:, _) is effectful. In fact, only
+ComapreEq(Untyped:, Untyped:) is effectful, and clobberize knew this already. As a result, LICM
+would blow up if we hoisted CompareEq(Untyped:, Other:), which clobberize knew wasn't
+effectful.
+
+Instead of fixing this by making AI precise, in r227742 we made matters worse by then breaking
+clobberize to also think that CompareEq(Untyped:, _) is effectful.
+
+This fixes the whole situation by teaching both clobberize and AI that the only effectful form
+of CompareEq is ComapreEq(Untyped:, Untyped:).
+
+* dfg/DFGAbstractInterpreterInlines.h:
+(JSC::DFG::AbstractInterpreter::executeEffects):
+* dfg/DFGClobberize.h:
+(JSC::DFG::clobberize):
+
2018-04-09 Filip Pizlo
Executing known edge types may reveal a contradiction causing us to emit an exit at a node that is not allowed to exit
Modified: trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h (230484 => 230485)
--- trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h 2018-04-10 17:21:50 UTC (rev 230484)
+++ trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h 2018-04-10 17:57:29 UTC (rev 230485)
@@ -1636,7 +1636,7 @@
}
}
-if (node->child1().useKind() == UntypedUse || node->child2().useKind() == UntypedUse)
+if (node->isBinaryUseKind(UntypedUse))
clobberWorld(node->origin.semantic, clobberLimit);
forNode(node).setType(SpecBoolean);
break;
Modified: trunk/Source/_javascript_Core/dfg/DFGClobberize.h (230484 => 230485)
--- trunk/Source/_javascript_Core/dfg/DFGClobberize.h 2018-04-10 17:21:50 UTC (rev 230484)
+++ trunk/Source/_javascript_Core/dfg/DFGClobberize.h 2018-04-10 17:57:29 UTC (rev 230485)
@@ -1537,13 +1537,8 @@
write(HeapObjectCount);
return;
}
-
-if (node->op() == CompareEq && node->isBinaryUseKind(ObjectUse)) {
-def(PureValue(node));
-return;
-}
-if (node->child1().useKind() == UntypedUse || node->child1().useKind() == ObjectUse
-|| node->child2().useKind() == UntypedUse || node->child2().useKind() == ObjectUse) {
+
+if (node->isBinaryUseKind(UntypedUse)) {
read(World);
write(Heap);
[webkit-changes] [230465] trunk/Source/JavaScriptCore
Title: [230465] trunk/Source/_javascript_Core
Revision 230465
Author fpi...@apple.com
Date 2018-04-09 19:42:27 -0700 (Mon, 09 Apr 2018)
Log Message
Executing known edge types may reveal a contradiction causing us to emit an exit at a node that is not allowed to exit
https://bugs.webkit.org/show_bug.cgi?id=184372
Reviewed by Saam Barati.
We do a pretty good job of not emitting checks for KnownBlah edges, since those mean that we
have already proved, using techniques that are more precise than AI, that the edge has type
Blah. Unfortunately, we do not handle this case gracefully when AI state becomes bottom,
because we have a bad habit of treating terminate/terminateSpeculativeExecution as something
other than a check - so we think we can call those just because we should have already
bailed. It's better to think of them as the result of folding a check. Therefore, we should
only do it if there had been a check to begin with.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
(JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
(JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lowInt32):
(JSC::FTL::DFG::LowerDFGToB3::lowInt52):
(JSC::FTL::DFG::LowerDFGToB3::lowCell):
(JSC::FTL::DFG::LowerDFGToB3::lowBoolean):
(JSC::FTL::DFG::LowerDFGToB3::lowDouble):
(JSC::FTL::DFG::LowerDFGToB3::speculate):
(JSC::FTL::DFG::LowerDFGToB3::speculateCellOrOther):
(JSC::FTL::DFG::LowerDFGToB3::speculateStringOrOther):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (230464 => 230465)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-10 01:53:00 UTC (rev 230464)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-10 02:42:27 UTC (rev 230465)
@@ -1,3 +1,34 @@
+2018-04-09 Filip Pizlo
+
+Executing known edge types may reveal a contradiction causing us to emit an exit at a node that is not allowed to exit
+https://bugs.webkit.org/show_bug.cgi?id=184372
+
+Reviewed by Saam Barati.
+
+We do a pretty good job of not emitting checks for KnownBlah edges, since those mean that we
+have already proved, using techniques that are more precise than AI, that the edge has type
+Blah. Unfortunately, we do not handle this case gracefully when AI state becomes bottom,
+because we have a bad habit of treating terminate/terminateSpeculativeExecution as something
+other than a check - so we think we can call those just because we should have already
+bailed. It's better to think of them as the result of folding a check. Therefore, we should
+only do it if there had been a check to begin with.
+
+* dfg/DFGSpeculativeJIT64.cpp:
+(JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
+(JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
+(JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
+(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
+(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
+* ftl/FTLLowerDFGToB3.cpp:
+(JSC::FTL::DFG::LowerDFGToB3::lowInt32):
+(JSC::FTL::DFG::LowerDFGToB3::lowInt52):
+(JSC::FTL::DFG::LowerDFGToB3::lowCell):
+(JSC::FTL::DFG::LowerDFGToB3::lowBoolean):
+(JSC::FTL::DFG::LowerDFGToB3::lowDouble):
+(JSC::FTL::DFG::LowerDFGToB3::speculate):
+(JSC::FTL::DFG::LowerDFGToB3::speculateCellOrOther):
+(JSC::FTL::DFG::LowerDFGToB3::speculateStringOrOther):
+
2018-04-08 Yusuke Suzuki
[JSC] Introduce @putByIdDirectPrivate
Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp (230464 => 230465)
--- trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp 2018-04-10 01:53:00 UTC (rev 230464)
+++ trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp 2018-04-10 02:42:27 UTC (rev 230465)
@@ -1088,7 +1088,8 @@
m_interpreter.filter(value, SpecInt32Only);
if (value.isClear()) {
-terminateSpeculativeExecution(Uncountable, JSValueRegs(), 0);
+if (mayHaveTypeCheck(edge.useKind()))
+terminateSpeculativeExecution(Uncountable, JSValueRegs(), 0);
returnFormat = DataFormatInt32;
return allocate();
}
@@ -1232,7 +1233,8 @@
m_interpreter.filter(value, SpecAnyInt);
if (value.isClear()) {
-terminateSpeculativeExecution(Uncountable, JSValueRegs(), 0);
+if (mayHaveTypeCheck(edge.useKind()))
+terminateSpeculativeExecution(Uncountable, JSValueRegs(), 0);
return allocate();
}
@@ -1339,7 +1341,8 @@
info.fillDouble(*m_stream, fpr);
return fpr;
}
-terminateSpeculativeExecution(U
[webkit-changes] [230287] trunk
Title: [230287] trunk
Revision 230287
Author fpi...@apple.com
Date 2018-04-04 17:30:48 -0700 (Wed, 04 Apr 2018)
Log Message
REGRESSION(r222563): removed DoubleReal type check causes tons of crashes because CSE has never known how to handle SaneChain
https://bugs.webkit.org/show_bug.cgi?id=184319
Reviewed by Saam Barati.
JSTests:
* stress/array-push-nan-to-double-array-cse-sane-and-insane-chain.js: Added.
(foo):
(bar):
* stress/array-push-nan-to-double-array.js: Added.
(foo):
(bar):
Source/_javascript_Core:
In r222581, we replaced type checks about DoubleReal in ArrayPush in the DFG/FTL backends with
assertions. That's correct because FixupPhase was emitting those checks as Check(DoubleRealRep:) before
the ArrayPush.
But this revealed a longstanding CSE bug: CSE will happily match a SaneChain GetByVal with a InBounds
GetByVal. SaneChain can return NaN while InBounds cannot. This means that if we first use AI to
eliminate the Check(DoubleRealRep:) based on the input being a GetByVal(InBounds) but then replace that
with a GetByVal(SaneChain), then we will hit the assertion.
This teaches CSE to not replace GetByVal(InBounds) with GetByVal(SaneChain) and vice versa. That gets
tricky because PutByVal can match either. So, we use the fact that it's legal for a store to def() more
than once: PutByVal now defs() a HeapLocation for InBounds and a HeapLocation for SaneChain.
* dfg/DFGCSEPhase.cpp:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArrayPush):
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGCSEPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGClobberize.h
trunk/Source/_javascript_Core/dfg/DFGHeapLocation.cpp
trunk/Source/_javascript_Core/dfg/DFGHeapLocation.h
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
Added Paths
trunk/JSTests/stress/array-push-nan-to-double-array-cse-sane-and-insane-chain.js
trunk/JSTests/stress/array-push-nan-to-double-array.js
Diff
Modified: trunk/JSTests/ChangeLog (230286 => 230287)
--- trunk/JSTests/ChangeLog 2018-04-05 00:22:09 UTC (rev 230286)
+++ trunk/JSTests/ChangeLog 2018-04-05 00:30:48 UTC (rev 230287)
@@ -1,3 +1,17 @@
+2018-04-04 Filip Pizlo
+
+REGRESSION(r222563): removed DoubleReal type check causes tons of crashes because CSE has never known how to handle SaneChain
+https://bugs.webkit.org/show_bug.cgi?id=184319
+
+Reviewed by Saam Barati.
+
+* stress/array-push-nan-to-double-array-cse-sane-and-insane-chain.js: Added.
+(foo):
+(bar):
+* stress/array-push-nan-to-double-array.js: Added.
+(foo):
+(bar):
+
2018-04-03 Mark Lam
Test js-fixed-array-out-of-memory.js should be excluded for memory limited devices.
Added: trunk/JSTests/stress/array-push-nan-to-double-array-cse-sane-and-insane-chain.js (0 => 230287)
--- trunk/JSTests/stress/array-push-nan-to-double-array-cse-sane-and-insane-chain.js (rev 0)
+++ trunk/JSTests/stress/array-push-nan-to-double-array-cse-sane-and-insane-chain.js 2018-04-05 00:30:48 UTC (rev 230287)
@@ -0,0 +1,23 @@
+function foo(array, otherArray, i)
+{
+var x = otherArray[i];
+var y = otherArray[i];
+array.push(y);
+return x / 42;
+}
+
+function bar()
+{
+return [];
+}
+
+noInline(foo);
+noInline(bar);
+
+for (var i = 0; i < 1; ++i)
+foo(bar(), [42.5], 0);
+
+var result = bar();
+foo(result, [,42.5], 0);
+if (result[0] !== void 0)
+throw "Bad result: " + result;
Added: trunk/JSTests/stress/array-push-nan-to-double-array.js (0 => 230287)
--- trunk/JSTests/stress/array-push-nan-to-double-array.js (rev 0)
+++ trunk/JSTests/stress/array-push-nan-to-double-array.js 2018-04-05 00:30:48 UTC (rev 230287)
@@ -0,0 +1,20 @@
+function foo(array, num, denum)
+{
+array.push(num/denum);
+}
+
+function bar()
+{
+return [];
+}
+
+noInline(foo);
+noInline(bar);
+
+for (var i = 0; i < 1; ++i)
+foo(bar(), 42.5, 3.1);
+
+var result = bar();
+foo(result, 0, 0);
+if ("" + result[0] !== "NaN")
+throw "Bad result: " + result;
Modified: trunk/Source/_javascript_Core/ChangeLog (230286 => 230287)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-05 00:22:09 UTC (rev 230286)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-05 00:30:48 UTC (rev 230287)
@@ -1,5 +1,34 @@
2018-04-04 Filip Pizlo
+REGRESSION(r222563): removed DoubleReal type check causes tons of crashes because CSE has never known how to handle SaneChain
+https://bugs.webkit.org/show_bug.cgi?id=184319
+
+Reviewed by Saam Barati.
+
+In r222581, we replaced type checks about DoubleReal in ArrayPush in the DFG/FTL backends with
+assertions. That's correct because FixupPhase was emitting t
[webkit-changes] [230273] trunk/Source/JavaScriptCore
Title: [230273] trunk/Source/_javascript_Core Revision 230273 Author fpi...@apple.com Date 2018-04-04 13:29:43 -0700 (Wed, 04 Apr 2018) Log Message Remove poisoning of typed array vector https://bugs.webkit.org/show_bug.cgi?id=184313 Reviewed by Saam Barati. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::checkArray): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds): (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage): (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset): (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered): * jit/IntrinsicEmitter.cpp: (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitIntTypedArrayGetByVal): (JSC::JIT::emitFloatTypedArrayGetByVal): (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/arm64.rb: * offlineasm/x86.rb: * runtime/CagedBarrierPtr.h: * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::JSArrayBufferView): (JSC::JSArrayBufferView::finalize): (JSC::JSArrayBufferView::neuter): * runtime/JSArrayBufferView.h: (JSC::JSArrayBufferView::vector const): (JSC::JSArrayBufferView::offsetOfVector): (JSC::JSArrayBufferView::offsetOfPoisonedVector): Deleted. (JSC::JSArrayBufferView::poisonFor): Deleted. (JSC::JSArrayBufferView::Poison::key): Deleted. * runtime/JSCPoison.cpp: (JSC::initializePoison): * runtime/JSCPoison.h: * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::estimatedSize): (JSC::JSGenericTypedArrayView::visitChildren): (JSC::JSGenericTypedArrayView::slowDownAndWasteMemory): * runtime/JSObject.h: Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/dfg/DFGFixupPhase.cpp trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp trunk/Source/_javascript_Core/ftl/FTLAbstractHeapRepository.h trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp trunk/Source/_javascript_Core/jit/IntrinsicEmitter.cpp trunk/Source/_javascript_Core/jit/JITPropertyAccess.cpp trunk/Source/_javascript_Core/llint/LowLevelInterpreter.asm trunk/Source/_javascript_Core/llint/LowLevelInterpreter64.asm trunk/Source/_javascript_Core/offlineasm/arm64.rb trunk/Source/_javascript_Core/offlineasm/x86.rb trunk/Source/_javascript_Core/runtime/CagedBarrierPtr.h trunk/Source/_javascript_Core/runtime/JSArrayBufferView.cpp trunk/Source/_javascript_Core/runtime/JSArrayBufferView.h trunk/Source/_javascript_Core/runtime/JSCPoison.cpp trunk/Source/_javascript_Core/runtime/JSCPoison.h trunk/Source/_javascript_Core/runtime/JSGenericTypedArrayViewInlines.h trunk/Source/_javascript_Core/runtime/JSObject.h Diff Modified: trunk/Source/_javascript_Core/ChangeLog (230272 => 230273) --- trunk/Source/_javascript_Core/ChangeLog 2018-04-04 20:19:01 UTC (rev 230272) +++ trunk/Source/_javascript_Core/ChangeLog 2018-04-04 20:29:43 UTC (rev 230273) @@ -1,3 +1,54 @@ +2018-04-04 Filip Pizlo + +Remove poisoning of typed array vector +https://bugs.webkit.org/show_bug.cgi?id=184313 + +Reviewed by Saam Barati. + +* dfg/DFGFixupPhase.cpp: +(JSC::DFG::FixupPhase::checkArray): +* dfg/DFGSpeculativeJIT.cpp: +(JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds): +(JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): +(JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): +(JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize): +* ftl/FTLAbstractHeapRepository.h: +* ftl/FTLLowerDFGToB3.cpp: +(JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage): +(JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset): +(JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): +(JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered): +* jit/IntrinsicEmitter.cpp: +(JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter): +* jit/JITPropertyAccess.cpp: +(JSC::JIT::emitIntTypedArrayGetByVal): +(JSC::JIT::emitFloatTypedArrayGetByVal): +(JSC::JIT::emitIntTypedArrayPutByVal): +(JSC::JIT::emitFloatTypedArrayPutByVal): +* llint/LowLevelInterpreter.asm: +* llint/LowLevelInterpreter64.asm: +* offlineasm/arm64.rb: +* offlineasm/x86.rb: +* runtime/CagedBarrierPtr.h: +* runtime/JSArrayBufferView.cpp: +(JSC::JSArrayBufferView::JSArrayBufferView): +(JSC::JSArrayBufferView::finalize): +(JSC::JSArrayBufferView::neuter): +* runtime/JSArrayBufferView.h: +(JSC::J
[webkit-changes] [230266] trunk/Source/JavaScriptCore
Title: [230266] trunk/Source/_javascript_Core Revision 230266 Author fpi...@apple.com Date 2018-04-04 10:55:44 -0700 (Wed, 04 Apr 2018) Log Message Don't do index masking or poisoning for DirectArguments https://bugs.webkit.org/show_bug.cgi?id=184280 Reviewed by Saam Barati. * _javascript_Core.xcodeproj/project.pbxproj: * bytecode/AccessCase.cpp: (JSC::AccessCase::generateWithGuard): * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h: (JSC::DFG::CallCreateDirectArgumentsSlowPathGenerator::CallCreateDirectArgumentsSlowPathGenerator): * dfg/DFGCallCreateDirectArgumentsWithKnownLengthSlowPathGenerator.h: Removed. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments): (JSC::DFG::SpeculativeJIT::compileGetArrayLength): (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments): (JSC::DFG::SpeculativeJIT::compileGetFromArguments): (JSC::DFG::SpeculativeJIT::compilePutToArguments): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments): (JSC::FTL::DFG::LowerDFGToB3::compileGetFromArguments): (JSC::FTL::DFG::LowerDFGToB3::compilePutToArguments): (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass): (JSC::FTL::DFG::LowerDFGToB3::dynamicPoison): (JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnLoadedType): (JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnType): (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedHeapCell): Deleted. * heap/SecurityKind.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_from_arguments): (JSC::JIT::emit_op_put_to_arguments): (JSC::JIT::emitDirectArgumentsGetByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_from_arguments): (JSC::JIT::emit_op_put_to_arguments): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/DirectArguments.cpp: (JSC::DirectArguments::DirectArguments): (JSC::DirectArguments::createUninitialized): (JSC::DirectArguments::create): (JSC::DirectArguments::createByCopying): (JSC::DirectArguments::estimatedSize): (JSC::DirectArguments::visitChildren): (JSC::DirectArguments::overrideThings): (JSC::DirectArguments::copyToArguments): (JSC::DirectArguments::mappedArgumentsSize): * runtime/DirectArguments.h: * runtime/JSCPoison.h: * runtime/JSLexicalEnvironment.h: * runtime/JSSymbolTableObject.h: Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj trunk/Source/_javascript_Core/bytecode/AccessCase.cpp trunk/Source/_javascript_Core/dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp trunk/Source/_javascript_Core/ftl/FTLAbstractHeapRepository.h trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp trunk/Source/_javascript_Core/jit/JITPropertyAccess.cpp trunk/Source/_javascript_Core/jit/JITPropertyAccess32_64.cpp trunk/Source/_javascript_Core/llint/LowLevelInterpreter.asm trunk/Source/_javascript_Core/llint/LowLevelInterpreter32_64.asm trunk/Source/_javascript_Core/llint/LowLevelInterpreter64.asm trunk/Source/_javascript_Core/runtime/DirectArguments.cpp trunk/Source/_javascript_Core/runtime/DirectArguments.h trunk/Source/_javascript_Core/runtime/JSCPoison.h trunk/Source/_javascript_Core/runtime/JSLexicalEnvironment.h trunk/Source/_javascript_Core/runtime/JSSymbolTableObject.h trunk/Source/_javascript_Core/runtime/VM.cpp trunk/Source/_javascript_Core/runtime/VM.h Removed Paths trunk/Source/_javascript_Core/dfg/DFGCallCreateDirectArgumentsWithKnownLengthSlowPathGenerator.h Diff Modified: trunk/Source/_javascript_Core/ChangeLog (230265 => 230266) --- trunk/Source/_javascript_Core/ChangeLog 2018-04-04 17:43:55 UTC (rev 230265) +++ trunk/Source/_javascript_Core/ChangeLog 2018-04-04 17:55:44 UTC (rev 230266) @@ -1,5 +1,62 @@ 2018-04-03 Filip Pizlo +Don't do index masking or poisoning for DirectArguments +https://bugs.webkit.org/show_bug.cgi?id=184280 + +Reviewed by Saam Barati. + +* _javascript_Core.xcodeproj/project.pbxproj: +* bytecode/AccessCase.cpp: +(JSC::AccessCase::generateWithGuard): +* dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h: +(JSC::DFG::CallCreateDirectArgumentsSlowPathGenerator::CallCreateDirectArgumentsSlowPathGenerator): +* dfg/DFGCallCreateDirectArgumentsWithKnownLengthSlowPathGenerator.h: Removed. +* dfg/DFGSpeculativeJIT.cpp: +(JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments): +(JSC::DFG::SpeculativeJIT::compileGetArrayLength): +(JSC::DFG::SpeculativeJIT::compileCreateDirectArguments): +(JSC::DFG::SpeculativeJIT::compileGetFromArguments): +(JSC::DFG::SpeculativeJIT::compilePutToArguments): +* ftl/FTLAbstractHeapRepository.h: +* ftl/FTLLowerDFGToB3.cpp: +(JSC::FTL::DFG::LowerDF
[webkit-changes] [230264] trunk/Source/JavaScriptCore
Title: [230264] trunk/Source/_javascript_Core
Revision 230264
Author fpi...@apple.com
Date 2018-04-04 10:42:11 -0700 (Wed, 04 Apr 2018)
Log Message
JSArray::appendMemcpy seems to be missing a barrier
https://bugs.webkit.org/show_bug.cgi?id=184290
Reviewed by Mark Lam.
If you write to an array that may contain pointers and you didn't just allocate it, then you need to
barrier right after.
I don't know if this is really a bug - it's possible that all callers of appendMemcpy do things that
obviate the need for this barrier. But these barriers are cheap, so we should do them if in doubt.
* runtime/JSArray.cpp:
(JSC::JSArray::appendMemcpy):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/JSArray.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (230263 => 230264)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-04 17:41:29 UTC (rev 230263)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-04 17:42:11 UTC (rev 230264)
@@ -1,5 +1,21 @@
2018-04-03 Filip Pizlo
+JSArray::appendMemcpy seems to be missing a barrier
+https://bugs.webkit.org/show_bug.cgi?id=184290
+
+Reviewed by Mark Lam.
+
+If you write to an array that may contain pointers and you didn't just allocate it, then you need to
+barrier right after.
+
+I don't know if this is really a bug - it's possible that all callers of appendMemcpy do things that
+obviate the need for this barrier. But these barriers are cheap, so we should do them if in doubt.
+
+* runtime/JSArray.cpp:
+(JSC::JSArray::appendMemcpy):
+
+2018-04-03 Filip Pizlo
+
GC shouldn't do object distancing
https://bugs.webkit.org/show_bug.cgi?id=184195
Modified: trunk/Source/_javascript_Core/runtime/JSArray.cpp (230263 => 230264)
--- trunk/Source/_javascript_Core/runtime/JSArray.cpp 2018-04-04 17:41:29 UTC (rev 230263)
+++ trunk/Source/_javascript_Core/runtime/JSArray.cpp 2018-04-04 17:42:11 UTC (rev 230264)
@@ -554,8 +554,10 @@
}
} else if (type == ArrayWithDouble)
memcpy(butterfly()->contiguousDouble().data() + startIndex, otherArray->butterfly()->contiguousDouble().data(), sizeof(JSValue) * otherLength);
-else
+else {
memcpy(butterfly()->contiguous().data() + startIndex, otherArray->butterfly()->contiguous().data(), sizeof(JSValue) * otherLength);
+vm.heap.writeBarrier(this);
+}
return true;
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [230226] trunk/Source
Title: [230226] trunk/Source Revision 230226 Author fpi...@apple.com Date 2018-04-03 16:52:09 -0700 (Tue, 03 Apr 2018) Log Message GC shouldn't do object distancing https://bugs.webkit.org/show_bug.cgi?id=184195 Reviewed by Saam Barati. Source/_javascript_Core: This rolls out SecurityKind/SecurityOriginToken, but keeps the TLC infrastructure. It seems to be a small speed-up. * CMakeLists.txt: * _javascript_Core.xcodeproj/project.pbxproj: * Sources.txt: * heap/BlockDirectory.cpp: (JSC::BlockDirectory::findBlockForAllocation): (JSC::BlockDirectory::addBlock): * heap/BlockDirectory.h: * heap/CellAttributes.cpp: (JSC::CellAttributes::dump const): * heap/CellAttributes.h: (JSC::CellAttributes::CellAttributes): * heap/LocalAllocator.cpp: (JSC::LocalAllocator::allocateSlowCase): (JSC::LocalAllocator::tryAllocateWithoutCollecting): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::Handle::didAddToDirectory): * heap/MarkedBlock.h: (JSC::MarkedBlock::Handle::securityOriginToken const): Deleted. * heap/SecurityKind.cpp: Removed. * heap/SecurityKind.h: Removed. * heap/SecurityOriginToken.cpp: Removed. * heap/SecurityOriginToken.h: Removed. * heap/ThreadLocalCache.cpp: (JSC::ThreadLocalCache::create): (JSC::ThreadLocalCache::ThreadLocalCache): * heap/ThreadLocalCache.h: (JSC::ThreadLocalCache::securityOriginToken const): Deleted. * runtime/JSDestructibleObjectHeapCellType.cpp: (JSC::JSDestructibleObjectHeapCellType::JSDestructibleObjectHeapCellType): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::JSGlobalObject): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::threadLocalCache const): Deleted. * runtime/JSSegmentedVariableObjectHeapCellType.cpp: (JSC::JSSegmentedVariableObjectHeapCellType::JSSegmentedVariableObjectHeapCellType): * runtime/JSStringHeapCellType.cpp: (JSC::JSStringHeapCellType::JSStringHeapCellType): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): * wasm/js/JSWebAssemblyCodeBlockHeapCellType.cpp: (JSC::JSWebAssemblyCodeBlockHeapCellType::JSWebAssemblyCodeBlockHeapCellType): Source/WebCore: No new tests because no change in behavior. * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * bindings/js/JSDOMGlobalObject.cpp: (WebCore::JSDOMGlobalObject::JSDOMGlobalObject): * bindings/js/JSDOMGlobalObject.h: * bindings/js/JSDOMWindowBase.cpp: (WebCore::JSDOMWindowBase::JSDOMWindowBase): * dom/Document.cpp: (WebCore::Document::threadLocalCache): Deleted. * dom/Document.h: * page/OriginThreadLocalCache.cpp: Removed. * page/OriginThreadLocalCache.h: Removed. Modified Paths trunk/Source/_javascript_Core/CMakeLists.txt trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj trunk/Source/_javascript_Core/Sources.txt trunk/Source/_javascript_Core/heap/BlockDirectory.cpp trunk/Source/_javascript_Core/heap/BlockDirectory.h trunk/Source/_javascript_Core/heap/CellAttributes.cpp trunk/Source/_javascript_Core/heap/CellAttributes.h trunk/Source/_javascript_Core/heap/LocalAllocator.cpp trunk/Source/_javascript_Core/heap/MarkedBlock.cpp trunk/Source/_javascript_Core/heap/MarkedBlock.h trunk/Source/_javascript_Core/heap/ThreadLocalCache.cpp trunk/Source/_javascript_Core/heap/ThreadLocalCache.h trunk/Source/_javascript_Core/runtime/JSDestructibleObjectHeapCellType.cpp trunk/Source/_javascript_Core/runtime/JSGlobalObject.cpp trunk/Source/_javascript_Core/runtime/JSGlobalObject.h trunk/Source/_javascript_Core/runtime/JSSegmentedVariableObjectHeapCellType.cpp trunk/Source/_javascript_Core/runtime/JSStringHeapCellType.cpp trunk/Source/_javascript_Core/runtime/VM.cpp trunk/Source/_javascript_Core/runtime/VM.h trunk/Source/_javascript_Core/runtime/VMEntryScope.cpp trunk/Source/_javascript_Core/wasm/js/JSWebAssemblyCodeBlockHeapCellType.cpp trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/Sources.txt trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj trunk/Source/WebCore/bindings/js/JSDOMGlobalObject.cpp trunk/Source/WebCore/bindings/js/JSDOMGlobalObject.h trunk/Source/WebCore/bindings/js/JSDOMWindowBase.cpp trunk/Source/WebCore/dom/Document.cpp trunk/Source/WebCore/dom/Document.h Removed Paths trunk/Source/_javascript_Core/heap/SecurityKind.cpp trunk/Source/_javascript_Core/heap/SecurityKind.h trunk/Source/_javascript_Core/heap/SecurityOriginToken.cpp trunk/Source/_javascript_Core/heap/SecurityOriginToken.h trunk/Source/WebCore/page/OriginThreadLocalCache.cpp trunk/Source/WebCore/page/OriginThreadLocalCache.h Diff Modified: trunk/Source/_javascript_Core/CMakeLists.txt (230225 => 230226) --- trunk/Source/_javascript_Core/CMakeLists.txt 2018-04-03 23:50:14 UTC (rev 230225) +++ trunk/Source/_javascript_Core/CMakeLists.txt 2018-04-03 23:52:09 UTC (rev 230226) @@ -546,8 +546,6 @@ heap/MutatorState.h heap/RegisterState.h heap/RunningScope.h -heap/SecurityKind.h -heap/SecurityOriginToken.h heap/SimpleMarkingConstraint.h heap/SlotVisitor.h hea
[webkit-changes] [230145] trunk/Source/JavaScriptCore
Title: [230145] trunk/Source/_javascript_Core Revision 230145 Author fpi...@apple.com Date 2018-04-01 12:46:05 -0700 (Sun, 01 Apr 2018) Log Message Raise the for-call inlining threshold to 190 to fix JetStream/richards regression https://bugs.webkit.org/show_bug.cgi?id=184228 Reviewed by Yusuke Suzuki. * runtime/Options.h: Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/runtime/Options.h Diff Modified: trunk/Source/_javascript_Core/ChangeLog (230144 => 230145) --- trunk/Source/_javascript_Core/ChangeLog 2018-04-01 17:57:53 UTC (rev 230144) +++ trunk/Source/_javascript_Core/ChangeLog 2018-04-01 19:46:05 UTC (rev 230145) @@ -1,3 +1,12 @@ +2018-04-01 Filip Pizlo + +Raise the for-call inlining threshold to 190 to fix JetStream/richards regression +https://bugs.webkit.org/show_bug.cgi?id=184228 + +Reviewed by Yusuke Suzuki. + +* runtime/Options.h: + 2018-03-31 Filip Pizlo JSObject shouldn't do index masking Modified: trunk/Source/_javascript_Core/runtime/Options.h (230144 => 230145) --- trunk/Source/_javascript_Core/runtime/Options.h 2018-04-01 17:57:53 UTC (rev 230144) +++ trunk/Source/_javascript_Core/runtime/Options.h 2018-04-01 19:46:05 UTC (rev 230145) @@ -288,7 +288,7 @@ \ v(unsigned, maximumOptimizationCandidateInstructionCount, 10, Normal, nullptr) \ \ -v(unsigned, maximumFunctionForCallInlineCandidateInstructionCount, 180, Normal, nullptr) \ +v(unsigned, maximumFunctionForCallInlineCandidateInstructionCount, 190, Normal, nullptr) \ v(unsigned, maximumFunctionForClosureCallInlineCandidateInstructionCount, 100, Normal, nullptr) \ v(unsigned, maximumFunctionForConstructInlineCandidateInstructionCount, 100, Normal, nullptr) \ \ ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [230143] trunk
Title: [230143] trunk
Revision 230143
Author fpi...@apple.com
Date 2018-04-01 10:08:39 -0700 (Sun, 01 Apr 2018)
Log Message
JSC crash in JIT code with for-of loop and Array/Set iterators
https://bugs.webkit.org/show_bug.cgi?id=183174
Reviewed by Saam Barati.
JSTests:
* microbenchmarks/hoist-get-by-offset-tower-with-inferred-types.js: Added. This test shows that fixing the bug didn't break hoisting of GetByOffset with inferred types. I confirmed that if I did break it, this test slows down by >7x.
(foo):
* stress/hoist-get-by-offset-with-control-dependent-inferred-type.js: Added. This test shows that the bug is fixed.
(f):
Source/_javascript_Core:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute): Fix the bug by making GetByOffset and friends verify that they are getting the type proof they want at the desired hoisting site.
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGSafeToExecute.h
Added Paths
trunk/JSTests/microbenchmarks/hoist-get-by-offset-tower-with-inferred-types.js
trunk/JSTests/stress/hoist-get-by-offset-with-control-dependent-inferred-type.js
Diff
Modified: trunk/JSTests/ChangeLog (230142 => 230143)
--- trunk/JSTests/ChangeLog 2018-04-01 16:47:59 UTC (rev 230142)
+++ trunk/JSTests/ChangeLog 2018-04-01 17:08:39 UTC (rev 230143)
@@ -1,3 +1,15 @@
+2018-03-31 Filip Pizlo
+
+JSC crash in JIT code with for-of loop and Array/Set iterators
+https://bugs.webkit.org/show_bug.cgi?id=183174
+
+Reviewed by Saam Barati.
+
+* microbenchmarks/hoist-get-by-offset-tower-with-inferred-types.js: Added. This test shows that fixing the bug didn't break hoisting of GetByOffset with inferred types. I confirmed that if I did break it, this test slows down by >7x.
+(foo):
+* stress/hoist-get-by-offset-with-control-dependent-inferred-type.js: Added. This test shows that the bug is fixed.
+(f):
+
2018-03-30 JF Bastien
WebAssembly: support DataView compilation
Added: trunk/JSTests/microbenchmarks/hoist-get-by-offset-tower-with-inferred-types.js (0 => 230143)
--- trunk/JSTests/microbenchmarks/hoist-get-by-offset-tower-with-inferred-types.js (rev 0)
+++ trunk/JSTests/microbenchmarks/hoist-get-by-offset-tower-with-inferred-types.js 2018-04-01 17:08:39 UTC (rev 230143)
@@ -0,0 +1,19 @@
+function foo(o)
+{
+var result = 0;
+for (var i = 0; i < 100; ++i)
+result += o.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z;
+return result;
+}
+
+noInline(foo);
+
+for (var i = 0; i < 1000; ++i) {
+var o = {f:{g:{h:{i:{j:{k:{l:{m:{n:{o:{p:{q:{r:{s:{t:{u:{v:{w:{x:{y:{z:42};
+for (var j = 0; j < 100; ++j) {
+var result = foo(o);
+if (result != 4200)
+throw "Bad result in loop: " + result;
+}
+}
+
Added: trunk/JSTests/stress/hoist-get-by-offset-with-control-dependent-inferred-type.js (0 => 230143)
--- trunk/JSTests/stress/hoist-get-by-offset-with-control-dependent-inferred-type.js (rev 0)
+++ trunk/JSTests/stress/hoist-get-by-offset-with-control-dependent-inferred-type.js 2018-04-01 17:08:39 UTC (rev 230143)
@@ -0,0 +1,14 @@
+function f() {
+var a = Array(100).fill(0);
+var ta = new Set(a.map((v,k)=>k));
+var xs = [a, ta];
+var q = 0;
+var t = Date.now();
+for (var i = 0; i < 10; ++i) {
+for (var x of xs[i&1]) q+=x;
+}
+return [Date.now()-t,q];
+}
+noInline(f);
+f();
+
Modified: trunk/Source/_javascript_Core/ChangeLog (230142 => 230143)
--- trunk/Source/_javascript_Core/ChangeLog 2018-04-01 16:47:59 UTC (rev 230142)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-04-01 17:08:39 UTC (rev 230143)
@@ -1,3 +1,13 @@
+2018-03-31 Filip Pizlo
+
+JSC crash in JIT code with for-of loop and Array/Set iterators
+https://bugs.webkit.org/show_bug.cgi?id=183174
+
+Reviewed by Saam Barati.
+
+* dfg/DFGSafeToExecute.h:
+(JSC::DFG::safeToExecute): Fix the bug by making GetByOffset and friends verify that they are getting the type proof they want at the desired hoisting site.
+
2018-03-30 Filip Pizlo
Strings and Vectors shouldn't do index masking
Modified: trunk/Source/_javascript_Core/dfg/DFGSafeToExecute.h (230142 => 230143)
--- trunk/Source/_javascript_Core/dfg/DFGSafeToExecute.h 2018-04-01 16:47:59 UTC (rev 230142)
+++ trunk/Source/_javascript_Core/dfg/DFGSafeToExecute.h 2018-04-01 17:08:39 UTC (rev 230143)
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2013-2017 Apple Inc. All rights reserved.
+ * Copyright (C) 2013-2018 Apple Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -504,9 +504,33 @@
case GetByOffset:
case GetGetterSetterByOffset:
case PutByOffset: {
-PropertyOffset offset = node->storageAccessData().offset;
+
[webkit-changes] [230130] trunk/Source
Title: [230130] trunk/Source Revision 230130 Author fpi...@apple.com Date 2018-03-31 08:55:38 -0700 (Sat, 31 Mar 2018) Log Message Strings and Vectors shouldn't do index masking https://bugs.webkit.org/show_bug.cgi?id=184193 Reviewed by Mark Lam. Source/_javascript_Core: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt): (JSC::DFG::SpeculativeJIT::compileGetByValOnString): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt): (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt): * jit/ThunkGenerators.cpp: (JSC::stringCharLoad): Source/WTF: * wtf/SizeLimits.cpp: * wtf/Vector.h: (WTF::VectorBufferBase::allocateBuffer): (WTF::VectorBufferBase::tryAllocateBuffer): (WTF::VectorBufferBase::reallocateBuffer): (WTF::VectorBufferBase::deallocateBuffer): (WTF::VectorBufferBase::releaseBuffer): (WTF::VectorBufferBase::VectorBufferBase): (WTF::VectorBuffer::allocateBuffer): (WTF::VectorBuffer::tryAllocateBuffer): (WTF::VectorBuffer::swap): (WTF::VectorBuffer::restoreInlineBufferIfNeeded): (WTF::Vector::at): (WTF::Vector::at const): (WTF::VectorBufferBase::updateMask): Deleted. * wtf/text/StringImpl.h: (WTF::StringImpl::flagIsSymbol): (WTF::StringImpl::length const): (WTF::StringImplShape::StringImplShape): (WTF::StringImpl::at const): (WTF::StringImpl::tailOffset): (WTF::StringImpl::maskOffset): Deleted. (WTF::StringImpl::mask const): Deleted. * wtf/text/StringView.h: (WTF::StringView::StringView): (WTF::StringView::operator=): (WTF::StringView::initialize): (WTF::StringView::clear): (WTF::StringView::operator[] const): * wtf/text/WTFString.h: (WTF::String::length const): (WTF::String::mask const): Deleted. Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp trunk/Source/_javascript_Core/ftl/FTLAbstractHeapRepository.h trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp trunk/Source/_javascript_Core/jit/ThunkGenerators.cpp trunk/Source/WTF/ChangeLog trunk/Source/WTF/wtf/SizeLimits.cpp trunk/Source/WTF/wtf/Vector.h trunk/Source/WTF/wtf/text/StringImpl.cpp trunk/Source/WTF/wtf/text/StringImpl.h trunk/Source/WTF/wtf/text/StringView.h trunk/Source/WTF/wtf/text/WTFString.h Diff Modified: trunk/Source/_javascript_Core/ChangeLog (230129 => 230130) --- trunk/Source/_javascript_Core/ChangeLog 2018-03-31 07:04:00 UTC (rev 230129) +++ trunk/Source/_javascript_Core/ChangeLog 2018-03-31 15:55:38 UTC (rev 230130) @@ -1,3 +1,20 @@ +2018-03-30 Filip Pizlo + +Strings and Vectors shouldn't do index masking +https://bugs.webkit.org/show_bug.cgi?id=184193 + +Reviewed by Mark Lam. + +* dfg/DFGSpeculativeJIT.cpp: +(JSC::DFG::SpeculativeJIT::compileGetCharCodeAt): +(JSC::DFG::SpeculativeJIT::compileGetByValOnString): +* ftl/FTLAbstractHeapRepository.h: +* ftl/FTLLowerDFGToB3.cpp: +(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt): +(JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt): +* jit/ThunkGenerators.cpp: +(JSC::stringCharLoad): + 2018-03-30 Mark Lam Add pointer profiling support in baseline JIT and supporting files. Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp (230129 => 230130) --- trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp 2018-03-31 07:04:00 UTC (rev 230129) +++ trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp 2018-03-31 15:55:38 UTC (rev 230130) @@ -2110,7 +2110,6 @@ GPRReg scratchReg = scratch.gpr(); m_jit.loadPtr(MacroAssembler::Address(stringReg, JSString::offsetOfValue()), scratchReg); -m_jit.and32(MacroAssembler::Address(scratchReg, StringImpl::maskOffset()), indexReg); // Load the character into scratchReg JITCompiler::Jump is16Bit = m_jit.branchTest32(MacroAssembler::Zero, MacroAssembler::Address(scratchReg, StringImpl::flagsOffset()), TrustedImm32(StringImpl::flagIs8Bit())); @@ -2158,7 +2157,6 @@ speculationCheck(OutOfBounds, JSValueRegs(), 0, outOfBounds); m_jit.loadPtr(MacroAssembler::Address(baseReg, JSString::offsetOfValue()), scratchReg); -m_jit.and32(MacroAssembler::Address(scratchReg, StringImpl::maskOffset()), propertyReg); // Load the character into scratchReg JITCompiler::Jump is16Bit = m_jit.branchTest32(MacroAssembler::Zero, MacroAssembler::Address(scratchReg, StringImpl::flagsOffset()), TrustedImm32(StringImpl::flagIs8Bit())); Modified: trunk/Source/_javascript_Core/ftl/FTLAbstractHeapRepository.h (230129 => 230130) --- trunk/Source/_javascript_Core/ftl/FTLAbstractHeapRepository.h 2018-03-31 07:04:00 UTC (rev 230129) +++ trunk/Source/_javascript_Core/ftl/FTLAbstractHeapRepository.h 2018-03-31 15:55:38 UTC (rev 230130) @@ -112,7 +112,6 @@ macro(StringImpl_data, StringImpl::dataOffset()) \ macro(StringImpl_hashAndFlags, StringImpl::flagsOffset()) \ macro(StringImpl_length, StringImpl::lengthMemoryOffset()
[webkit-changes] [230115] trunk
Title: [230115] trunk
Revision 230115
Author fpi...@apple.com
Date 2018-03-30 13:31:00 -0700 (Fri, 30 Mar 2018)
Log Message
Bytecode generator should not get_from_scope something that may be a hole into a variable that is already live
https://bugs.webkit.org/show_bug.cgi?id=184189
Reviewed by JF Bastien.
JSTests:
* stress/load-hole-from-scope-into-live-var.js: Added.
(result.eval.try.switch):
(catch):
Source/_javascript_Core:
* bytecompiler/NodesCodegen.cpp:
(JSC::ResolveNode::emitBytecode):
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecompiler/NodesCodegen.cpp
Added Paths
trunk/JSTests/stress/load-hole-from-scope-into-live-var.js
Diff
Modified: trunk/JSTests/ChangeLog (230114 => 230115)
--- trunk/JSTests/ChangeLog 2018-03-30 20:25:26 UTC (rev 230114)
+++ trunk/JSTests/ChangeLog 2018-03-30 20:31:00 UTC (rev 230115)
@@ -1,3 +1,14 @@
+2018-03-30 Filip Pizlo
+
+Bytecode generator should not get_from_scope something that may be a hole into a variable that is already live
+https://bugs.webkit.org/show_bug.cgi?id=184189
+
+Reviewed by JF Bastien.
+
+* stress/load-hole-from-scope-into-live-var.js: Added.
+(result.eval.try.switch):
+(catch):
+
2018-03-30 Ryan Haddad
Unreviewed, rolling out r230102.
Added: trunk/JSTests/stress/load-hole-from-scope-into-live-var.js (0 => 230115)
--- trunk/JSTests/stress/load-hole-from-scope-into-live-var.js (rev 0)
+++ trunk/JSTests/stress/load-hole-from-scope-into-live-var.js 2018-03-30 20:31:00 UTC (rev 230115)
@@ -0,0 +1,14 @@
+//@ runDefault
+var result = eval(`
+try {
+switch (0) {
+case 1:
+let x = eval();
+default:
+x;
+}
+} catch (e) {
+}
+`);
+if (result !== void 0)
+throw "Bad result: " + result;
Modified: trunk/Source/_javascript_Core/ChangeLog (230114 => 230115)
--- trunk/Source/_javascript_Core/ChangeLog 2018-03-30 20:25:26 UTC (rev 230114)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-03-30 20:31:00 UTC (rev 230115)
@@ -1,3 +1,13 @@
+2018-03-30 Filip Pizlo
+
+Bytecode generator should not get_from_scope something that may be a hole into a variable that is already live
+https://bugs.webkit.org/show_bug.cgi?id=184189
+
+Reviewed by JF Bastien.
+
+* bytecompiler/NodesCodegen.cpp:
+(JSC::ResolveNode::emitBytecode):
+
2018-03-30 Mark Lam
Add pointer profiling support to Wasm.
Modified: trunk/Source/_javascript_Core/bytecompiler/NodesCodegen.cpp (230114 => 230115)
--- trunk/Source/_javascript_Core/bytecompiler/NodesCodegen.cpp 2018-03-30 20:25:26 UTC (rev 230114)
+++ trunk/Source/_javascript_Core/bytecompiler/NodesCodegen.cpp 2018-03-30 20:31:00 UTC (rev 230115)
@@ -252,10 +252,12 @@
generator.emitExpressionInfo(divot, m_start, divot);
RefPtr scope = generator.emitResolveScope(dst, var);
RegisterID* finalDest = generator.finalDestination(dst);
-RegisterID* result = generator.emitGetFromScope(finalDest, scope.get(), var, ThrowIfNotFound);
-generator.emitTDZCheckIfNecessary(var, finalDest, nullptr);
+RefPtr uncheckedResult = generator.newTemporary();
+generator.emitGetFromScope(uncheckedResult.get(), scope.get(), var, ThrowIfNotFound);
+generator.emitTDZCheckIfNecessary(var, uncheckedResult.get(), nullptr);
+generator.emitMove(finalDest, uncheckedResult.get());
generator.emitProfileType(finalDest, var, m_position, JSTextPosition(-1, m_position.offset + m_ident.length(), -1));
-return result;
+return finalDest;
}
// -- TemplateStringNode ---
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [229987] trunk
Title: [229987] trunk
Revision 229987
Author fpi...@apple.com
Date 2018-03-26 14:01:16 -0700 (Mon, 26 Mar 2018)
Log Message
DFG should know that CreateThis can be effectful
https://bugs.webkit.org/show_bug.cgi?id=184013
Reviewed by Saam Barati.
JSTests:
* stress/create-this-property-change.js: Added.
(Foo):
(RealBar):
(get if):
* stress/create-this-structure-change-without-cse.js: Added.
(Foo):
(RealBar):
(get if):
* stress/create-this-structure-change.js: Added.
(Foo):
(RealBar):
(get if):
Source/_javascript_Core:
As shown in the tests added in JSTests, CreateThis can be effectful if the constructor this
is a proxy.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h
trunk/Source/_javascript_Core/dfg/DFGClobberize.h
Added Paths
trunk/JSTests/stress/create-this-property-change.js
trunk/JSTests/stress/create-this-structure-change-without-cse.js
trunk/JSTests/stress/create-this-structure-change.js
Diff
Modified: trunk/JSTests/ChangeLog (229986 => 229987)
--- trunk/JSTests/ChangeLog 2018-03-26 21:00:30 UTC (rev 229986)
+++ trunk/JSTests/ChangeLog 2018-03-26 21:01:16 UTC (rev 229987)
@@ -1,3 +1,23 @@
+2018-03-26 Filip Pizlo
+
+DFG should know that CreateThis can be effectful
+https://bugs.webkit.org/show_bug.cgi?id=184013
+
+Reviewed by Saam Barati.
+
+* stress/create-this-property-change.js: Added.
+(Foo):
+(RealBar):
+(get if):
+* stress/create-this-structure-change-without-cse.js: Added.
+(Foo):
+(RealBar):
+(get if):
+* stress/create-this-structure-change.js: Added.
+(Foo):
+(RealBar):
+(get if):
+
2018-03-22 Yusuke Suzuki
[DFG] Introduces fused compare and jump
Added: trunk/JSTests/stress/create-this-property-change.js (0 => 229987)
--- trunk/JSTests/stress/create-this-property-change.js (rev 0)
+++ trunk/JSTests/stress/create-this-property-change.js 2018-03-26 21:01:16 UTC (rev 229987)
@@ -0,0 +1,49 @@
+var globalO;
+
+function Foo()
+{
+this.g = 42;
+}
+
+class RealBar extends Foo {
+constructor()
+{
+var o = globalO;
+var result = o.f;
+super();
+result += o.f;
+this.result = result;
+}
+}
+
+var doIntercept = false;
+var didExecuteFGetter = false;
+var Bar = new Proxy(RealBar, {
+get: function(target, property, receiver) {
+if (property == "prototype" && doIntercept) {
+globalO.f = 666;
+didExecuteFGetter = true;
+}
+return Reflect.get(target, property, receiver);
+}
+});
+
+noInline(RealBar);
+
+for (var i = 0; i < 1; ++i) {
+(function() {
+globalO = {f:43};
+var result = new Bar().result;
+if (result != 86)
+throw "bad result in loop: " + result;
+})();
+}
+
+doIntercept = true;
+globalO = {f:43};
+var result = new Bar().result;
+if (result != 709)
+throw "bad result at end: " + result;
+if (!didExecuteFGetter)
+throw "did not execute f getter";
+
Added: trunk/JSTests/stress/create-this-structure-change-without-cse.js (0 => 229987)
--- trunk/JSTests/stress/create-this-structure-change-without-cse.js (rev 0)
+++ trunk/JSTests/stress/create-this-structure-change-without-cse.js 2018-03-26 21:01:16 UTC (rev 229987)
@@ -0,0 +1,51 @@
+var globalO;
+
+function Foo()
+{
+this.f = 42;
+}
+
+class RealBar extends Foo {
+constructor()
+{
+var o = globalO;
+var result = o.f;
+super();
+result += o.f;
+this.result = result;
+}
+}
+
+var doIntercept = false;
+var didExecuteFGetter = false;
+var Bar = new Proxy(RealBar, {
+get: function(target, property, receiver) {
+if (property == "prototype" && doIntercept) {
+globalO.__defineGetter__("f", function() {
+didExecuteFGetter = true;
+return 666;
+});
+}
+return Reflect.get(target, property, receiver);
+}
+});
+
+noInline(RealBar);
+
+for (var i = 0; i < 1; ++i) {
+(function() {
+globalO = {f:43};
+var result = new Bar().result;
+if (result != 86)
+throw "bad result in loop: " + result;
+})();
+}
+
+doIntercept = true;
+globalO = {f:43};
+var result = new Bar().result;
+if (result != 709)
+throw "bad result at end: " + result;
+if (!didExecuteFGetter)
+throw "did not execute f getter";
+
Added: trunk/JSTests/stress/create-this-structure-change.js (0 => 229987)
--- trunk/JSTests/stress/create-this-structure-change.js (rev 0)
+++ trunk/JSTests/stress/create-this-structure-change.js 2018-03-26 21:01:16 UTC (rev 229987)
@@ -0,0 +1,51 @@
+var gl
[webkit-changes] [229842] trunk
Title: [229842] trunk
Revision 229842
Author fpi...@apple.com
Date 2018-03-21 19:15:44 -0700 (Wed, 21 Mar 2018)
Log Message
ScopedArguments should do poisoning and index masking
https://bugs.webkit.org/show_bug.cgi?id=183863
Reviewed by Mark Lam.
JSTests:
Adds another stress test of scoped arguments.
* stress/scoped-arguments-test.js: Added.
(foo):
Source/_javascript_Core:
This outlines the ScopedArguments overflow storage and adds poisoning.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateWithGuard):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
(JSC::DFG::SpeculativeJIT::compileGetArrayLength):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitScopedArgumentsGetByVal):
* runtime/JSCPoison.h:
* runtime/ScopedArguments.cpp:
(JSC::ScopedArguments::ScopedArguments):
(JSC::ScopedArguments::createUninitialized):
(JSC::ScopedArguments::visitChildren):
* runtime/ScopedArguments.h:
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/AccessCase.cpp
trunk/Source/_javascript_Core/dfg/DFGArrayMode.cpp
trunk/Source/_javascript_Core/dfg/DFGOSRExit.cpp
trunk/Source/_javascript_Core/dfg/DFGOperations.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
trunk/Source/_javascript_Core/ftl/FTLAbstractHeapRepository.h
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
trunk/Source/_javascript_Core/ftl/FTLOperations.cpp
trunk/Source/_javascript_Core/jit/JITPropertyAccess.cpp
trunk/Source/_javascript_Core/runtime/DirectArguments.cpp
trunk/Source/_javascript_Core/runtime/DirectArguments.h
trunk/Source/_javascript_Core/runtime/GenericArgumentsInlines.h
trunk/Source/_javascript_Core/runtime/JSCPoison.h
trunk/Source/_javascript_Core/runtime/ScopedArguments.cpp
trunk/Source/_javascript_Core/runtime/ScopedArguments.h
Added Paths
trunk/JSTests/stress/scoped-arguments-test.js
Diff
Modified: trunk/JSTests/ChangeLog (229841 => 229842)
--- trunk/JSTests/ChangeLog 2018-03-22 01:49:27 UTC (rev 229841)
+++ trunk/JSTests/ChangeLog 2018-03-22 02:15:44 UTC (rev 229842)
@@ -1,3 +1,15 @@
+2018-03-21 Filip Pizlo
+
+ScopedArguments should do poisoning and index masking
+https://bugs.webkit.org/show_bug.cgi?id=183863
+
+Reviewed by Mark Lam.
+
+Adds another stress test of scoped arguments.
+
+* stress/scoped-arguments-test.js: Added.
+(foo):
+
2018-03-20 Saam Barati
We need to do proper bookkeeping of exitOK when inserting constants when sinking NewArrayBuffer
Added: trunk/JSTests/stress/scoped-arguments-test.js (0 => 229842)
--- trunk/JSTests/stress/scoped-arguments-test.js (rev 0)
+++ trunk/JSTests/stress/scoped-arguments-test.js 2018-03-22 02:15:44 UTC (rev 229842)
@@ -0,0 +1,16 @@
+function foo(a)
+{
+(function() { return a; })();
+return [arguments[0], arguments];
+}
+
+noInline(foo);
+
+for (var i = 0; i < 1; ++i) {
+var result = foo(42);
+if (result[0] != 42)
+throw new Error("result[0] is not 42: " + result[0]);
+if (result[1][0] != 42)
+throw new Error("result[1][0] is not 42: " + result[1][0]);
+}
+
Modified: trunk/Source/_javascript_Core/ChangeLog (229841 => 229842)
--- trunk/Source/_javascript_Core/ChangeLog 2018-03-22 01:49:27 UTC (rev 229841)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-03-22 02:15:44 UTC (rev 229842)
@@ -1,3 +1,30 @@
+2018-03-21 Filip Pizlo
+
+ScopedArguments should do poisoning and index masking
+https://bugs.webkit.org/show_bug.cgi?id=183863
+
+Reviewed by Mark Lam.
+
+This outlines the ScopedArguments overflow storage and adds poisoning.
+
+* bytecode/AccessCase.cpp:
+(JSC::AccessCase::generateWithGuard):
+* dfg/DFGSpeculativeJIT.cpp:
+(JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
+(JSC::DFG::SpeculativeJIT::compileGetArrayLength):
+* ftl/FTLAbstractHeapRepository.h:
+* ftl/FTLLowerDFGToB3.cpp:
+(JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
+(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
+* jit/JITPropertyAccess.cpp:
+(JSC::JIT::emitScopedArgumentsGetByVal):
+* runtime/JSCPoison.h:
+* runtime/ScopedArguments.cpp:
+(JSC::ScopedArguments::ScopedArguments):
+(JSC::ScopedArguments::createUninitialized):
+(JSC::ScopedArguments::visitChildren):
+* runtime/ScopedArguments.h:
+
2018-03-21 Mark Lam
Refactor the PtrTag list as a macro so that we can auto-generate code that enumerates each PtrTag.
Modified: trunk/Source/_javascript_Core/bytecode/AccessCase.cpp (229841 => 229842)
--- trunk/Source/_javascript_Core/bytecode/AccessCase.cpp 2018-03-22 01
[webkit-changes] [229545] trunk/Source/JavaScriptCore
Title: [229545] trunk/Source/_javascript_Core
Revision 229545
Author fpi...@apple.com
Date 2018-03-12 13:19:53 -0700 (Mon, 12 Mar 2018)
Log Message
Unreviewed, fix simple goof that was causing 32-bit DFG crashes.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (229544 => 229545)
--- trunk/Source/_javascript_Core/ChangeLog 2018-03-12 19:44:17 UTC (rev 229544)
+++ trunk/Source/_javascript_Core/ChangeLog 2018-03-12 20:19:53 UTC (rev 229545)
@@ -1,3 +1,10 @@
+2018-03-12 Filip Pizlo
+
+Unreviewed, fix simple goof that was causing 32-bit DFG crashes.
+
+* dfg/DFGSpeculativeJIT.cpp:
+(JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
+
2018-03-11 Yusuke Suzuki
[DFG] AI should convert CreateThis to NewObject if the prototype object is proved
Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp (229544 => 229545)
--- trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp 2018-03-12 19:44:17 UTC (rev 229544)
+++ trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp 2018-03-12 20:19:53 UTC (rev 229545)
@@ -7006,7 +7006,8 @@
GPRTemporary length;
if (isX86() && is32Bit() && !lengthIsKnown) {
-GPRFlushedCallResult result(this);
+GPRFlushedCallResult realResult(this);
+result.adopt(realResult);
resultGPR = result.gpr();
RELEASE_ASSERT(resultGPR == GPRInfo::regT0);
flushRegisters();
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
