[webkit-changes] [289601] trunk

2022-02-10 Thread fpizlo
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

2022-02-10 Thread fpizlo
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):

[webkit-changes] [289491] trunk/Source/bmalloc

2022-02-09 Thread fpizlo
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 

[webkit-changes] [288342] trunk/Source/bmalloc

2022-01-20 Thread fpizlo
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

[webkit-changes] [287994] trunk/Source/bmalloc

2022-01-13 Thread fpizlo
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, _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

2022-01-13 Thread fpizlo
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, _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 == _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:09 UTC 

[webkit-changes] [287968] trunk/Source/bmalloc

2022-01-12 Thread fpizlo
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 

[webkit-changes] [286587] trunk/Source/bmalloc

2021-12-06 Thread fpizlo
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 

[webkit-changes] [286516] trunk/Source/bmalloc

2021-12-03 Thread fpizlo
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 /* 

[webkit-changes] [284456] trunk/Source/WTF

2021-10-19 Thread fpizlo
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

2021-10-01 Thread fpizlo
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

[webkit-changes] [283178] trunk/Source/bmalloc

2021-09-28 Thread fpizlo
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 

[webkit-changes] [282899] trunk/Source/bmalloc

2021-09-22 Thread fpizlo
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

2021-09-16 Thread fpizlo
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

2021-08-04 Thread fpizlo
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)

--- 

[webkit-changes] [280605] trunk/Source/bmalloc

2021-08-03 Thread fpizlo
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(>spine); \
+spine = name##_spine_ptr_load([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(>spine); \
+spine = name##_spine_ptr_load([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

2021-06-16 Thread fpizlo
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 @@
 		

[webkit-changes] [278476] trunk/Source/JavaScriptCore

2021-06-04 Thread fpizlo
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

2021-06-04 Thread fpizlo
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:
+* 

[webkit-changes] [278424] trunk/Source/JavaScriptCore

2021-06-03 Thread fpizlo
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

2021-05-11 Thread fpizlo
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

2021-05-06 Thread fpizlo
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

2021-05-06 Thread fpizlo
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* 

[webkit-changes] [277117] trunk/Source

2021-05-06 Thread fpizlo
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

2021-05-06 Thread fpizlo
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 

[webkit-changes] [277105] trunk/Tools

2021-05-06 Thread fpizlo
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

2021-04-30 Thread fpizlo
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

2021-04-30 Thread fpizlo
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

2021-04-27 Thread fpizlo
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

2020-04-23 Thread fpizlo
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

2020-04-21 Thread fpizlo
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

2020-04-21 Thread fpizlo
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

2020-04-21 Thread fpizlo
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

2020-04-21 Thread fpizlo
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

2020-04-21 Thread fpizlo
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

2020-04-18 Thread fpizlo
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

2020-04-18 Thread fpizlo
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

2020-04-14 Thread fpizlo
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

2020-04-14 Thread fpizlo
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

2020-04-14 Thread fpizlo
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

2020-04-14 Thread fpizlo
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

2020-04-14 Thread fpizlo
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

2018-11-16 Thread fpizlo
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 

[webkit-changes] [238324] trunk/JSTests

2018-11-16 Thread fpizlo
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

2018-11-16 Thread fpizlo
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

2018-07-23 Thread fpizlo
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 

[webkit-changes] [233714] trunk/Source/JavaScriptCore

2018-07-10 Thread fpizlo
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)

--- 

[webkit-changes] [233631] trunk/Tools

2018-07-08 Thread fpizlo
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

2018-06-07 Thread fpizlo
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, 

[webkit-changes] [232227] trunk/Source/WTF

2018-05-26 Thread fpizlo
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

2018-05-23 Thread fpizlo
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	

[webkit-changes] [232074] trunk/Source

2018-05-22 Thread fpizlo
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

[webkit-changes] [232008] trunk/Source/JavaScriptCore

2018-05-20 Thread fpizlo
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

2018-05-19 Thread fpizlo
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

[webkit-changes] [231871] trunk

2018-05-16 Thread fpizlo
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)
+

[webkit-changes] [231743] trunk/Source/WTF

2018-05-13 Thread fpizlo
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

2018-05-13 Thread fpizlo
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, ); }; 

[webkit-changes] [231665] trunk/Source/JavaScriptCore

2018-05-10 Thread fpizlo
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 = 

[webkit-changes] [231660] trunk/Source/JavaScriptCore

2018-05-10 Thread fpizlo
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):

[webkit-changes] [231607] trunk/Source/JavaScriptCore

2018-05-09 Thread fpizlo
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 

[webkit-changes] [231522] trunk/Source/JavaScriptCore

2018-05-08 Thread fpizlo
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

2018-05-08 Thread fpizlo
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:

[webkit-changes] [231468] trunk

2018-05-07 Thread fpizlo
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  
 
   

[webkit-changes] [231467] trunk/Source/JavaScriptCore

2018-05-07 Thread fpizlo
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

2018-05-05 Thread fpizlo
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

2018-05-03 Thread fpizlo
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 */ 

[webkit-changes] [231283] trunk

2018-05-02 Thread fpizlo
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

2018-05-02 Thread fpizlo
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 = 

[webkit-changes] [231204] trunk/Source/JavaScriptCore

2018-05-01 Thread fpizlo
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)

--- 

[webkit-changes] [231185] trunk

2018-04-30 Thread fpizlo
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

2018-04-29 Thread fpizlo
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

2018-04-27 Thread fpizlo
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

2018-04-24 Thread fpizlo
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], 

[webkit-changes] [230964] trunk/Source/JavaScriptCore

2018-04-24 Thread fpizlo
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: {
+

[webkit-changes] [230956] trunk/Source/JavaScriptCore

2018-04-24 Thread fpizlo
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

2018-04-23 Thread fpizlo
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

2018-04-23 Thread fpizlo
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;
-}
-
- 

[webkit-changes] [230813] trunk/Source

2018-04-19 Thread fpizlo
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__) && 

[webkit-changes] [230726] trunk/Source/JavaScriptCore

2018-04-17 Thread fpizlo
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());
+

[webkit-changes] [230725] trunk

2018-04-17 Thread fpizlo
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 

[webkit-changes] [230723] trunk/Source/JavaScriptCore

2018-04-17 Thread fpizlo
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 

[webkit-changes] [230695] trunk/Source/WebCore

2018-04-16 Thread fpizlo
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

2018-04-15 Thread fpizlo
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 

[webkit-changes] [230494] trunk/Source/JavaScriptCore

2018-04-10 Thread fpizlo
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

2018-04-10 Thread fpizlo
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):
+* 

[webkit-changes] [230486] trunk/Source/JavaScriptCore

2018-04-10 Thread fpizlo
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

2018-04-10 Thread fpizlo
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)) {
 

[webkit-changes] [230465] trunk/Source/JavaScriptCore

2018-04-09 Thread fpizlo
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;
 }
-  

[webkit-changes] [230287] trunk

2018-04-04 Thread fpizlo
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
+

[webkit-changes] [230273] trunk/Source/JavaScriptCore

2018-04-04 Thread fpizlo
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):
+* 

[webkit-changes] [230266] trunk/Source/JavaScriptCore

2018-04-04 Thread fpizlo
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:
+

[webkit-changes] [230264] trunk/Source/JavaScriptCore

2018-04-04 Thread fpizlo
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

2018-04-03 Thread fpizlo
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
 

[webkit-changes] [230145] trunk/Source/JavaScriptCore

2018-04-01 Thread fpizlo
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

2018-04-01 Thread fpizlo
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 

[webkit-changes] [230130] trunk/Source

2018-03-31 Thread fpizlo
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()) \
 

[webkit-changes] [230115] trunk

2018-03-30 Thread fpizlo
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

2018-03-26 Thread fpizlo
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 

[webkit-changes] [229842] trunk

2018-03-21 Thread fpizlo
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 => 

[webkit-changes] [229545] trunk/Source/JavaScriptCore

2018-03-12 Thread fpizlo
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


  1   2   3   4   5   6   7   8   9   10   >