from:"sbarati"

[webkit-changes] [228725] trunk

2018-02-19 Thread sbarati

Title: [228725] trunk








Revision 228725
Author sbar...@apple.com
Date 2018-02-19 19:45:03 -0800 (Mon, 19 Feb 2018)


Log Message
Don't use JSFunction's allocation profile when getting the prototype can be effectful
https://bugs.webkit.org/show_bug.cgi?id=182942


Reviewed by Mark Lam.

JSTests:

* stress/get-prototype-create-this-effectful.js: Added.

Source/_javascript_Core:

Prior to this patch, the create_this implementation assumed that anything
that is a JSFunction can use the object allocation profile and go down the
fast path to allocate the |this| object. Implied by this approach is that
accessing the 'prototype' property of the incoming function is not an
effectful operation. This is inherent to the ObjectAllocationProfile
data structure: it caches the prototype field. However, getting the
'prototype' property might be an effectful operation, e.g, it could
be a getter. Many variants of functions in JS have the 'prototype' property
as non-configurable. However, some functions, like bound functions, do not
have the 'prototype' field with these attributes.

This patch adds the notion of 'canUseAllocationProfile' to JSFunction
and threads it through so that we only go down the fast path and use
the allocation profile when the prototype property is non-configurable.

* bytecompiler/NodesCodegen.cpp:
(JSC::ClassExprNode::emitBytecode):
* dfg/DFGOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSFunction.cpp:
(JSC::JSFunction::prototypeForConstruction):
(JSC::JSFunction::allocateAndInitializeRareData):
(JSC::JSFunction::initializeRareData):
(JSC::JSFunction::getOwnPropertySlot):
(JSC::JSFunction::canUseAllocationProfileNonInline):
* runtime/JSFunction.h:
(JSC::JSFunction::ensureRareDataAndAllocationProfile):
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::canUseAllocationProfile):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecompiler/NodesCodegen.cpp
trunk/Source/_javascript_Core/dfg/DFGOperations.cpp
trunk/Source/_javascript_Core/runtime/CommonSlowPaths.cpp
trunk/Source/_javascript_Core/runtime/JSFunction.cpp
trunk/Source/_javascript_Core/runtime/JSFunction.h
trunk/Source/_javascript_Core/runtime/JSFunctionInlines.h


Added Paths

trunk/JSTests/stress/get-prototype-create-this-effectful.js




Diff

Modified: trunk/JSTests/ChangeLog (228724 => 228725)

--- trunk/JSTests/ChangeLog	2018-02-20 03:21:53 UTC (rev 228724)
+++ trunk/JSTests/ChangeLog	2018-02-20 03:45:03 UTC (rev 228725)
@@ -1,3 +1,13 @@
+2018-02-19  Saam Barati  
+
+Don't use JSFunction's allocation profile when getting the prototype can be effectful
+https://bugs.webkit.org/show_bug.cgi?id=182942
+
+
+Reviewed by Mark Lam.
+
+* stress/get-prototype-create-this-effectful.js: Added.
+
 2018-02-16  Saam Barati  
 
 Fix bugs from r228411


Added: trunk/JSTests/stress/get-prototype-create-this-effectful.js (0 => 228725)

--- trunk/JSTests/stress/get-prototype-create-this-effectful.js	(rev 0)
+++ trunk/JSTests/stress/get-prototype-create-this-effectful.js	2018-02-20 03:45:03 UTC (rev 228725)
@@ -0,0 +1,40 @@
+function assert(b) {
+if (!b)
+throw new Error("Bad assertion")
+}
+
+function test1() {
+let boundFunction = function () {}.bind();
+Object.defineProperty(boundFunction, "prototype", {
+get() {
+throw Error("Hello");
+}
+});
+
+let threw = false;
+try {
+Reflect.construct(function() {}, [], boundFunction);
+} catch(e) {
+threw = true;
+assert(e.message === "Hello");
+}
+assert(threw);
+}
+test1();
+
+function test2() {
+let boundFunction = function () {}.bind();
+let counter = 0;
+Object.defineProperty(boundFunction, "prototype", {
+get() {
+++counter;
+return {};
+}
+});
+
+const iters = 1000;
+for (let i = 0; i < iters; ++i)
+Reflect.construct(function() {}, [], boundFunction);
+assert(counter === iters);
+}
+test2();


Modified: trunk/Source/_javascript_Core/ChangeLog (228724 => 228725)

--- trunk/Source/_javascript_Core/ChangeLog	2018-02-20 03:21:53 UTC (rev 228724)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-02-20 03:45:03 UTC (rev 228725)
@@ -1,5 +1,44 @@
 2018-02-19  Saam Barati  
 
+Don't use JSFunction's allocation profile when getting the prototype can be effectful
+https://bugs.webkit.org/show_bug.cgi?id=182942
+
+
+Reviewed by Mark Lam.
+
+Prior to this patch, the create_this implementation assumed that anything
+that is a JSFunction can use the object allocation profile and go down the
+fast path to allocate the |this| object. Implied by this approach is that
+accessing the 'prototype' property of the incoming function is not an
+effectful operation.

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

2018-02-19 Thread sbarati

Title: [228720] trunk/Source/_javascript_Core








Revision 228720
Author sbar...@apple.com
Date 2018-02-19 18:00:39 -0800 (Mon, 19 Feb 2018)


Log Message
Don't mark an array profile out of bounds for the cases where the DFG will convert the access to SaneChain
https://bugs.webkit.org/show_bug.cgi?id=182912


Reviewed by Keith Miller.

In the baseline JIT and LLInt, when we loading a hole from an original array,
with the array prototype chain being normal, we end up marking the ArrayProfile
for that GetByVal as out of bounds. However, the DFG knows exactly how to
optimize this case by returning undefined when loading from a hole. Currently,
it only does this for Contiguous arrays (and sometimes Double arrays).
This patch just makes sure to not mark the ArrayProfile as out of bounds
in this scenario for Contiguous arrays, since the DFG will always optimize
this case.

However, we should extend this by profiling when a GetByVal loads a hole. By
doing so, we can optimize this for Int32, ArrayStorage, and maybe even Double
arrays. That work will happen in:
https://bugs.webkit.org/show_bug.cgi?id=182940

This patch is a 30-50%  speedup on JetStream's hash-map test. This patch
speeds up JetStream by 1% when testing on my iMac.

* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::refine const):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* jit/JITOperations.cpp:
(JSC::getByVal):
(JSC::canAccessArgumentIndexQuickly): Deleted.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::getByVal):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::canAccessArgumentIndexQuickly):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGArrayMode.cpp
trunk/Source/_javascript_Core/dfg/DFGFixupPhase.cpp
trunk/Source/_javascript_Core/jit/JITOperations.cpp
trunk/Source/_javascript_Core/llint/LLIntSlowPaths.cpp
trunk/Source/_javascript_Core/llint/LowLevelInterpreter32_64.asm
trunk/Source/_javascript_Core/llint/LowLevelInterpreter64.asm
trunk/Source/_javascript_Core/runtime/CommonSlowPaths.h




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (228719 => 228720)

--- trunk/Source/_javascript_Core/ChangeLog	2018-02-20 01:26:25 UTC (rev 228719)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-02-20 02:00:39 UTC (rev 228720)
@@ -1,3 +1,43 @@
+2018-02-19  Saam Barati  
+
+Don't mark an array profile out of bounds for the cases where the DFG will convert the access to SaneChain
+https://bugs.webkit.org/show_bug.cgi?id=182912
+
+
+Reviewed by Keith Miller.
+
+In the baseline JIT and LLInt, when we loading a hole from an original array,
+with the array prototype chain being normal, we end up marking the ArrayProfile
+for that GetByVal as out of bounds. However, the DFG knows exactly how to
+optimize this case by returning undefined when loading from a hole. Currently,
+it only does this for Contiguous arrays (and sometimes Double arrays).
+This patch just makes sure to not mark the ArrayProfile as out of bounds
+in this scenario for Contiguous arrays, since the DFG will always optimize
+this case.
+
+However, we should extend this by profiling when a GetByVal loads a hole. By
+doing so, we can optimize this for Int32, ArrayStorage, and maybe even Double
+arrays. That work will happen in:
+https://bugs.webkit.org/show_bug.cgi?id=182940
+
+This patch is a 30-50%  speedup on JetStream's hash-map test. This patch
+speeds up JetStream by 1% when testing on my iMac.
+
+* dfg/DFGArrayMode.cpp:
+(JSC::DFG::ArrayMode::refine const):
+* dfg/DFGFixupPhase.cpp:
+(JSC::DFG::FixupPhase::fixupNode):
+* jit/JITOperations.cpp:
+(JSC::getByVal):
+(JSC::canAccessArgumentIndexQuickly): Deleted.
+* llint/LLIntSlowPaths.cpp:
+(JSC::LLInt::getByVal):
+(JSC::LLInt::LLINT_SLOW_PATH_DECL):
+* llint/LowLevelInterpreter32_64.asm:
+* llint/LowLevelInterpreter64.asm:
+* runtime/CommonSlowPaths.h:
+(JSC::CommonSlowPaths::canAccessArgumentIndexQuickly):
+
 2018-02-17  Filip Pizlo  
 
 GetArrayMask should support constant folding


Modified: trunk/Source/_javascript_Core/dfg/DFGArrayMode.cpp (228719 => 228720)

--- trunk/Source/_javascript_Core/dfg/DFGArrayMode.cpp	2018-02-20 01:26:25 UTC (rev 228719)
+++ trunk/Source/_javascript_Core/dfg/DFGArrayMode.cpp	2018-02-20 02:00:39 UTC (rev 228720)
@@ -210,12 +210,16 @@
 // If we have an OriginalArray and the JSArray prototype chain is sane,
 // any indexed access always return undefined. We have a fast path for that.
 JSGlobalObject* globalObject = graph.globalObjectFor(node->origin.semantic);
+Structure* arrayPrototypeStructure

[webkit-changes] [228565] trunk

2018-02-16 Thread sbarati

Title: [228565] trunk








Revision 228565
Author sbar...@apple.com
Date 2018-02-16 11:12:29 -0800 (Fri, 16 Feb 2018)


Log Message
Fix bugs from r228411
https://bugs.webkit.org/show_bug.cgi?id=182851


Reviewed by JF Bastien.

JSTests:

* stress/constant-folding-phase-insert-check-handle-varargs.js: Added.

Source/_javascript_Core:

There was a bug from r228411 where inside the constant folding phase,
we used an insertCheck method that didn't handle varargs. This would
lead to a crash. When thinking about the fix for that function, I realized
a made a couple of mistakes in r228411. One is probably a security bug, and
the other is a performance bug because it'll prevent CSE for certain flavors
of GetByVal nodes. Both blunders are similar in nature.

In r228411, I added code in LICM that inserted a CheckVarargs node with children
of another varargs node. However, to construct this new node's children,
I just copied the AdjacencyList. This does a shallow copy. What we needed
was a deep copy. We needed to create a new vararg AdjacencyList that points
to edges that are deep copies of the original varargs children. This patch
fixes this goof in LICM.

r228411 made it so that PureValue over a varargs node would just compare actual
AdjacencyLists structs. So, if you had two GetByVals that had equal santized
children, their actual AdjacencyList structs are *not* bitwise equal, since they'll
have different firstChild values. Instead, we need to do a deep compare of their
adjacency lists. This patch teaches PureValue how to do that.

* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::copyVarargChildren):
* dfg/DFGInsertionSet.h:
(JSC::DFG::InsertionSet::insertCheck):
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::attemptHoist):
* dfg/DFGPureValue.cpp:
(JSC::DFG::PureValue::dump const):
* dfg/DFGPureValue.h:
(JSC::DFG::PureValue::PureValue):
(JSC::DFG::PureValue::op const):
(JSC::DFG::PureValue::hash const):
(JSC::DFG::PureValue::operator== const):
(JSC::DFG::PureValue::isVarargs const):
(JSC::DFG::PureValue::children const): Deleted.
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
(JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGClobberize.h
trunk/Source/_javascript_Core/dfg/DFGConstantFoldingPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGGraph.h
trunk/Source/_javascript_Core/dfg/DFGInsertionSet.h
trunk/Source/_javascript_Core/dfg/DFGLICMPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGPureValue.cpp
trunk/Source/_javascript_Core/dfg/DFGPureValue.h
trunk/Source/_javascript_Core/dfg/DFGStrengthReductionPhase.cpp


Added Paths

trunk/JSTests/stress/constant-folding-phase-insert-check-handle-varargs.js




Diff

Modified: trunk/JSTests/ChangeLog (228564 => 228565)

--- trunk/JSTests/ChangeLog	2018-02-16 19:05:07 UTC (rev 228564)
+++ trunk/JSTests/ChangeLog	2018-02-16 19:12:29 UTC (rev 228565)
@@ -1,3 +1,13 @@
+2018-02-16  Saam Barati  
+
+Fix bugs from r228411
+https://bugs.webkit.org/show_bug.cgi?id=182851
+
+
+Reviewed by JF Bastien.
+
+* stress/constant-folding-phase-insert-check-handle-varargs.js: Added.
+
 2018-02-15  Filip Pizlo  
 
 Unreviewed, roll out r228366 since it did not progress anything.


Added: trunk/JSTests/stress/constant-folding-phase-insert-check-handle-varargs.js (0 => 228565)

--- trunk/JSTests/stress/constant-folding-phase-insert-check-handle-varargs.js	(rev 0)
+++ trunk/JSTests/stress/constant-folding-phase-insert-check-handle-varargs.js	2018-02-16 19:12:29 UTC (rev 228565)
@@ -0,0 +1,151 @@
+function __getRandomObject() {
+for (let obj of __getObjects()) {
+}
+}
+function __getRandomProperty() {
+let properties = __getproperties(obj);
+return properties[seed % properties.length];
+}
+try {
+} catch (e) {
+this.WScript = new Proxy({}, { });
+}
+(function () { function ValueOf() { switch (value) { } } })(this);
+
+(function (global) { })(this);
+
+function f1() {
+v = v.map(() => { })
+}
+
+try {
+f1();
+} catch (e) {}
+
+try {
+f1();
+} catch (e) {}
+
+try {
+__getRandomObject(983831)[__getRandomProperty(__getRandomObject(983831))]();
+} catch (e) {}
+
+if (!'next') throw "Error: iterator prototype should have next method.";
+
+function f2() {
+var v = a[0];
+if (v.next !== a[randoF2].next) throw "Error: next method is not the same.";
+}
+var a1 = [];
+var sym = a1[Symbol.iterator]();
+try {
+__callRandomFunction(keys, 457796, keys, __getRandomObject(860068), keys, true, __getRandomObject(32567), -1073741825, null);
+Object.defineProperty(keys, __getRandomProperty(), { });
+f2([a1[Symbol.iterator](),
+ keys.keys(), a1.entries()]);
+} catch

[webkit-changes] [228488] trunk

2018-02-14 Thread sbarati

Title: [228488] trunk








Revision 228488
Author sbar...@apple.com
Date 2018-02-14 15:25:52 -0800 (Wed, 14 Feb 2018)


Log Message
Setting a VMTrap shouldn't look at topCallFrame since that may imply we're in C code and holding the malloc lock
https://bugs.webkit.org/show_bug.cgi?id=182801

Reviewed by Keith Miller.

JSTests:

* stress/watchdog-dont-malloc-when-in-c-code.js: Added.

Source/_javascript_Core:

VMTraps would sometimes install traps when it paused the JS thread when it
was in C code. This is wrong, as installing traps mallocs, and the JS thread
may have been holding the malloc lock while in C code. This could lead to a
deadlock when C code was holding the malloc lock.

This patch makes it so that we only install traps when we've proven the PC
is in JIT or LLInt code. If we're in JIT/LLInt code, we are guaranteed that
we're not holding the malloc lock.

* jsc.cpp:
(GlobalObject::finishCreation):
(functionMallocInALoop):
* runtime/VMTraps.cpp:
(JSC::VMTraps::tryInstallTrapBreakpoints):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/jsc.cpp
trunk/Source/_javascript_Core/runtime/VMTraps.cpp


Added Paths

trunk/JSTests/stress/watchdog-dont-malloc-when-in-c-code.js




Diff

Modified: trunk/JSTests/ChangeLog (228487 => 228488)

--- trunk/JSTests/ChangeLog	2018-02-14 22:45:50 UTC (rev 228487)
+++ trunk/JSTests/ChangeLog	2018-02-14 23:25:52 UTC (rev 228488)
@@ -1,3 +1,12 @@
+2018-02-14  Saam Barati  
+
+Setting a VMTrap shouldn't look at topCallFrame since that may imply we're in C code and holding the malloc lock
+https://bugs.webkit.org/show_bug.cgi?id=182801
+
+Reviewed by Keith Miller.
+
+* stress/watchdog-dont-malloc-when-in-c-code.js: Added.
+
 2018-02-14  Ryan Haddad  
 
 Skip JSC test stress/activation-sink-default-value-tdz-error.js on debug.


Added: trunk/JSTests/stress/watchdog-dont-malloc-when-in-c-code.js (0 => 228488)

--- trunk/JSTests/stress/watchdog-dont-malloc-when-in-c-code.js	(rev 0)
+++ trunk/JSTests/stress/watchdog-dont-malloc-when-in-c-code.js	2018-02-14 23:25:52 UTC (rev 228488)
@@ -0,0 +1,5 @@
+//@ runFTLEagerWatchdog
+
+for (let i = 0; i < 7000; ++i) {
+mallocInALoop();
+}


Modified: trunk/Source/_javascript_Core/ChangeLog (228487 => 228488)

--- trunk/Source/_javascript_Core/ChangeLog	2018-02-14 22:45:50 UTC (rev 228487)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-02-14 23:25:52 UTC (rev 228488)
@@ -1,3 +1,25 @@
+2018-02-14  Saam Barati  
+
+Setting a VMTrap shouldn't look at topCallFrame since that may imply we're in C code and holding the malloc lock
+https://bugs.webkit.org/show_bug.cgi?id=182801
+
+Reviewed by Keith Miller.
+
+VMTraps would sometimes install traps when it paused the JS thread when it
+was in C code. This is wrong, as installing traps mallocs, and the JS thread
+may have been holding the malloc lock while in C code. This could lead to a
+deadlock when C code was holding the malloc lock.
+
+This patch makes it so that we only install traps when we've proven the PC
+is in JIT or LLInt code. If we're in JIT/LLInt code, we are guaranteed that
+we're not holding the malloc lock.
+
+* jsc.cpp:
+(GlobalObject::finishCreation):
+(functionMallocInALoop):
+* runtime/VMTraps.cpp:
+(JSC::VMTraps::tryInstallTrapBreakpoints):
+
 2018-02-14  Michael Saboff  
 
 REGRESSION(225695) : com.apple.WebKit.WebContent at com.apple._javascript_Core: JSC::RegExp::match + 630 :: stack overflow


Modified: trunk/Source/_javascript_Core/jsc.cpp (228487 => 228488)

--- trunk/Source/_javascript_Core/jsc.cpp	2018-02-14 22:45:50 UTC (rev 228487)
+++ trunk/Source/_javascript_Core/jsc.cpp	2018-02-14 23:25:52 UTC (rev 228488)
@@ -342,6 +342,7 @@
 static EncodedJSValue JSC_HOST_CALL functionHeapCapacity(ExecState*);
 static EncodedJSValue JSC_HOST_CALL functionFlashHeapAccess(ExecState*);
 static EncodedJSValue JSC_HOST_CALL functionDisableRichSourceInfo(ExecState*);
+static EncodedJSValue JSC_HOST_CALL functionMallocInALoop(ExecState*);
 
 struct Script {
 enum class StrictMode {
@@ -599,6 +600,7 @@
 addFunction(vm, "flashHeapAccess", functionFlashHeapAccess, 0);
 
 addFunction(vm, "disableRichSourceInfo", functionDisableRichSourceInfo, 0);
+addFunction(vm, "mallocInALoop", functionMallocInALoop, 0);
 }
 
 void addFunction(VM& vm, JSObject* object, const char* name, NativeFunction function, unsigned arguments)
@@ -1748,6 +1750,16 @@
 return JSValue::encode(jsUndefined());
 }
 
+EncodedJSValue JSC_HOST_CALL functionMallocInALoop(ExecState*)
+{
+Vector ptrs;
+for (unsigned i = 0; i < 5000; ++i)
+ptrs.append(fastMalloc(1024 * 2));
+for (void* ptr : ptrs)
+

[webkit-changes] [228454] trunk

2018-02-13 Thread sbarati

Title: [228454] trunk








Revision 228454
Author sbar...@apple.com
Date 2018-02-13 21:07:07 -0800 (Tue, 13 Feb 2018)


Log Message
putDirectIndexSlowOrBeyondVectorLength needs to convert to dictionary indexing mode always if attributes are present
https://bugs.webkit.org/show_bug.cgi?id=182755


Reviewed by Keith Miller.

JSTests:

* stress/always-enter-dictionary-indexing-mode-with-getter.js: Added.
(test1.o.get 10005):
(test1):
(test2.o.get 1000):
(test2):

Source/_javascript_Core:

putDirectIndexSlowOrBeyondVectorLength with non-zero attributes only converted
the object in question to a dictionary indexing mode when the index is less than
the vector length. This makes no sense. If we're defining a getter, setter, or read
only property, we must always enter the dictionary indexing mode irrespective
of the index in relation to the vector length.

* runtime/JSObject.cpp:
(JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/JSObject.cpp


Added Paths

trunk/JSTests/stress/always-enter-dictionary-indexing-mode-with-getter.js




Diff

Modified: trunk/JSTests/ChangeLog (228453 => 228454)

--- trunk/JSTests/ChangeLog	2018-02-14 04:38:33 UTC (rev 228453)
+++ trunk/JSTests/ChangeLog	2018-02-14 05:07:07 UTC (rev 228454)
@@ -1,3 +1,17 @@
+2018-02-13  Saam Barati  
+
+putDirectIndexSlowOrBeyondVectorLength needs to convert to dictionary indexing mode always if attributes are present
+https://bugs.webkit.org/show_bug.cgi?id=182755
+
+
+Reviewed by Keith Miller.
+
+* stress/always-enter-dictionary-indexing-mode-with-getter.js: Added.
+(test1.o.get 10005):
+(test1):
+(test2.o.get 1000):
+(test2):
+
 2018-02-13  Caitlin Potter  
 
 [JSC] cache TaggedTemplate arrays by callsite rather than by contents


Added: trunk/JSTests/stress/always-enter-dictionary-indexing-mode-with-getter.js (0 => 228454)

--- trunk/JSTests/stress/always-enter-dictionary-indexing-mode-with-getter.js	(rev 0)
+++ trunk/JSTests/stress/always-enter-dictionary-indexing-mode-with-getter.js	2018-02-14 05:07:07 UTC (rev 228454)
@@ -0,0 +1,29 @@
+function test1(item) {
+var o = {
+1: item,
+get 10005() { },
+};
+let arr = new Array(10008);
+for (let key of arr.keys()) {
+let o2 = {};
+o[key] = o2;
+}
+}
+test1({});
+test1(10);
+test1(10.5);
+
+function test2(item) {
+var o = {
+0: item,
+get 1000() { },
+};
+let arr = new Array(1000);
+for (let key of arr.keys()) {
+let o2 = {};
+o[key] = o2;
+}
+}
+test2({});
+test2(10);
+test2(10.5);


Modified: trunk/Source/_javascript_Core/ChangeLog (228453 => 228454)

--- trunk/Source/_javascript_Core/ChangeLog	2018-02-14 04:38:33 UTC (rev 228453)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-02-14 05:07:07 UTC (rev 228454)
@@ -1,5 +1,22 @@
 2018-02-13  Saam Barati  
 
+putDirectIndexSlowOrBeyondVectorLength needs to convert to dictionary indexing mode always if attributes are present
+https://bugs.webkit.org/show_bug.cgi?id=182755
+
+
+Reviewed by Keith Miller.
+
+putDirectIndexSlowOrBeyondVectorLength with non-zero attributes only converted
+the object in question to a dictionary indexing mode when the index is less than
+the vector length. This makes no sense. If we're defining a getter, setter, or read
+only property, we must always enter the dictionary indexing mode irrespective
+of the index in relation to the vector length.
+
+* runtime/JSObject.cpp:
+(JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
+
+2018-02-13  Saam Barati  
+
 Follup fix to r228411 for 32-bit builds. I missed a place where we used non vararg getter for child2().
 
 * dfg/DFGSpeculativeJIT32_64.cpp:


Modified: trunk/Source/_javascript_Core/runtime/JSObject.cpp (228453 => 228454)

--- trunk/Source/_javascript_Core/runtime/JSObject.cpp	2018-02-14 04:38:33 UTC (rev 228453)
+++ trunk/Source/_javascript_Core/runtime/JSObject.cpp	2018-02-14 05:07:07 UTC (rev 228454)
@@ -2922,11 +2922,9 @@
 }
 
 case ALL_INT32_INDEXING_TYPES: {
-if (attributes) {
-if (i < m_butterfly->vectorLength())
-return putDirectIndexBeyondVectorLengthWithArrayStorage(exec, i, value, attributes, mode, ensureArrayStorageExistsAndEnterDictionaryIndexingMode(vm));
-return putDirectIndexBeyondVectorLengthWithArrayStorage(exec, i, value, attributes, mode, convertInt32ToArrayStorage(vm));
-}
+ASSERT(!indexingShouldBeSparse());
+if (attributes)
+return putDirectIndexBeyondVectorLengthWithArrayStorage(exec, i, value, attributes, mode,

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

2018-02-13 Thread sbarati

Title: [228438] trunk/Source/_javascript_Core








Revision 228438
Author sbar...@apple.com
Date 2018-02-13 15:03:21 -0800 (Tue, 13 Feb 2018)


Log Message
Follup fix to r228411 for 32-bit builds. I missed a place where we used non vararg getter for child2().

* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT32_64.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (228437 => 228438)

--- trunk/Source/_javascript_Core/ChangeLog	2018-02-13 22:43:50 UTC (rev 228437)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-02-13 23:03:21 UTC (rev 228438)
@@ -1,3 +1,10 @@
+2018-02-13  Saam Barati  
+
+Follup fix to r228411 for 32-bit builds. I missed a place where we used non vararg getter for child2().
+
+* dfg/DFGSpeculativeJIT32_64.cpp:
+(JSC::DFG::SpeculativeJIT::compile):
+
 2018-02-13  Guillaume Emont  
 
 [YarrJIT][ARM] We need to save r8 as it is the initial start register


Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT32_64.cpp (228437 => 228438)

--- trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT32_64.cpp	2018-02-13 22:43:50 UTC (rev 228437)
+++ trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT32_64.cpp	2018-02-13 23:03:21 UTC (rev 228438)
@@ -2576,7 +2576,7 @@
 break;
 }
 
-if (node->child2().useKind() == SymbolUse) {
+if (m_graph.varArgChild(node, 1).useKind() == SymbolUse) {
 compileGetByValForObjectWithSymbol(node);
 break;
 }






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [228401] trunk

2018-02-12 Thread sbarati

Title: [228401] trunk








Revision 228401
Author sbar...@apple.com
Date 2018-02-12 15:41:17 -0800 (Mon, 12 Feb 2018)


Log Message
DFG::emitCodeToGetArgumentsArrayLength needs to handle NewArrayBuffer/PhantomNewArrayBuffer
https://bugs.webkit.org/show_bug.cgi?id=182706


Reviewed by Filip Pizlo.

JSTests:

* stress/get-array-length-phantom-new-array-buffer.js: Added.
(effects):
(foo):

Source/_javascript_Core:

When we added support for PhantomNewArrayBuffer, we forgot to update
the emitCodeToGetArgumentsArrayLength function to handle PhantomNewArrayBuffer.
This patch adds that support. It's trivial to generate the length for
a PhantomNewArrayBuffer node since it's a constant buffer, with a constant
length.

* dfg/DFGArgumentsUtilities.cpp:
(JSC::DFG::emitCodeToGetArgumentsArrayLength):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGArgumentsUtilities.cpp


Added Paths

trunk/JSTests/stress/get-array-length-phantom-new-array-buffer.js




Diff

Modified: trunk/JSTests/ChangeLog (228400 => 228401)

--- trunk/JSTests/ChangeLog	2018-02-12 23:28:51 UTC (rev 228400)
+++ trunk/JSTests/ChangeLog	2018-02-12 23:41:17 UTC (rev 228401)
@@ -1,3 +1,15 @@
+2018-02-12  Saam Barati  
+
+DFG::emitCodeToGetArgumentsArrayLength needs to handle NewArrayBuffer/PhantomNewArrayBuffer
+https://bugs.webkit.org/show_bug.cgi?id=182706
+
+
+Reviewed by Filip Pizlo.
+
+* stress/get-array-length-phantom-new-array-buffer.js: Added.
+(effects):
+(foo):
+
 2018-02-09  Filip Pizlo  
 
 Don't waste memory for error.stack


Added: trunk/JSTests/stress/get-array-length-phantom-new-array-buffer.js (0 => 228401)

--- trunk/JSTests/stress/get-array-length-phantom-new-array-buffer.js	(rev 0)
+++ trunk/JSTests/stress/get-array-length-phantom-new-array-buffer.js	2018-02-12 23:41:17 UTC (rev 228401)
@@ -0,0 +1,14 @@
+function effects() {}
+noInline(effects);
+
+function foo() {
+let x = [1,2,3];
+effects();
+return x.length;
+}
+noInline(foo);
+
+for (let i = 0; i < 10; ++i) {
+if (foo() !== 3)
+throw new Error();
+}


Modified: trunk/Source/_javascript_Core/ChangeLog (228400 => 228401)

--- trunk/Source/_javascript_Core/ChangeLog	2018-02-12 23:28:51 UTC (rev 228400)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-02-12 23:41:17 UTC (rev 228401)
@@ -1,3 +1,20 @@
+2018-02-12  Saam Barati  
+
+DFG::emitCodeToGetArgumentsArrayLength needs to handle NewArrayBuffer/PhantomNewArrayBuffer
+https://bugs.webkit.org/show_bug.cgi?id=182706
+
+
+Reviewed by Filip Pizlo.
+
+When we added support for PhantomNewArrayBuffer, we forgot to update
+the emitCodeToGetArgumentsArrayLength function to handle PhantomNewArrayBuffer.
+This patch adds that support. It's trivial to generate the length for
+a PhantomNewArrayBuffer node since it's a constant buffer, with a constant
+length.
+
+* dfg/DFGArgumentsUtilities.cpp:
+(JSC::DFG::emitCodeToGetArgumentsArrayLength):
+
 2018-02-12  Mark Lam  
 
 Add more support for pointer preparations.


Modified: trunk/Source/_javascript_Core/dfg/DFGArgumentsUtilities.cpp (228400 => 228401)

--- trunk/Source/_javascript_Core/dfg/DFGArgumentsUtilities.cpp	2018-02-12 23:28:51 UTC (rev 228400)
+++ trunk/Source/_javascript_Core/dfg/DFGArgumentsUtilities.cpp	2018-02-12 23:41:17 UTC (rev 228401)
@@ -65,9 +65,15 @@
 DFG_ASSERT(
 graph, arguments,
 arguments->op() == CreateDirectArguments || arguments->op() == CreateScopedArguments
-|| arguments->op() == CreateClonedArguments || arguments->op() == CreateRest
-|| arguments->op() == PhantomDirectArguments || arguments->op() == PhantomClonedArguments || arguments->op() == PhantomCreateRest,
+|| arguments->op() == CreateClonedArguments || arguments->op() == CreateRest || arguments->op() == NewArrayBuffer
+|| arguments->op() == PhantomDirectArguments || arguments->op() == PhantomClonedArguments
+|| arguments->op() == PhantomCreateRest || arguments->op() == PhantomNewArrayBuffer,
 arguments->op());
+
+if (arguments->op() == NewArrayBuffer || arguments->op() == PhantomNewArrayBuffer) {
+return insertionSet.insertConstant(
+nodeIndex, origin, jsNumber(arguments->castOperand()->length()));
+}
 
 InlineCallFrame* inlineCallFrame = arguments->origin.semantic.inlineCallFrame;
 






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2018-02-02 Thread sbarati

Title: [228035] trunk/Source/_javascript_Core








Revision 228035
Author sbar...@apple.com
Date 2018-02-02 16:43:14 -0800 (Fri, 02 Feb 2018)


Log Message
Make various DFG_ASSERTs provide more data to WTFCrashWithInfo
https://bugs.webkit.org/show_bug.cgi?id=182453


Reviewed by JF Bastien and Mark Lam.

* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGArgumentsUtilities.cpp:
(JSC::DFG::emitCodeToGetArgumentsArrayLength):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupChecksInBlock):
* dfg/DFGFlowIndexing.h:
(JSC::DFG::FlowIndexing::shadowIndex const):
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::run):
(JSC::DFG::LICMPhase::attemptHoist):
* dfg/DFGLoopPreHeaderCreationPhase.cpp:
(JSC::DFG::LoopPreHeaderCreationPhase::run):
* dfg/DFGPutStackSinkingPhase.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithAbs):
(JSC::DFG::SpeculativeJIT::compileArithRounding):
(JSC::DFG::SpeculativeJIT::compileToPrimitive):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillJSValue):
(JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
(JSC::DFG::SpeculativeJIT::fillSpeculateInt32Strict):
(JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
(JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierClusteringPhase.cpp:
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetStack):
(JSC::FTL::DFG::LowerDFGToB3::compileArithClz32):
(JSC::FTL::DFG::LowerDFGToB3::compileArithAbs):
(JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
(JSC::FTL::DFG::LowerDFGToB3::compileArithFloor):
(JSC::FTL::DFG::LowerDFGToB3::compileArithCeil):
(JSC::FTL::DFG::LowerDFGToB3::compileArithTrunc):
(JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
(JSC::FTL::DFG::LowerDFGToB3::compilePutById):
(JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareEq):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
(JSC::FTL::DFG::LowerDFGToB3::compileIn):
(JSC::FTL::DFG::LowerDFGToB3::compare):
(JSC::FTL::DFG::LowerDFGToB3::switchStringRecurse):
(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::lowJSValue):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h
trunk/Source/_javascript_Core/dfg/DFGArgumentsEliminationPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGArgumentsUtilities.cpp
trunk/Source/_javascript_Core/dfg/DFGFixupPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGFlowIndexing.h
trunk/Source/_javascript_Core/dfg/DFGLICMPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGLoopPreHeaderCreationPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGPutStackSinkingPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp
trunk/Source/_javascript_Core/dfg/DFGStoreBarrierClusteringPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGStoreBarrierInsertionPhase.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (228034 => 228035)

--- trunk/Source/_javascript_Core/ChangeLog	2018-02-03 00:39:31 UTC (rev 228034)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-02-03 00:43:14 UTC (rev 228035)
@@ -1,3 +1,66 @@
+2018-02-02  Saam Barati  
+
+Make various DFG_ASSERTs provide more data to WTFCrashWithInfo
+https://bugs.webkit.org/show_bug.cgi?id=182453
+
+
+Reviewed by JF Bastien and Mark Lam.
+
+* dfg/DFGAbstractInterpreterInlines.h:
+(JSC::DFG::AbstractInterpreter::executeEffects):
+* dfg/DFGArgumentsEliminationPhase.cpp:
+* dfg/DFGArgumentsUtilities.cpp:
+(JSC::DFG::emitCodeToGetArgumentsArrayLength):
+* dfg/DFGFixupPhase.cpp:
+(JSC::DFG::FixupPhase::fixupChecksInBlock):
+* dfg/DFGFlowIndexing.h:
+(JSC::DFG::FlowIndexing::shadowIndex const):
+* dfg/DFGLICMPhase.cpp:
+(JSC::DFG::LICMPhase::run):
+(JSC::DFG::LICMPhase::attemptHoist):
+* dfg/DFGLoopPreHeaderCreationPhase.cpp:
+(JSC::DFG::LoopPreHeaderCreationPhase::run):
+* dfg/DFGPutStackSinkingPhase.cpp:
+* dfg/DFGSpeculativeJIT.cpp:
+(JSC::DFG::SpeculativeJIT::compileArithAbs):
+(JSC::DFG::SpeculativeJIT::compileArithRounding):
+(JSC::DFG::SpeculativeJIT::compileToPrimitive):
+* dfg/DFGSpeculativeJIT64.cpp:
+(JSC::DFG::SpeculativeJIT::fillJSValue):
+

[webkit-changes] [228031] trunk

2018-02-02 Thread sbarati

Title: [228031] trunk








Revision 228031
Author sbar...@apple.com
Date 2018-02-02 14:55:29 -0800 (Fri, 02 Feb 2018)


Log Message
When BytecodeParser inserts Unreachable after ForceOSRExit it needs to update ArgumentPositions for Flushes it inserts
https://bugs.webkit.org/show_bug.cgi?id=182368


Reviewed by Mark Lam.

JSTests:

* stress/flush-after-force-exit-in-bytecodeparser-needs-to-update-argument-positions.js: Added.
(runNearStackLimit.t):
(runNearStackLimit):
(try.runNearStackLimit):
(catch):

Source/_javascript_Core:

When preserving liveness when inserting Unreachable nodes after ForceOSRExit,
we must add the VariableAccessData to the given argument position. Otherwise,
we may end up with a VariableAccessData that doesn't respect the shouldNeverUnbox bit.
If we end up with such a situation, it can lead to invalid IR after the
arguments elimination phase optimizes a GetByVal to a GetStack.

* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::flushImpl):
(JSC::DFG::ByteCodeParser::flushForTerminalImpl):
(JSC::DFG::ByteCodeParser::flush):
(JSC::DFG::ByteCodeParser::flushForTerminal):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
(JSC::DFG::ByteCodeParser::parse):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp


Added Paths

trunk/JSTests/stress/flush-after-force-exit-in-bytecodeparser-needs-to-update-argument-positions.js




Diff

Modified: trunk/JSTests/ChangeLog (228030 => 228031)

--- trunk/JSTests/ChangeLog	2018-02-02 22:52:56 UTC (rev 228030)
+++ trunk/JSTests/ChangeLog	2018-02-02 22:55:29 UTC (rev 228031)
@@ -1,3 +1,17 @@
+2018-02-02  Saam Barati  
+
+When BytecodeParser inserts Unreachable after ForceOSRExit it needs to update ArgumentPositions for Flushes it inserts
+https://bugs.webkit.org/show_bug.cgi?id=182368
+
+
+Reviewed by Mark Lam.
+
+* stress/flush-after-force-exit-in-bytecodeparser-needs-to-update-argument-positions.js: Added.
+(runNearStackLimit.t):
+(runNearStackLimit):
+(try.runNearStackLimit):
+(catch):
+
 2018-02-02  Yusuke Suzuki  
 
 Update test262 to Jan 30 version


Added: trunk/JSTests/stress/flush-after-force-exit-in-bytecodeparser-needs-to-update-argument-positions.js (0 => 228031)

--- trunk/JSTests/stress/flush-after-force-exit-in-bytecodeparser-needs-to-update-argument-positions.js	(rev 0)
+++ trunk/JSTests/stress/flush-after-force-exit-in-bytecodeparser-needs-to-update-argument-positions.js	2018-02-02 22:55:29 UTC (rev 228031)
@@ -0,0 +1,32 @@
+//@ runDefault("--useConcurrentGC=0", "--thresholdForJITAfterWarmUp=10", "--thresholdForJITSoon=10", "--thresholdForOptimizeAfterWarmUp=20", "--thresholdForOptimizeAfterLongWarmUp=20", "--thresholdForOptimizeSoon=20", "--thresholdForFTLOptimizeAfterWarmUp=20", "--thresholdForFTLOptimizeSoon=20", "--maximumEvalCacheableSourceLength=15", "--maxPerThreadStackUsage=1048576")
+
+function runNearStackLimit(f) {
+function t() {
+try {
+return t();
+} catch (e) {
+return f();
+}
+}
+return t();
+};
+
+runNearStackLimit(() => { });
+runNearStackLimit(() => { });
+
+function f2(a, b) {
+'use strict';
+try {
+a.push(arguments[0] + arguments[2] + a + undefinedVariable);
+} catch (e) { }
+}
+
+try {
+runNearStackLimit(() => {
+return f2(1, 2, 3);
+});
+} catch (e) {}
+
+try {
+runNearStackLimit();
+} catch { }


Modified: trunk/Source/_javascript_Core/ChangeLog (228030 => 228031)

--- trunk/Source/_javascript_Core/ChangeLog	2018-02-02 22:52:56 UTC (rev 228030)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-02-02 22:55:29 UTC (rev 228031)
@@ -1,3 +1,25 @@
+2018-02-02  Saam Barati  
+
+When BytecodeParser inserts Unreachable after ForceOSRExit it needs to update ArgumentPositions for Flushes it inserts
+https://bugs.webkit.org/show_bug.cgi?id=182368
+
+
+Reviewed by Mark Lam.
+
+When preserving liveness when inserting Unreachable nodes after ForceOSRExit,
+we must add the VariableAccessData to the given argument position. Otherwise,
+we may end up with a VariableAccessData that doesn't respect the shouldNeverUnbox bit.
+If we end up with such a situation, it can lead to invalid IR after the
+arguments elimination phase optimizes a GetByVal to a GetStack.
+
+* dfg/DFGByteCodeParser.cpp:
+(JSC::DFG::ByteCodeParser::flushImpl):
+(JSC::DFG::ByteCodeParser::flushForTerminalImpl):
+(JSC::DFG::ByteCodeParser::flush):
+(JSC::DFG::ByteCodeParser::flushForTerminal):
+(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
+(JSC::DFG::ByteCodeParser::parse):
+
 2018-02-02  Mark Lam  
 
 More ARM64_32 fixes.

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

2018-02-02 Thread sbarati

Title: [228018] trunk/Source/_javascript_Core








Revision 228018
Author sbar...@apple.com
Date 2018-02-02 11:07:31 -0800 (Fri, 02 Feb 2018)


Log Message
MapHash should return true to doesGC in the DFG depending on useKind because it might resolve a rope
https://bugs.webkit.org/show_bug.cgi?id=182402

Reviewed by Yusuke Suzuki.

* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGDoesGC.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (228017 => 228018)

--- trunk/Source/_javascript_Core/ChangeLog	2018-02-02 18:51:37 UTC (rev 228017)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-02-02 19:07:31 UTC (rev 228018)
@@ -1,3 +1,13 @@
+2018-02-02  Saam Barati  
+
+MapHash should return true to doesGC in the DFG depending on useKind because it might resolve a rope
+https://bugs.webkit.org/show_bug.cgi?id=182402
+
+Reviewed by Yusuke Suzuki.
+
+* dfg/DFGDoesGC.cpp:
+(JSC::DFG::doesGC):
+
 2018-02-02  Yusuke Suzuki  
 
 [JSC] Clean up ArraySpeciesCreate


Modified: trunk/Source/_javascript_Core/dfg/DFGDoesGC.cpp (228017 => 228018)

--- trunk/Source/_javascript_Core/dfg/DFGDoesGC.cpp	2018-02-02 18:51:37 UTC (rev 228017)
+++ trunk/Source/_javascript_Core/dfg/DFGDoesGC.cpp	2018-02-02 19:07:31 UTC (rev 228018)
@@ -205,7 +205,6 @@
 case CPUIntrinsic:
 case CheckTraps:
 case StringFromCharCode:
-case MapHash:
 case NormalizeMapKey:
 case GetMapBucket:
 case GetMapBucketHead:
@@ -355,6 +354,18 @@
 case SetAdd:
 case MapSet:
 return true;
+
+case MapHash:
+switch (node->child1().useKind()) {
+case BooleanUse:
+case Int32Use:
+case SymbolUse:
+case ObjectUse:
+return false;
+default:
+// We might resolve a rope.
+return true;
+}
 
 case MultiPutByOffset:
 return node->multiPutByOffsetData().reallocatesStorage();






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [227951] trunk/Source

2018-01-31 Thread sbarati

Title: [227951] trunk/Source








Revision 227951
Author sbar...@apple.com
Date 2018-01-31 21:36:40 -0800 (Wed, 31 Jan 2018)


Log Message
Replace tryLargeMemalignVirtual with tryLargeZeroedMemalignVirtual and use it to allocate large zeroed memory in Wasm
https://bugs.webkit.org/show_bug.cgi?id=182064


Reviewed by Geoffrey Garen.

Source/bmalloc:

This patch replaces the tryLargeMemalignVirtual API with tryLargeZeroedMemalignVirtual.
By doing that, we're able to remove the AllocationKind enum. To zero the memory,
tryLargeZeroedMemalignVirtual uses mmap(... MAP_ANON ...) over previously mmapped
memory. This both purges the any resident memory for the virtual range and ensures
that the pages in the range are zeroed. Most OSs should implement this by taking a
page fault and zero filling on first access. Therefore, this API is returning pages
that will result in page faults on first access. Hence, the name 'virtual' in the API.
This API differs from the old API in that users of it need not call madvise themselves.
The memory is ready to go.

* bmalloc.xcodeproj/project.pbxproj:
* bmalloc/AllocationKind.h: Removed.
* bmalloc/DebugHeap.cpp:
(bmalloc::DebugHeap::memalignLarge):
(bmalloc::DebugHeap::freeLarge):
* bmalloc/DebugHeap.h:
* bmalloc/Heap.cpp:
(bmalloc::Heap::splitAndAllocate):
(bmalloc::Heap::tryAllocateLarge):
(bmalloc::Heap::allocateLarge):
(bmalloc::Heap::shrinkLarge):
(bmalloc::Heap::deallocateLarge):
* bmalloc/Heap.h:
* bmalloc/IsoPage.cpp:
(bmalloc::IsoPageBase::allocatePageMemory):
* bmalloc/VMAllocate.h:
(bmalloc::vmZeroAndPurge):
* bmalloc/VMHeap.cpp:
(bmalloc::VMHeap::tryAllocateLargeChunk):
* bmalloc/VMHeap.h:
* bmalloc/bmalloc.cpp:
(bmalloc::api::tryLargeZeroedMemalignVirtual):
(bmalloc::api::freeLargeVirtual):
(bmalloc::api::tryLargeMemalignVirtual): Deleted.
* bmalloc/bmalloc.h:

Source/_javascript_Core:

This patch switches WebAssembly Memory to always use bmalloc's
zeroed virtual allocation API. This makes it so that we don't
dirty the memory to zero it. It's a huge compile time speedup
on WasmBench on iOS.

* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::create):
(JSC::Wasm::Memory::~Memory):
(JSC::Wasm::Memory::addressIsInActiveFastMemory):
(JSC::Wasm::Memory::grow):
(JSC::Wasm::commitZeroPages): Deleted.

Source/WTF:

* wtf/Gigacage.cpp:
(Gigacage::tryAllocateZeroedVirtualPages):
(Gigacage::freeVirtualPages):
(Gigacage::tryAllocateVirtualPages): Deleted.
* wtf/Gigacage.h:
* wtf/OSAllocator.h:

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/wasm/WasmMemory.cpp
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/Gigacage.cpp
trunk/Source/WTF/wtf/Gigacage.h
trunk/Source/WTF/wtf/OSAllocator.h
trunk/Source/bmalloc/ChangeLog
trunk/Source/bmalloc/bmalloc/DebugHeap.cpp
trunk/Source/bmalloc/bmalloc/DebugHeap.h
trunk/Source/bmalloc/bmalloc/Heap.cpp
trunk/Source/bmalloc/bmalloc/Heap.h
trunk/Source/bmalloc/bmalloc/IsoPage.cpp
trunk/Source/bmalloc/bmalloc/VMAllocate.h
trunk/Source/bmalloc/bmalloc/VMHeap.cpp
trunk/Source/bmalloc/bmalloc/VMHeap.h
trunk/Source/bmalloc/bmalloc/bmalloc.cpp
trunk/Source/bmalloc/bmalloc/bmalloc.h
trunk/Source/bmalloc/bmalloc.xcodeproj/project.pbxproj


Removed Paths

trunk/Source/bmalloc/bmalloc/AllocationKind.h




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (227950 => 227951)

--- trunk/Source/_javascript_Core/ChangeLog	2018-02-01 04:27:12 UTC (rev 227950)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-02-01 05:36:40 UTC (rev 227951)
@@ -1,3 +1,23 @@
+2018-01-31  Saam Barati  
+
+Replace tryLargeMemalignVirtual with tryLargeZeroedMemalignVirtual and use it to allocate large zeroed memory in Wasm
+https://bugs.webkit.org/show_bug.cgi?id=182064
+
+
+Reviewed by Geoffrey Garen.
+
+This patch switches WebAssembly Memory to always use bmalloc's
+zeroed virtual allocation API. This makes it so that we don't
+dirty the memory to zero it. It's a huge compile time speedup
+on WasmBench on iOS.
+
+* wasm/WasmMemory.cpp:
+(JSC::Wasm::Memory::create):
+(JSC::Wasm::Memory::~Memory):
+(JSC::Wasm::Memory::addressIsInActiveFastMemory):
+(JSC::Wasm::Memory::grow):
+(JSC::Wasm::commitZeroPages): Deleted.
+
 2018-01-31  Mark Lam  
 
 Build fix for CLoop after r227874.


Modified: trunk/Source/_javascript_Core/wasm/WasmMemory.cpp (227950 => 227951)

--- trunk/Source/_javascript_Core/wasm/WasmMemory.cpp	2018-02-01 04:27:12 UTC (rev 227950)
+++ trunk/Source/_javascript_Core/wasm/WasmMemory.cpp	2018-02-01 05:36:40 UTC (rev 227951)
@@ -95,26 +95,26 @@
 class MemoryManager {
 public:
 MemoryManager()
-: m_maxCount(Options::maxNumWebAssemblyFastMemories())
+: m_maxFastMemoryCount(Options::maxNumWebAssemblyFastMemories())
 {
 }
 
-MemoryResult tryAllocateVirtualPages()
+MemoryResult tryAllocateFastMemory()
 {
 MemoryResult result = [&] {

[webkit-changes] [227898] trunk

2018-01-31 Thread sbarati

Title: [227898] trunk








Revision 227898
Author sbar...@apple.com
Date 2018-01-31 02:18:28 -0800 (Wed, 31 Jan 2018)


Log Message
JSC incorrectly interpreting script, sets Global Property instead of Global Lexical variable (LiteralParser / JSONP path)
https://bugs.webkit.org/show_bug.cgi?id=182074


Reviewed by Mark Lam.

JSTests:

* stress/jsonp-program-evaluate-path-must-consider-global-lexical-environment.js: Added.
(assert):
(let.func):
(let.o.foo):
(varFunc):

LayoutTests/imported/w3c:

* web-platform-tests/service-workers/service-worker/import-scripts-updated-flag.https-expected.txt:

Source/_javascript_Core:

This patch teaches the JSONP evaluator about the global lexical environment.
Before, it was using the global object as the global scope, but that's wrong.
The global lexical environment is the first node in the global scope chain.

* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
* jsc.cpp:
(GlobalObject::finishCreation):
(shellSupportsRichSourceInfo):
(functionDisableRichSourceInfo):
* runtime/LiteralParser.cpp:
(JSC::LiteralParser::tryJSONPParse):
* runtime/LiteralParser.h:

LayoutTests:

* http/tests/security/regress-52192-expected.txt:

Modified Paths

trunk/JSTests/ChangeLog
trunk/LayoutTests/ChangeLog
trunk/LayoutTests/http/tests/security/regress-52192-expected.txt
trunk/LayoutTests/imported/w3c/ChangeLog
trunk/LayoutTests/imported/w3c/web-platform-tests/service-workers/service-worker/import-scripts-updated-flag.https-expected.txt
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/interpreter/Interpreter.cpp
trunk/Source/_javascript_Core/jsc.cpp
trunk/Source/_javascript_Core/runtime/LiteralParser.cpp
trunk/Source/_javascript_Core/runtime/LiteralParser.h


Added Paths

trunk/JSTests/stress/jsonp-program-evaluate-path-must-consider-global-lexical-environment.js




Diff

Modified: trunk/JSTests/ChangeLog (227897 => 227898)

--- trunk/JSTests/ChangeLog	2018-01-31 10:04:57 UTC (rev 227897)
+++ trunk/JSTests/ChangeLog	2018-01-31 10:18:28 UTC (rev 227898)
@@ -1,3 +1,17 @@
+2018-01-31  Saam Barati  
+
+JSC incorrectly interpreting script, sets Global Property instead of Global Lexical variable (LiteralParser / JSONP path)
+https://bugs.webkit.org/show_bug.cgi?id=182074
+
+
+Reviewed by Mark Lam.
+
+* stress/jsonp-program-evaluate-path-must-consider-global-lexical-environment.js: Added.
+(assert):
+(let.func):
+(let.o.foo):
+(varFunc):
+
 2018-01-30  Yusuke Suzuki  
 
 Unreviewed, update test262 expects


Added: trunk/JSTests/stress/jsonp-program-evaluate-path-must-consider-global-lexical-environment.js (0 => 227898)

--- trunk/JSTests/stress/jsonp-program-evaluate-path-must-consider-global-lexical-environment.js	(rev 0)
+++ trunk/JSTests/stress/jsonp-program-evaluate-path-must-consider-global-lexical-environment.js	2018-01-31 10:18:28 UTC (rev 227898)
@@ -0,0 +1,53 @@
+function assert(b) {
+if (!b)
+throw new Error("Bad");
+}
+
+disableRichSourceInfo(); // This is needed for the JSONP path to be taken for calls.
+
+let a = 22;
+loadString("a = 42");
+assert(a === 42);
+
+let b = {f: 22};
+loadString("b.f = 42");
+assert(b.f === 42);
+
+let foo = null;
+let bar = 42;
+loadString("foo = 'root'; bar = 5")
+assert(foo === "root");
+assert(bar === 5);
+
+let called = false;
+let func = (a) => {
+assert(a.foo === 20);
+called = true;
+};
+
+loadString("func({foo:20})");
+assert(called);
+
+called = false;
+let o = {
+foo(arg) {
+assert(arg.foo === 20);
+called = true;
+}
+};
+
+loadString("o.foo({foo:20})");
+assert(called);
+
+var theVar = 20;
+loadString("theVar = 42");
+assert(theVar === 42);
+assert(this.theVar === 42);
+
+called = false;
+var varFunc = (a) => {
+assert(a.foo === 20);
+called = true;
+};
+loadString("varFunc({foo:20})");
+assert(called);


Modified: trunk/LayoutTests/ChangeLog (227897 => 227898)

--- trunk/LayoutTests/ChangeLog	2018-01-31 10:04:57 UTC (rev 227897)
+++ trunk/LayoutTests/ChangeLog	2018-01-31 10:18:28 UTC (rev 227898)
@@ -1,3 +1,13 @@
+2018-01-31  Saam Barati  
+
+JSC incorrectly interpreting script, sets Global Property instead of Global Lexical variable (LiteralParser / JSONP path)
+https://bugs.webkit.org/show_bug.cgi?id=182074
+
+
+Reviewed by Mark Lam.
+
+* http/tests/security/regress-52192-expected.txt:
+
 2018-01-30  John Wilander  
 
 Add callbacks to testRunner.statisticsSetShouldPartitionCookiesForHost() and testRunner.statisticsUpdateCookiePartitioning()


Modified: trunk/LayoutTests/http/tests/security/regress-52192-expected.txt (227897 => 227898)

--- trunk/LayoutTests/http/tests/security/regress-52192-expected.txt	2018-01-31 10:04:57 UTC (rev 227897)
+++ trunk/LayoutTests/http/tests/security/regress-52192-expected.txt	2018-01-31

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

2018-01-31 Thread sbarati

Title: [227897] trunk/Source/_javascript_Core








Revision 227897
Author sbar...@apple.com
Date 2018-01-31 02:04:57 -0800 (Wed, 31 Jan 2018)


Log Message
clean up pushToSaveImmediateWithoutTouchingRegisters a bit
https://bugs.webkit.org/show_bug.cgi?id=181774

Reviewed by JF Bastien.

This function on ARM64 was considering what to do with the scratch
register. And conditionally invalidated what was in it. This is not
relevant though, since the function always recovers what was in that
register. This patch just switches it to using dataTempRegister
directly and updates the comment to describe why it can do so safely.

* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::pushToSaveImmediateWithoutTouchingRegisters):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/assembler/MacroAssemblerARM64.h




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (227896 => 227897)

--- trunk/Source/_javascript_Core/ChangeLog	2018-01-31 09:58:06 UTC (rev 227896)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-01-31 10:04:57 UTC (rev 227897)
@@ -1,3 +1,19 @@
+2018-01-31  Saam Barati  
+
+clean up pushToSaveImmediateWithoutTouchingRegisters a bit
+https://bugs.webkit.org/show_bug.cgi?id=181774
+
+Reviewed by JF Bastien.
+
+This function on ARM64 was considering what to do with the scratch
+register. And conditionally invalidated what was in it. This is not
+relevant though, since the function always recovers what was in that
+register. This patch just switches it to using dataTempRegister
+directly and updates the comment to describe why it can do so safely.
+
+* assembler/MacroAssemblerARM64.h:
+(JSC::MacroAssemblerARM64::pushToSaveImmediateWithoutTouchingRegisters):
+
 2018-01-30  Mark Lam  
 
 Apply poisoning to TypedArray vector pointers.


Modified: trunk/Source/_javascript_Core/assembler/MacroAssemblerARM64.h (227896 => 227897)

--- trunk/Source/_javascript_Core/assembler/MacroAssemblerARM64.h	2018-01-31 09:58:06 UTC (rev 227896)
+++ trunk/Source/_javascript_Core/assembler/MacroAssemblerARM64.h	2018-01-31 10:04:57 UTC (rev 227897)
@@ -2203,8 +2203,11 @@
 
 void pushToSaveImmediateWithoutTouchingRegisters(TrustedImm32 imm)
 {
-// We invalidate any cached values in dataTempRegister if temp register caching is enabled.
-RegisterID reg = m_allowScratchRegister ? getCachedDataTempRegisterIDAndInvalidate() : dataTempRegister;
+// We can use any non-hardware reserved register here since we restore its value.
+// We pick dataTempRegister arbitrarily. We don't need to invalidate it here since
+// we restore its original value.
+RegisterID reg = dataTempRegister;
+
 pushPair(reg, reg);
 move(imm, reg);
 store64(reg, stackPointerRegister);






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [227236] trunk

2018-01-19 Thread sbarati

Title: [227236] trunk








Revision 227236
Author sbar...@apple.com
Date 2018-01-19 14:30:45 -0800 (Fri, 19 Jan 2018)


Log Message
Kill ArithNegate's ArithProfile assert inside BytecodeParser
https://bugs.webkit.org/show_bug.cgi?id=181877


Reviewed by Mark Lam.

JSTests:

* stress/arith-profile-for-negate-can-see-non-number-due-to-dfg-osr-exit-profiling.js: Added.
(runNearStackLimit):
(f1):
(f2):
(f3):
(i.catch):
(i.try.runNearStackLimit):
(catch):

Source/_javascript_Core:

Before this patch, we used to assert that op_negate's result ArithProfile
only produces number. It's logically true that negate only produces a number.
However, the DFG may incorrectly pick this ArithProfile when doing OSR exit
profiling. So we'll end up profiling something that's likely the input to
negate. This patch removes the assert. We cede to the fact that Graph::methodOfGettingAValueProfileFor
is entirely heuristic based, potentially leading to profiling results being imprecise.

* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::makeSafe):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp


Added Paths

trunk/JSTests/stress/arith-profile-for-negate-can-see-non-number-due-to-dfg-osr-exit-profiling.js




Diff

Modified: trunk/JSTests/ChangeLog (227235 => 227236)

--- trunk/JSTests/ChangeLog	2018-01-19 22:16:21 UTC (rev 227235)
+++ trunk/JSTests/ChangeLog	2018-01-19 22:30:45 UTC (rev 227236)
@@ -1,5 +1,22 @@
 2018-01-19  Saam Barati  
 
+Kill ArithNegate's ArithProfile assert inside BytecodeParser
+https://bugs.webkit.org/show_bug.cgi?id=181877
+
+
+Reviewed by Mark Lam.
+
+* stress/arith-profile-for-negate-can-see-non-number-due-to-dfg-osr-exit-profiling.js: Added.
+(runNearStackLimit):
+(f1):
+(f2):
+(f3):
+(i.catch):
+(i.try.runNearStackLimit):
+(catch):
+
+2018-01-19  Saam Barati  
+
 Spread's effects are modeled incorrectly both in AI and in Clobberize
 https://bugs.webkit.org/show_bug.cgi?id=181867
 


Added: trunk/JSTests/stress/arith-profile-for-negate-can-see-non-number-due-to-dfg-osr-exit-profiling.js (0 => 227236)

--- trunk/JSTests/stress/arith-profile-for-negate-can-see-non-number-due-to-dfg-osr-exit-profiling.js	(rev 0)
+++ trunk/JSTests/stress/arith-profile-for-negate-can-see-non-number-due-to-dfg-osr-exit-profiling.js	2018-01-19 22:30:45 UTC (rev 227236)
@@ -0,0 +1,32 @@
+function runNearStackLimit(f) {
+try {
+return t();
+} catch (e) {
+return f();
+}
+}
+let flag = false;
+function f1() {
+return flag ? {} : 10;
+}
+noInline(f1);
+
+function f2() {
+}
+
+function f3(arg) {
+let r = -(arg ? f1() : f2());
+}
+
+for (let i = 0; i < 10; ++i) {
+try {
+f3(!!(i % 2));
+} catch (e) {}
+} 
+
+flag = true;
+for (let i = 0; i < 10; ++i) try {
+runNearStackLimit(() => {
+return f3(!!(i % 2));
+});
+} catch (e) {}


Modified: trunk/Source/_javascript_Core/ChangeLog (227235 => 227236)

--- trunk/Source/_javascript_Core/ChangeLog	2018-01-19 22:16:21 UTC (rev 227235)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-01-19 22:30:45 UTC (rev 227236)
@@ -1,3 +1,21 @@
+2018-01-19  Saam Barati  
+
+Kill ArithNegate's ArithProfile assert inside BytecodeParser
+https://bugs.webkit.org/show_bug.cgi?id=181877
+
+
+Reviewed by Mark Lam.
+
+Before this patch, we used to assert that op_negate's result ArithProfile
+only produces number. It's logically true that negate only produces a number.
+However, the DFG may incorrectly pick this ArithProfile when doing OSR exit
+profiling. So we'll end up profiling something that's likely the input to
+negate. This patch removes the assert. We cede to the fact that Graph::methodOfGettingAValueProfileFor
+is entirely heuristic based, potentially leading to profiling results being imprecise.
+
+* dfg/DFGByteCodeParser.cpp:
+(JSC::DFG::ByteCodeParser::makeSafe):
+
 2018-01-19  David Kilzer  
 
 oss-fuzz jsc build is broken: StringImpl.h:27:10: fatal error: 'unicode/ustring.h' file not found


Modified: trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp (227235 => 227236)

--- trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp	2018-01-19 22:16:21 UTC (rev 227235)
+++ trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp	2018-01-19 22:30:45 UTC (rev 227236)
@@ -940,8 +940,10 @@
 break;
 }
 case ArithNegate: {
-ASSERT_WITH_MESSAGE(!arithProfile->didObserveNonNumber(), "op_negate starts with a toNumber() on the argument, it should only produce numbers.");
-
+// We'd like to assert here that the arith profile for

[webkit-changes] [227104] trunk

2018-01-17 Thread sbarati

Title: [227104] trunk








Revision 227104
Author sbar...@apple.com
Date 2018-01-17 17:58:25 -0800 (Wed, 17 Jan 2018)


Log Message
Disable Atomics when SharedArrayBuffer isn’t enabled
https://bugs.webkit.org/show_bug.cgi?id=181572


Reviewed by Michael Saboff.

JSTests:

* stress/isLockFree.js:

Source/_javascript_Core:

* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::createAtomicsProperty): Deleted.

Modified Paths

trunk/JSTests/ChangeLog
trunk/JSTests/stress/isLockFree.js
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/JSGlobalObject.cpp




Diff

Modified: trunk/JSTests/ChangeLog (227103 => 227104)

--- trunk/JSTests/ChangeLog	2018-01-18 01:58:05 UTC (rev 227103)
+++ trunk/JSTests/ChangeLog	2018-01-18 01:58:25 UTC (rev 227104)
@@ -1,5 +1,15 @@
 2018-01-17  Saam Barati  
 
+Disable Atomics when SharedArrayBuffer isn’t enabled
+https://bugs.webkit.org/show_bug.cgi?id=181572
+
+
+Reviewed by Michael Saboff.
+
+* stress/isLockFree.js:
+
+2018-01-17  Saam Barati  
+
 DFG::Node::convertToConstant needs to clear the varargs flags
 https://bugs.webkit.org/show_bug.cgi?id=181697
 


Modified: trunk/JSTests/stress/isLockFree.js (227103 => 227104)

--- trunk/JSTests/stress/isLockFree.js	2018-01-18 01:58:05 UTC (rev 227103)
+++ trunk/JSTests/stress/isLockFree.js	2018-01-18 01:58:25 UTC (rev 227104)
@@ -1,3 +1,5 @@
+//@ skip
+
 function foo(bytes) {
 return Atomics.isLockFree(bytes);
 }


Modified: trunk/Source/_javascript_Core/ChangeLog (227103 => 227104)

--- trunk/Source/_javascript_Core/ChangeLog	2018-01-18 01:58:05 UTC (rev 227103)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-01-18 01:58:25 UTC (rev 227104)
@@ -1,5 +1,17 @@
 2018-01-17  Saam Barati  
 
+Disable Atomics when SharedArrayBuffer isn’t enabled
+https://bugs.webkit.org/show_bug.cgi?id=181572
+
+
+Reviewed by Michael Saboff.
+
+* runtime/JSGlobalObject.cpp:
+(JSC::JSGlobalObject::init):
+(JSC::createAtomicsProperty): Deleted.
+
+2018-01-17  Saam Barati  
+
 Support MultiGetByOffset in the DFG
 https://bugs.webkit.org/show_bug.cgi?id=181466
 


Modified: trunk/Source/_javascript_Core/runtime/JSGlobalObject.cpp (227103 => 227104)

--- trunk/Source/_javascript_Core/runtime/JSGlobalObject.cpp	2018-01-18 01:58:05 UTC (rev 227103)
+++ trunk/Source/_javascript_Core/runtime/JSGlobalObject.cpp	2018-01-18 01:58:25 UTC (rev 227104)
@@ -212,12 +212,6 @@
 return ConsoleObject::create(vm, global, ConsoleObject::createStructure(vm, global, constructEmptyObject(global->globalExec(;
 }
 
-static JSValue createAtomicsProperty(VM& vm, JSObject* object)
-{
-JSGlobalObject* global = jsCast(object);
-return AtomicsObject::create(vm, global, AtomicsObject::createStructure(vm, global, global->objectPrototype()));
-}
-
 static EncodedJSValue JSC_HOST_CALL makeBoundFunction(ExecState* exec)
 {
 VM& vm = exec->vm();
@@ -308,7 +302,6 @@
   Proxy createProxyProperty  DontEnum|PropertyCallback
   JSON  createJSONProperty   DontEnum|PropertyCallback
   Math  createMathProperty   DontEnum|PropertyCallback
-  Atomics   createAtomicsPropertyDontEnum|PropertyCallback
   console   createConsolePropertyDontEnum|PropertyCallback
   Int8Array JSGlobalObject::m_typedArrayInt8 DontEnum|ClassStructure
   Int16ArrayJSGlobalObject::m_typedArrayInt16DontEnum|ClassStructure
@@ -664,11 +657,15 @@
 
 JSArrayBufferConstructor* arrayBufferConstructor = JSArrayBufferConstructor::create(vm, JSArrayBufferConstructor::createStructure(vm, this, m_functionPrototype.get()), m_arrayBufferPrototype.get(), m_speciesGetterSetter.get(), ArrayBufferSharingMode::Default);
 m_arrayBufferPrototype->putDirectWithoutTransition(vm, vm.propertyNames->constructor, arrayBufferConstructor, static_cast(PropertyAttribute::DontEnum));
+
 #if ENABLE(SHARED_ARRAY_BUFFER)
 JSArrayBufferConstructor* sharedArrayBufferConstructor = nullptr;
 sharedArrayBufferConstructor = JSArrayBufferConstructor::create(vm, JSArrayBufferConstructor::createStructure(vm, this, m_functionPrototype.get()), m_sharedArrayBufferPrototype.get(), m_speciesGetterSetter.get(), ArrayBufferSharingMode::Shared);
 m_sharedArrayBufferPrototype->putDirectWithoutTransition(vm, vm.propertyNames->constructor, sharedArrayBufferConstructor, static_cast(PropertyAttribute::DontEnum));
+
+AtomicsObject* atomicsObject = AtomicsObject::create(vm, this, AtomicsObject::createStructure(vm, this, m_objectPrototype.get()));
 #endif
+
 #define CREATE_CONSTRUCTOR_FOR_SIMPLE_TYPE(capitalName, lowerName, properName,

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

2018-01-17 Thread sbarati

Title: [227096] trunk/Source/_javascript_Core








Revision 227096
Author sbar...@apple.com
Date 2018-01-17 16:34:16 -0800 (Wed, 17 Jan 2018)


Log Message
Support MultiGetByOffset in the DFG
https://bugs.webkit.org/show_bug.cgi?id=181466

Reviewed by Keith Miller.

This seems to benefit Speedometer in my local testing. It seems like this
might be around a 0.5% improvement.

* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetById):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::supportsMultiGetByOffset):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp
trunk/Source/_javascript_Core/dfg/DFGConstantFoldingPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGGraph.h
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (227095 => 227096)

--- trunk/Source/_javascript_Core/ChangeLog	2018-01-18 00:26:31 UTC (rev 227095)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-01-18 00:34:16 UTC (rev 227096)
@@ -1,5 +1,26 @@
 2018-01-17  Saam Barati  
 
+Support MultiGetByOffset in the DFG
+https://bugs.webkit.org/show_bug.cgi?id=181466
+
+Reviewed by Keith Miller.
+
+This seems to benefit Speedometer in my local testing. It seems like this
+might be around a 0.5% improvement.
+
+* dfg/DFGAbstractInterpreterInlines.h:
+(JSC::DFG::AbstractInterpreter::executeEffects):
+* dfg/DFGByteCodeParser.cpp:
+(JSC::DFG::ByteCodeParser::handleGetById):
+* dfg/DFGConstantFoldingPhase.cpp:
+(JSC::DFG::ConstantFoldingPhase::foldConstants):
+* dfg/DFGGraph.h:
+(JSC::DFG::Graph::supportsMultiGetByOffset):
+* dfg/DFGSpeculativeJIT64.cpp:
+(JSC::DFG::SpeculativeJIT::compile):
+
+2018-01-17  Saam Barati  
+
 DFG::Node::convertToConstant needs to clear the varargs flags
 https://bugs.webkit.org/show_bug.cgi?id=181697
 


Modified: trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h (227095 => 227096)

--- trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h	2018-01-18 00:26:31 UTC (rev 227095)
+++ trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h	2018-01-18 00:34:16 UTC (rev 227096)
@@ -2881,10 +2881,6 @@
 // contradiction then there must always be a contradiction even if subsequent passes don't
 // realize it. This is the case here.
 
-// Ordinarily you have to be careful with calling setFoundConstants()
-// because of the effect on compile times, but this node is FTL-only.
-m_state.setFoundConstants(true);
-
 UniquedStringImpl* uid = m_graph.identifiers()[node->multiGetByOffsetData().identifierNumber];
 
 AbstractValue base = forNode(node->child1());
@@ -2893,8 +2889,10 @@
 for (const MultiGetByOffsetCase& getCase : node->multiGetByOffsetData().cases) {
 RegisteredStructureSet set = getCase.set();
 set.filter(base);
-if (set.isEmpty())
+if (set.isEmpty()) {
+m_state.setFoundConstants(true);
 continue;
+}
 baseSet.merge(set);
 
 switch (getCase.method().kind()) {


Modified: trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp (227095 => 227096)

--- trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp	2018-01-18 00:26:31 UTC (rev 227095)
+++ trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp	2018-01-18 00:34:16 UTC (rev 227096)
@@ -3933,8 +3933,7 @@
 }
 
 if (getByIdStatus.numVariants() > 1) {
-if (getByIdStatus.makesCalls() || !isFTL(m_graph.m_plan.mode)
-|| !Options::usePolymorphicAccessInlining()) {
+if (getByIdStatus.makesCalls() || !m_graph.supportsMultiGetByOffset(currentCodeOrigin()) || !Options::usePolymorphicAccessInlining()) {
 set(VirtualRegister(destinationOperand),
 addToGraph(getById, OpInfo(identifierNumber), OpInfo(prediction), base));
 return;


Modified: trunk/Source/_javascript_Core/dfg/DFGConstantFoldingPhase.cpp (227095 => 227096)

--- trunk/Source/_javascript_Core/dfg/DFGConstantFoldingPhase.cpp	2018-01-18 00:26:31 UTC (rev 227095)
+++ trunk/Source/_javascript_Core/dfg/DFGConstantFoldingPhase.cpp	2018-01-18 00:34:16 UTC (rev 227096)
@@ -522,7 +522,7 @@
 break;
 }
 
-if (!isFTL(m_graph.m_plan.mode))
+if (!m_graph.supportsMultiGetByOffset(node->origin.semantic))
 break;

[webkit-changes] [227053] trunk

2018-01-17 Thread sbarati

Title: [227053] trunk








Revision 227053
Author sbar...@apple.com
Date 2018-01-17 01:24:26 -0800 (Wed, 17 Jan 2018)


Log Message
DFG::Node::convertToConstant needs to clear the varargs flags
https://bugs.webkit.org/show_bug.cgi?id=181697


Reviewed by Yusuke Suzuki.

JSTests:

* stress/dfg-node-convert-to-constant-must-clear-varargs-flags.js: Added.
(doIndexOf):
(bar):
(i.bar):

Source/_javascript_Core:

* dfg/DFGNode.h:
(JSC::DFG::Node::convertToConstant):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGNode.h


Added Paths

trunk/JSTests/stress/dfg-node-convert-to-constant-must-clear-varargs-flags.js




Diff

Modified: trunk/JSTests/ChangeLog (227052 => 227053)

--- trunk/JSTests/ChangeLog	2018-01-17 09:22:35 UTC (rev 227052)
+++ trunk/JSTests/ChangeLog	2018-01-17 09:24:26 UTC (rev 227053)
@@ -1,3 +1,16 @@
+2018-01-17  Saam Barati  
+
+DFG::Node::convertToConstant needs to clear the varargs flags
+https://bugs.webkit.org/show_bug.cgi?id=181697
+
+
+Reviewed by Yusuke Suzuki.
+
+* stress/dfg-node-convert-to-constant-must-clear-varargs-flags.js: Added.
+(doIndexOf):
+(bar):
+(i.bar):
+
 2018-01-16  Ryan Haddad  
 
 Unreviewed, rolling out r226937.


Added: trunk/JSTests/stress/dfg-node-convert-to-constant-must-clear-varargs-flags.js (0 => 227053)

--- trunk/JSTests/stress/dfg-node-convert-to-constant-must-clear-varargs-flags.js	(rev 0)
+++ trunk/JSTests/stress/dfg-node-convert-to-constant-must-clear-varargs-flags.js	2018-01-17 09:24:26 UTC (rev 227053)
@@ -0,0 +1,14 @@
+function doIndexOf(a) {
+a.indexOf(a);
+}
+
+function bar(f) {
+f();
+}
+
+let array = [20];
+for (let i = 0; i < 10; ++i) {
+bar(() => {
+return doIndexOf(array.concat());
+});
+}


Modified: trunk/Source/_javascript_Core/ChangeLog (227052 => 227053)

--- trunk/Source/_javascript_Core/ChangeLog	2018-01-17 09:22:35 UTC (rev 227052)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-01-17 09:24:26 UTC (rev 227053)
@@ -1,3 +1,14 @@
+2018-01-17  Saam Barati  
+
+DFG::Node::convertToConstant needs to clear the varargs flags
+https://bugs.webkit.org/show_bug.cgi?id=181697
+
+
+Reviewed by Yusuke Suzuki.
+
+* dfg/DFGNode.h:
+(JSC::DFG::Node::convertToConstant):
+
 2018-01-16  JF Bastien  
 
 Allow dangerous disabling of poison


Modified: trunk/Source/_javascript_Core/dfg/DFGNode.h (227052 => 227053)

--- trunk/Source/_javascript_Core/dfg/DFGNode.h	2018-01-17 09:22:35 UTC (rev 227052)
+++ trunk/Source/_javascript_Core/dfg/DFGNode.h	2018-01-17 09:24:26 UTC (rev 227053)
@@ -518,7 +518,7 @@
 m_op = Int52Constant;
 else
 m_op = JSConstant;
-m_flags &= ~NodeMustGenerate;
+m_flags &= ~(NodeMustGenerate | NodeHasVarArgs);
 m_opInfo = value;
 children.reset();
 }






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2018-01-14 Thread sbarati

Title: [226942] trunk/Source/_javascript_Core








Revision 226942
Author sbar...@apple.com
Date 2018-01-14 11:43:39 -0800 (Sun, 14 Jan 2018)


Log Message
Unreviewed. r226928 broke the CLOOP build. This patch fixes the CLOOP build.

* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
(JSC::CallLinkStatus::computeExitSiteData):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/CallLinkStatus.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (226941 => 226942)

--- trunk/Source/_javascript_Core/ChangeLog	2018-01-14 07:16:21 UTC (rev 226941)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-01-14 19:43:39 UTC (rev 226942)
@@ -1,3 +1,11 @@
+2018-01-14  Saam Barati  
+
+Unreviewed. r226928 broke the CLOOP build. This patch fixes the CLOOP build.
+
+* bytecode/CallLinkStatus.cpp:
+(JSC::CallLinkStatus::computeFromLLInt):
+(JSC::CallLinkStatus::computeExitSiteData):
+
 2018-01-13  Mark Lam  
 
 Replace all use of ConstExprPoisoned with Poisoned.


Modified: trunk/Source/_javascript_Core/bytecode/CallLinkStatus.cpp (226941 => 226942)

--- trunk/Source/_javascript_Core/bytecode/CallLinkStatus.cpp	2018-01-14 07:16:21 UTC (rev 226941)
+++ trunk/Source/_javascript_Core/bytecode/CallLinkStatus.cpp	2018-01-14 19:43:39 UTC (rev 226942)
@@ -64,8 +64,6 @@
 // takes slow path.
 return takesSlowPath();
 }
-#else
-UNUSED_PARAM(locker);
 #endif
 
 Instruction* instruction = profiledBlock->instructions().begin() + bytecodeIndex;
@@ -115,7 +113,6 @@
 exitSiteData.badFunction =
 codeBlock->hasExitSite(locker, DFG::FrequentExitSite(bytecodeIndex, BadCell));
 #else
-UNUSED_PARAM(locker);
 UNUSED_PARAM(profiledBlock);
 UNUSED_PARAM(bytecodeIndex);
 #endif






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2018-01-12 Thread sbarati

Title: [226928] trunk/Source/_javascript_Core








Revision 226928
Author sbar...@apple.com
Date 2018-01-12 16:36:37 -0800 (Fri, 12 Jan 2018)


Log Message
Move ExitProfile to UnlinkedCodeBlock so it can be shared amongst CodeBlocks backed by the same UnlinkedCodeBlock
https://bugs.webkit.org/show_bug.cgi?id=181545

Reviewed by Michael Saboff.

This patch follows the theme of putting optimization profiling information on
UnlinkedCodeBlock. This allows the unlinked code cache to remember OSR exit data.
This often leads to the first compile of a CodeBlock, backed by an UnlinkedCodeBlock
pulled from the code cache, making better compilation decisions, usually
resulting in fewer exits, and fewer recompilations.

This is a 1% Speedometer progression in my testing.

* bytecode/BytecodeDumper.cpp:
(JSC::BytecodeDumper::dumpProfilesForBytecodeOffset):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
(JSC::CallLinkStatus::computeFor):
(JSC::CallLinkStatus::computeExitSiteData):
(JSC::CallLinkStatus::computeDFGStatuses):
* bytecode/CallLinkStatus.h:
* bytecode/CodeBlock.h:
(JSC::CodeBlock::addFrequentExitSite): Deleted.
(JSC::CodeBlock::hasExitSite const): Deleted.
(JSC::CodeBlock::exitProfile): Deleted.
* bytecode/DFGExitProfile.cpp:
(JSC::DFG::ExitProfile::add):
(JSC::DFG::QueryableExitProfile::initialize):
* bytecode/DFGExitProfile.h:
(JSC::DFG::ExitProfile::hasExitSite const):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::hasExitSite):
(JSC::GetByIdStatus::computeFor):
(JSC::GetByIdStatus::computeForStubInfo):
* bytecode/GetByIdStatus.h:
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::hasExitSite):
(JSC::PutByIdStatus::computeFor):
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/PutByIdStatus.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::livenessAnalysisSlow):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::hasExitSite const):
(JSC::UnlinkedCodeBlock::hasExitSite):
(JSC::UnlinkedCodeBlock::exitProfile):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::hasGlobalExitSite):
(JSC::DFG::Graph::hasExitSite):
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::attemptHoist):
* dfg/DFGOSRExitBase.cpp:
(JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/BytecodeDumper.cpp
trunk/Source/_javascript_Core/bytecode/CallLinkStatus.cpp
trunk/Source/_javascript_Core/bytecode/CallLinkStatus.h
trunk/Source/_javascript_Core/bytecode/CodeBlock.h
trunk/Source/_javascript_Core/bytecode/DFGExitProfile.cpp
trunk/Source/_javascript_Core/bytecode/DFGExitProfile.h
trunk/Source/_javascript_Core/bytecode/GetByIdStatus.cpp
trunk/Source/_javascript_Core/bytecode/GetByIdStatus.h
trunk/Source/_javascript_Core/bytecode/PutByIdStatus.cpp
trunk/Source/_javascript_Core/bytecode/PutByIdStatus.h
trunk/Source/_javascript_Core/bytecode/UnlinkedCodeBlock.cpp
trunk/Source/_javascript_Core/bytecode/UnlinkedCodeBlock.h
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp
trunk/Source/_javascript_Core/dfg/DFGGraph.h
trunk/Source/_javascript_Core/dfg/DFGLICMPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGOSRExitBase.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (226927 => 226928)

--- trunk/Source/_javascript_Core/ChangeLog	2018-01-13 00:30:02 UTC (rev 226927)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-01-13 00:36:37 UTC (rev 226928)
@@ -1,3 +1,61 @@
+2018-01-12  Saam Barati  
+
+Move ExitProfile to UnlinkedCodeBlock so it can be shared amongst CodeBlocks backed by the same UnlinkedCodeBlock
+https://bugs.webkit.org/show_bug.cgi?id=181545
+
+Reviewed by Michael Saboff.
+
+This patch follows the theme of putting optimization profiling information on
+UnlinkedCodeBlock. This allows the unlinked code cache to remember OSR exit data.
+This often leads to the first compile of a CodeBlock, backed by an UnlinkedCodeBlock
+pulled from the code cache, making better compilation decisions, usually
+resulting in fewer exits, and fewer recompilations.
+
+This is a 1% Speedometer progression in my testing.
+
+* bytecode/BytecodeDumper.cpp:
+(JSC::BytecodeDumper::dumpProfilesForBytecodeOffset):
+* bytecode/CallLinkStatus.cpp:
+(JSC::CallLinkStatus::computeFromLLInt):
+(JSC::CallLinkStatus::computeFor):
+(JSC::CallLinkStatus::computeExitSiteData):
+(JSC::CallLinkStatus::computeDFGStatuses):
+* bytecode/CallLinkStatus.h:
+* bytecode/CodeBlock.h:
+(JSC::CodeBlock::addFrequentExitSite): Deleted.
+(JSC::CodeBlock::hasExitSite const): Deleted.
+(JSC::CodeBlock::exitProfile): Deleted.
+* bytecode/DFGExitProfile.cpp:
+(JSC::DFG::ExitProfile::add):
+(JSC::DFG::QueryableExitProfile::initialize):
+

[webkit-changes] [226907] trunk

2018-01-12 Thread sbarati

Title: [226907] trunk








Revision 226907
Author sbar...@apple.com
Date 2018-01-12 12:47:44 -0800 (Fri, 12 Jan 2018)


Log Message
CheckStructure can be incorrectly subsumed by CheckStructureOrEmpty
https://bugs.webkit.org/show_bug.cgi?id=181177


Reviewed by Yusuke Suzuki.

JSTests:

* stress/check-structure-ir-ensures-empty-does-not-flow-through.js: Added.
(runNearStackLimit.t):
(runNearStackLimit):
(test.f):
(test):

Source/_javascript_Core:

The semantics of CheckStructure are such that it does not allow the empty value to flow through it.
However, we may eliminate a CheckStructure if it's preceded by a CheckStructureOrEmpty. This doesn't
have semantic consequences when validation is turned off. However, with validation on, this trips up
our OSR exit machinery that says when an exit is allowed to happen.

Consider the following IR:

a: GetClosureVar // Or any other node that produces BytecodeTop
...
c: CheckStructure(Cell:@a, {s2})
d: PutByOffset(KnownCell:@a, KnownCell:@a, @value)

In the TypeCheckHoistingPhase, we may insert CheckStructureOrEmptys like this:
a: GetClosureVar
e: CheckStructureOrEmpty(@a, {s1})
...
f: CheckStructureOrEmpty(@a, {s2})
c: CheckStructure(Cell:@a, {s2})
d: PutByOffset(KnownCell:@a, KnownCell:@a, @value)

This will cause constant folding to change the IR to:
a: GetClosureVar
e: CheckStructureOrEmpty(@a, {s1})
...
f: CheckStructureOrEmpty(@a, {s2})
d: PutByOffset(KnownCell:@a, KnownCell:@a, @value)

Our mayExit analysis determines that the PutByOffset should not exit. Note
that AI will determine the only value the PutByOffset can see in @a is
the empty value. Because KnownCell filters SpecCell and not SpecCellCheck,
when lowering the PutByOffset, we reach a contradiction in AI and emit
an OSR exit. However, because mayExit said we couldn't exit, we assert.

Note that if we did not run the TypeCheckHoistingPhase on this IR, AI
would have determined we would OSR exit at the second CheckStructure.

This patch makes it so constant folding produces the following IR:
a: GetClosureVar
e: CheckStructureOrEmpty(@a, {s1})
g: AssertNotEmpty(@a)
...
f: CheckStructureOrEmpty(@a, {s2})
h: AssertNotEmpty(@a)
d: PutByOffset(KnownCell:@a, KnownCell:@a, @value)

This modification will cause AI to know we will OSR exit before even reaching
the PutByOffset. Note that in the original IR, the GetClosureVar won't
actually produce the TDZ value. If it did, bytecode would have caused us
to emit a CheckNotEmpty before the CheckStructure/PutByOffset combo. That's
why this bug is about IR bookkeeping and not an actual error in IR analysis.
This patch introduces AssertNotEmpty instead of using CheckNotEmpty to be
more congruous with CheckStructure's semantics of crashing on the empty value
as input (on 64 bit platforms).

* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter::executeEffects):
* 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/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* 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::compileAssertNotEmpty):

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/DFGConstantFoldingPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGDoesGC.cpp
trunk/Source/_javascript_Core/dfg/DFGFixupPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGNodeType.h
trunk/Source/_javascript_Core/dfg/DFGPredictionPropagationPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGSafeToExecute.h
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT32_64.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp
trunk/Source/_javascript_Core/ftl/FTLCapabilities.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp


Added Paths

trunk/JSTests/stress/check-structure-ir-ensures-empty-does-not-flow-through.js




Diff

Modified: trunk/JSTests/ChangeLog (226906 => 226907)

--- trunk/JSTests/ChangeLog	2018-01-12 20:41:55 UTC (rev 226906)
+++ trunk/JSTests/ChangeLog	2018-01-12 20:47:44 UTC (rev 226907)
@@ -1,5 +1,19 @@
 2018-01-12  Saam Barati  
 
+CheckStructure can be incorrectly subsumed by CheckStructureOrEmpty
+https://bugs.webkit.org/show_bug.cgi?id=181177
+
+
+Reviewed by Yusuke Suzuki.
+
+* stress/check-structure-ir-ensures-empty-does-not-flow-through.js: Added.
+(runNearStackLimit.t):
+(runNearStackLimit):
+(test.f):
+

[webkit-changes] [226811] trunk

2018-01-11 Thread sbarati

Title: [226811] trunk








Revision 226811
Author sbar...@apple.com
Date 2018-01-11 15:21:18 -0800 (Thu, 11 Jan 2018)


Log Message
When inserting Unreachable in byte code parser we need to flush all the right things
https://bugs.webkit.org/show_bug.cgi?id=181509


Reviewed by Mark Lam.

JSTests:

* stress/proper-flushing-when-we-insert-unreachable-after-force-exit-in-bytecode-parser.js: Added.

Source/_javascript_Core:

I added code in r226655 that had its own mechanism for preserving liveness when
inserting Unreachable nodes after ForceOSRExit. There are two ways to preserve
liveness: PhantomLocal and Flush. Certain values *must* be flushed to the stack.
I got some of these values wrong, which was leading to a crash when recovering the
callee value from an inlined frame. Instead of making the same mistake and repeating
similar code again, this patch refactors this logic to be shared with the other
liveness preservation code in the DFG bytecode parser. This is what I should have
done in my initial patch.

* bytecode/InlineCallFrame.h:
(JSC::remapOperand):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::flushImpl):
(JSC::DFG::flushForTerminalImpl):
(JSC::DFG::ByteCodeParser::flush):
(JSC::DFG::ByteCodeParser::flushForTerminal):
(JSC::DFG::ByteCodeParser::parse):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/InlineCallFrame.h
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp


Added Paths

trunk/JSTests/stress/proper-flushing-when-we-insert-unreachable-after-force-exit-in-bytecode-parser.js




Diff

Modified: trunk/JSTests/ChangeLog (226810 => 226811)

--- trunk/JSTests/ChangeLog	2018-01-11 22:45:37 UTC (rev 226810)
+++ trunk/JSTests/ChangeLog	2018-01-11 23:21:18 UTC (rev 226811)
@@ -1,5 +1,15 @@
 2018-01-11  Saam Barati  
 
+When inserting Unreachable in byte code parser we need to flush all the right things
+https://bugs.webkit.org/show_bug.cgi?id=181509
+
+
+Reviewed by Mark Lam.
+
+* stress/proper-flushing-when-we-insert-unreachable-after-force-exit-in-bytecode-parser.js: Added.
+
+2018-01-11  Saam Barati  
+
 JITMathIC code in the FTL is wrong when code gets duplicated
 https://bugs.webkit.org/show_bug.cgi?id=181525
 


Added: trunk/JSTests/stress/proper-flushing-when-we-insert-unreachable-after-force-exit-in-bytecode-parser.js (0 => 226811)

--- trunk/JSTests/stress/proper-flushing-when-we-insert-unreachable-after-force-exit-in-bytecode-parser.js	(rev 0)
+++ trunk/JSTests/stress/proper-flushing-when-we-insert-unreachable-after-force-exit-in-bytecode-parser.js	2018-01-11 23:21:18 UTC (rev 226811)
@@ -0,0 +1,27 @@
+function test(b, f) {
+if (b)
+return f(b);
+}
+noInline(test);
+
+function throwError(b) {
+if (b) {
+try {
+throw new Error;
+} catch(e) { }
+}
+return 2;
+}
+noInline(throwError);
+
+function makeFoo() {
+return function foo(b) {
+throwError(b);
+OSRExit();
+}
+}
+
+let foos = [makeFoo(), makeFoo()];
+for (let i = 0; i < 1; ++i) {
+test(!!(i%2), foos[((Math.random() * 100) | 0) % foos.length]);
+}


Modified: trunk/Source/_javascript_Core/ChangeLog (226810 => 226811)

--- trunk/Source/_javascript_Core/ChangeLog	2018-01-11 22:45:37 UTC (rev 226810)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-01-11 23:21:18 UTC (rev 226811)
@@ -1,5 +1,31 @@
 2018-01-11  Saam Barati  
 
+When inserting Unreachable in byte code parser we need to flush all the right things
+https://bugs.webkit.org/show_bug.cgi?id=181509
+
+
+Reviewed by Mark Lam.
+
+I added code in r226655 that had its own mechanism for preserving liveness when
+inserting Unreachable nodes after ForceOSRExit. There are two ways to preserve
+liveness: PhantomLocal and Flush. Certain values *must* be flushed to the stack.
+I got some of these values wrong, which was leading to a crash when recovering the
+callee value from an inlined frame. Instead of making the same mistake and repeating
+similar code again, this patch refactors this logic to be shared with the other
+liveness preservation code in the DFG bytecode parser. This is what I should have
+done in my initial patch.
+
+* bytecode/InlineCallFrame.h:
+(JSC::remapOperand):
+* dfg/DFGByteCodeParser.cpp:
+(JSC::DFG::flushImpl):
+(JSC::DFG::flushForTerminalImpl):
+(JSC::DFG::ByteCodeParser::flush):
+(JSC::DFG::ByteCodeParser::flushForTerminal):
+(JSC::DFG::ByteCodeParser::parse):
+
+2018-01-11  Saam Barati  
+
 JITMathIC code in the FTL is wrong when code gets duplicated
 https://bugs.webkit.org/show_bug.cgi?id=181525
 


Modified: trunk/Source/_javascript_Core/bytecode/InlineCallFrame.h

[webkit-changes] [226806] trunk

2018-01-11 Thread sbarati

Title: [226806] trunk








Revision 226806
Author sbar...@apple.com
Date 2018-01-11 14:18:17 -0800 (Thu, 11 Jan 2018)


Log Message
JITMathIC code in the FTL is wrong when code gets duplicated
https://bugs.webkit.org/show_bug.cgi?id=181525


Reviewed by Michael Saboff and Keith Miller.

JSTests:

* stress/allow-math-ic-b3-code-duplication.js: Added.

Source/_javascript_Core:

B3/Air may duplicate code for various reasons. Patchpoint generators inside
FTLLower must be aware that they can be called multiple times because of this.
The patchpoint for math ICs was not aware of this, and shared state amongst
all invocations of the patchpoint's generator. This patch fixes this bug so
that each invocation of the patchpoint's generator gets a unique math IC.

* bytecode/CodeBlock.h:
(JSC::CodeBlock::addMathIC):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
(JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
(JSC::FTL::DFG::LowerDFGToB3::compileMathIC): Deleted.
* jit/JITMathIC.h:
(JSC::isProfileEmpty):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/CodeBlock.h
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
trunk/Source/_javascript_Core/jit/JITMathIC.h


Added Paths

trunk/JSTests/stress/allow-math-ic-b3-code-duplication.js




Diff

Modified: trunk/JSTests/ChangeLog (226805 => 226806)

--- trunk/JSTests/ChangeLog	2018-01-11 22:14:38 UTC (rev 226805)
+++ trunk/JSTests/ChangeLog	2018-01-11 22:18:17 UTC (rev 226806)
@@ -1,5 +1,15 @@
 2018-01-11  Saam Barati  
 
+JITMathIC code in the FTL is wrong when code gets duplicated
+https://bugs.webkit.org/show_bug.cgi?id=181525
+
+
+Reviewed by Michael Saboff and Keith Miller.
+
+* stress/allow-math-ic-b3-code-duplication.js: Added.
+
+2018-01-11  Saam Barati  
+
 Our for-in caching is wrong when we add indexed properties on things in the prototype chain
 https://bugs.webkit.org/show_bug.cgi?id=181508
 


Added: trunk/JSTests/stress/allow-math-ic-b3-code-duplication.js (0 => 226806)

--- trunk/JSTests/stress/allow-math-ic-b3-code-duplication.js	(rev 0)
+++ trunk/JSTests/stress/allow-math-ic-b3-code-duplication.js	2018-01-11 22:18:17 UTC (rev 226806)
@@ -0,0 +1,35 @@
+function test1() {
+var o1;
+for (let i = 0; i < 100; ++i) {
+var o2 = { f: { f: { f: { f: { f: { f: { f: { f: { f: { f: { f: { f: { } } } } } } } } } } } } };
+}
+return -o2;
+}
+test1();
+
+function test2() {
+var o1;
+for (let i = 0; i < 100; ++i) {
+var o2 = { f: { f: { f: { f: { f: { f: { f: { f: { f: { f: { f: { f: { } } } } } } } } } } } } };
+}
+return o1 - o2;
+}
+test2();
+
+function test3() {
+var o1;
+for (let i = 0; i < 100; ++i) {
+var o2 = { f: { f: { f: { f: { f: { f: { f: { f: { f: { f: { f: { f: { } } } } } } } } } } } } };
+}
+return o1 + o2;
+}
+test3();
+
+function test4() {
+var o1;
+for (let i = 0; i < 100; ++i) {
+var o2 = { f: { f: { f: { f: { f: { f: { f: { f: { f: { f: { f: { f: { } } } } } } } } } } } } };
+}
+return o1 * o2;
+}
+test4();


Modified: trunk/Source/_javascript_Core/ChangeLog (226805 => 226806)

--- trunk/Source/_javascript_Core/ChangeLog	2018-01-11 22:14:38 UTC (rev 226805)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-01-11 22:18:17 UTC (rev 226806)
@@ -1,3 +1,30 @@
+2018-01-11  Saam Barati  
+
+JITMathIC code in the FTL is wrong when code gets duplicated
+https://bugs.webkit.org/show_bug.cgi?id=181525
+
+
+Reviewed by Michael Saboff and Keith Miller.
+
+B3/Air may duplicate code for various reasons. Patchpoint generators inside
+FTLLower must be aware that they can be called multiple times because of this.
+The patchpoint for math ICs was not aware of this, and shared state amongst
+all invocations of the patchpoint's generator. This patch fixes this bug so
+that each invocation of the patchpoint's generator gets a unique math IC.
+
+* bytecode/CodeBlock.h:
+(JSC::CodeBlock::addMathIC):
+* ftl/FTLLowerDFGToB3.cpp:
+(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
+(JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
+(JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
+(JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
+(JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
+(JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
+(JSC::FTL::DFG::LowerDFGToB3::compileMathIC): Deleted.
+* jit/JITMathIC.h:
+(JSC::isProfileEmpty):
+
 2018-01-11  Michael Saboff

[webkit-changes] [226767] trunk

2018-01-11 Thread sbarati

Title: [226767] trunk








Revision 226767
Author sbar...@apple.com
Date 2018-01-11 00:16:06 -0800 (Thu, 11 Jan 2018)


Log Message
Our for-in caching is wrong when we add indexed properties on things in the prototype chain
https://bugs.webkit.org/show_bug.cgi?id=181508

Reviewed by Yusuke Suzuki.

JSTests:

* stress/for-in-prototype-with-indexed-properties-should-prevent-caching.js: Added.
(assert):
(test1.foo):
(test1):
(test2.foo):
(test2):

Source/_javascript_Core:

Our for-in caching would cache structure chains that had prototypes with
indexed properties. Clearly this is wrong. This caching breaks when a prototype
adds new indexed properties. We would continue to enumerate the old cached
state of properties, and not include the new indexed properties.

The old code used to prevent caching only if the base structure had
indexed properties. This patch extends it to prevent caching if the
base, or any structure in the prototype chain, has indexed properties.

* runtime/Structure.cpp:
(JSC::Structure::canCachePropertyNameEnumerator const):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/Structure.cpp


Added Paths

trunk/JSTests/stress/for-in-prototype-with-indexed-properties-should-prevent-caching.js




Diff

Modified: trunk/JSTests/ChangeLog (226766 => 226767)

--- trunk/JSTests/ChangeLog	2018-01-11 07:26:55 UTC (rev 226766)
+++ trunk/JSTests/ChangeLog	2018-01-11 08:16:06 UTC (rev 226767)
@@ -1,3 +1,17 @@
+2018-01-11  Saam Barati  
+
+Our for-in caching is wrong when we add indexed properties on things in the prototype chain
+https://bugs.webkit.org/show_bug.cgi?id=181508
+
+Reviewed by Yusuke Suzuki.
+
+* stress/for-in-prototype-with-indexed-properties-should-prevent-caching.js: Added.
+(assert):
+(test1.foo):
+(test1):
+(test2.foo):
+(test2):
+
 2018-01-09  Mark Lam  
 
 ASSERTION FAILED: pair.second->m_type & PropertyNode::Getter


Added: trunk/JSTests/stress/for-in-prototype-with-indexed-properties-should-prevent-caching.js (0 => 226767)

--- trunk/JSTests/stress/for-in-prototype-with-indexed-properties-should-prevent-caching.js	(rev 0)
+++ trunk/JSTests/stress/for-in-prototype-with-indexed-properties-should-prevent-caching.js	2018-01-11 08:16:06 UTC (rev 226767)
@@ -0,0 +1,77 @@
+"use strict";
+
+function assert(b) {
+if (!b)
+throw new Error;
+}
+
+
+function test1() {
+function foo(o) {
+let result = [];
+for (let p in o)
+result.push(p);
+return result;
+}
+noInline(foo);
+
+let p = {};
+let x = {__proto__: p};
+p[0] = 25;
+for (let i = 0; i < 20; ++i) {
+let result = foo(x);
+assert(result.length === 1);
+assert(result[0] === "0");
+}
+
+p[1] = 30;
+for (let i = 0; i < 20; ++i) {
+let result = foo(x);
+assert(result.length === 2);
+assert(result[0] === "0");
+assert(result[1] === "1");
+}
+
+p[2] = {};
+for (let i = 0; i < 20; ++i) {
+let result = foo(x);
+assert(result.length === 3);
+assert(result[0] === "0");
+assert(result[1] === "1");
+assert(result[2] === "2");
+}
+}
+test1();
+
+function test2() {
+function foo(o) {
+let result = [];
+for (let p in o)
+result.push(p);
+return result;
+}
+noInline(foo);
+
+let p = {};
+let x = {__proto__: p};
+for (let i = 0; i < 20; ++i) {
+let result = foo(x);
+assert(result.length === 0);
+}
+
+p[0] = 30;
+for (let i = 0; i < 20; ++i) {
+let result = foo(x);
+assert(result.length === 1);
+assert(result[0] === "0");
+}
+
+p[1] = {};
+for (let i = 0; i < 20; ++i) {
+let result = foo(x);
+assert(result.length === 2);
+assert(result[0] === "0");
+assert(result[1] === "1");
+}
+}
+test2();


Modified: trunk/Source/_javascript_Core/ChangeLog (226766 => 226767)

--- trunk/Source/_javascript_Core/ChangeLog	2018-01-11 07:26:55 UTC (rev 226766)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-01-11 08:16:06 UTC (rev 226767)
@@ -1,3 +1,22 @@
+2018-01-11  Saam Barati  
+
+Our for-in caching is wrong when we add indexed properties on things in the prototype chain
+https://bugs.webkit.org/show_bug.cgi?id=181508
+
+Reviewed by Yusuke Suzuki.
+
+Our for-in caching would cache structure chains that had prototypes with
+indexed properties. Clearly this is wrong. This caching breaks when a prototype
+adds new indexed properties. We would continue to enumerate the old cached
+state of properties, and not include the new indexed properties.
+
+The old code used to prevent caching only if the base structure had
+

[webkit-changes] [226661] trunk/Tools

2018-01-09 Thread sbarati

Title: [226661] trunk/Tools








Revision 226661
Author sbar...@apple.com
Date 2018-01-09 15:43:41 -0800 (Tue, 09 Jan 2018)


Log Message
Give some slack in display-profiler-outputs computation of the terminal window's number of columns
https://bugs.webkit.org/show_bug.cgi?id=181449

Reviewed by JF Bastien.

This allows me to Cmd+f in my terminal to search for things without
having the results become misaligned.

* Scripts/display-profiler-output:

Modified Paths

trunk/Tools/ChangeLog
trunk/Tools/Scripts/display-profiler-output




Diff

Modified: trunk/Tools/ChangeLog (226660 => 226661)

--- trunk/Tools/ChangeLog	2018-01-09 23:31:57 UTC (rev 226660)
+++ trunk/Tools/ChangeLog	2018-01-09 23:43:41 UTC (rev 226661)
@@ -1,3 +1,15 @@
+2018-01-09  Saam Barati  
+
+Give some slack in display-profiler-outputs computation of the terminal window's number of columns
+https://bugs.webkit.org/show_bug.cgi?id=181449
+
+Reviewed by JF Bastien.
+
+This allows me to Cmd+f in my terminal to search for things without
+having the results become misaligned.
+
+* Scripts/display-profiler-output:
+
 2018-01-09  Basuke Suzuki  
 
 [webkitpy] PlatformInfo should have default argument for casual use


Modified: trunk/Tools/Scripts/display-profiler-output (226660 => 226661)

--- trunk/Tools/Scripts/display-profiler-output	2018-01-09 23:31:57 UTC (rev 226660)
+++ trunk/Tools/Scripts/display-profiler-output	2018-01-09 23:43:41 UTC (rev 226661)
@@ -539,7 +539,7 @@
 
 def screenWidth
 if $stdin.tty?
-HighLine::SystemExtensions.terminal_size[0]
+HighLine::SystemExtensions.terminal_size[0] - 3
 else
 200
 end






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2018-01-09 Thread sbarati

Title: [226655] trunk/Source/_javascript_Core








Revision 226655
Author sbar...@apple.com
Date 2018-01-09 13:13:35 -0800 (Tue, 09 Jan 2018)


Log Message
Reduce graph size by replacing terminal nodes in blocks that have a ForceOSRExit with Unreachable
https://bugs.webkit.org/show_bug.cgi?id=181409

Reviewed by Keith Miller.

When I was looking at profiler data for Speedometer, I noticed that one of
the hottest functions in Speedometer is around 1100 bytecode operations long.
Only about 100 of those bytecode ops ever execute. However, we ended up
spending a lot of time compiling basic blocks that never executed. We often
plant ForceOSRExit nodes when we parse bytecodes that have a null value profile.
This is the case when such a node never executes.

This patch makes it so that anytime a block has a ForceOSRExit, we replace its
terminal node with an Unreachable node (and remove all nodes after the
ForceOSRExit). This will cut down on graph size when such a block dominates
other blocks in the CFG. This allows us to get rid of huge chunks of the CFG
in certain programs. When doing this transformation, we also insert
Flushes/PhantomLocals to ensure we can recover values that are bytecode
live-in to the ForceOSRExit.

Using ForceOSRExit as the signal for this is a bit of a hack. It definitely
does not get rid of all the CFG that it could. If we decide it's worth
it, we could use additional inputs into this mechanism. For example, we could
profile if a basic block ever executes inside the LLInt/Baseline, and
remove parts of the CFG based on that.

When running Speedometer with the concurrent JIT turned off, this patch
improves DFG/FTL compile times by around 5%.

* 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 (226654 => 226655)

--- trunk/Source/_javascript_Core/ChangeLog	2018-01-09 20:15:19 UTC (rev 226654)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-01-09 21:13:35 UTC (rev 226655)
@@ -1,3 +1,38 @@
+2018-01-09  Saam Barati  
+
+Reduce graph size by replacing terminal nodes in blocks that have a ForceOSRExit with Unreachable
+https://bugs.webkit.org/show_bug.cgi?id=181409
+
+Reviewed by Keith Miller.
+
+When I was looking at profiler data for Speedometer, I noticed that one of
+the hottest functions in Speedometer is around 1100 bytecode operations long.
+Only about 100 of those bytecode ops ever execute. However, we ended up
+spending a lot of time compiling basic blocks that never executed. We often
+plant ForceOSRExit nodes when we parse bytecodes that have a null value profile.
+This is the case when such a node never executes.
+
+This patch makes it so that anytime a block has a ForceOSRExit, we replace its
+terminal node with an Unreachable node (and remove all nodes after the
+ForceOSRExit). This will cut down on graph size when such a block dominates
+other blocks in the CFG. This allows us to get rid of huge chunks of the CFG
+in certain programs. When doing this transformation, we also insert
+Flushes/PhantomLocals to ensure we can recover values that are bytecode
+live-in to the ForceOSRExit.
+
+Using ForceOSRExit as the signal for this is a bit of a hack. It definitely
+does not get rid of all the CFG that it could. If we decide it's worth
+it, we could use additional inputs into this mechanism. For example, we could
+profile if a basic block ever executes inside the LLInt/Baseline, and
+remove parts of the CFG based on that.
+
+When running Speedometer with the concurrent JIT turned off, this patch
+improves DFG/FTL compile times by around 5%.
+
+* dfg/DFGByteCodeParser.cpp:
+(JSC::DFG::ByteCodeParser::addToGraph):
+(JSC::DFG::ByteCodeParser::parse):
+
 2018-01-09  Mark Lam  
 
 ASSERTION FAILED: pair.second->m_type & PropertyNode::Getter


Modified: trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp (226654 => 226655)

--- trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp	2018-01-09 20:15:19 UTC (rev 226654)
+++ trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp	2018-01-09 21:13:35 UTC (rev 226655)
@@ -694,7 +694,10 @@
 
 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;
@@ -1141,6 +1144,7 @@
 
 Instruction* m_currentInstruction;
 bool m_hasDebuggerEnabled;
+bool m_hasAnyForceOSRExits { false };

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

2018-01-08 Thread sbarati

Title: [226603] trunk/Source/WebCore








Revision 226603
Author sbar...@apple.com
Date 2018-01-08 17:55:40 -0800 (Mon, 08 Jan 2018)


Log Message
Speculative build fix after r226600. We only use clflush on x86 and the `asm volatile` syntax is not available in the Windows build.

No new tests because this is a build fix.

* dom/Comment.cpp:
(WebCore::Comment::clflushReadLength):

Modified Paths

trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/dom/Comment.cpp




Diff

Modified: trunk/Source/WebCore/ChangeLog (226602 => 226603)

--- trunk/Source/WebCore/ChangeLog	2018-01-09 01:53:29 UTC (rev 226602)
+++ trunk/Source/WebCore/ChangeLog	2018-01-09 01:55:40 UTC (rev 226603)
@@ -1,3 +1,12 @@
+2018-01-08  Saam Barati  
+
+Speculative build fix after r226600. We only use clflush on x86 and the `asm volatile` syntax is not available in the Windows build.
+
+No new tests because this is a build fix.
+
+* dom/Comment.cpp:
+(WebCore::Comment::clflushReadLength):
+
 2018-01-08  Michael Saboff  
 
 Add a DOM gadget for Spectre testing


Modified: trunk/Source/WebCore/dom/Comment.cpp (226602 => 226603)

--- trunk/Source/WebCore/dom/Comment.cpp	2018-01-09 01:53:29 UTC (rev 226602)
+++ trunk/Source/WebCore/dom/Comment.cpp	2018-01-09 01:55:40 UTC (rev 226603)
@@ -86,6 +86,7 @@
 
 void Comment::clflushReadLength()
 {
+#if CPU(X86_64) && !OS(WINDOWS)
 auto clflush = [] (void* ptr) {
 char* ptrToFlush = static_cast(ptr);
 asm volatile ("clflush %0" :: "m"(*ptrToFlush) : "memory");
@@ -92,6 +93,7 @@
 };
 
 clflush(_readLength);
+#endif
 }
 
 } // namespace WebCore






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [226493] trunk/Tools

2018-01-07 Thread sbarati

Title: [226493] trunk/Tools








Revision 226493
Author sbar...@apple.com
Date 2018-01-07 14:22:52 -0800 (Sun, 07 Jan 2018)


Log Message
Add total exits and total compilations sorting mode to the "full" command in display-profiler-output
https://bugs.webkit.org/show_bug.cgi?id=181372

Reviewed by Filip Pizlo.

Adding these sorting modes makes it easier to analyze functions
that recompile a lot and exit a lot.

* Scripts/display-profiler-output:

Modified Paths

trunk/Tools/ChangeLog
trunk/Tools/Scripts/display-profiler-output




Diff

Modified: trunk/Tools/ChangeLog (226492 => 226493)

--- trunk/Tools/ChangeLog	2018-01-07 06:31:14 UTC (rev 226492)
+++ trunk/Tools/ChangeLog	2018-01-07 22:22:52 UTC (rev 226493)
@@ -1,3 +1,15 @@
+2018-01-07  Saam Barati  
+
+Add total exits and total compilations sorting mode to the "full" command in display-profiler-output
+https://bugs.webkit.org/show_bug.cgi?id=181372
+
+Reviewed by Filip Pizlo.
+
+Adding these sorting modes makes it easier to analyze functions
+that recompile a lot and exit a lot.
+
+* Scripts/display-profiler-output:
+
 2018-01-06  Julien Brianceau  
 
 Unreviewed, remove my Cisco email from contributors.json


Modified: trunk/Tools/Scripts/display-profiler-output (226492 => 226493)

--- trunk/Tools/Scripts/display-profiler-output	2018-01-07 06:31:14 UTC (rev 226492)
+++ trunk/Tools/Scripts/display-profiler-output	2018-01-07 22:22:52 UTC (rev 226493)
@@ -650,6 +650,10 @@
 b.totalMaxTopExecutionCount <=> a.totalMaxTopExecutionCount
 when :machine
 b.totalMaxBottomExecutionCount <=> a.totalMaxBottomExecutionCount
+when :exits
+b.totalExitCount <=> a.totalExitCount
+when :compiles
+b.compilations.size <=> a.compilations.size
 else
 raise
 end
@@ -777,6 +781,10 @@
 when "full", "f"
 if args[0] and (args[0] == "m" or args[0] == "machine")
 summary(:full, :machine)
+elsif args[0] and (args[0] == "e" or args[0] == "exits")
+summary(:full, :exits)
+elsif args[0] and (args[0] == "c" or args[0] == "compiles")
+summary(:full, :compiles)
 else
 summary(:full, :bytecode)
 end






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2018-01-04 Thread sbarati

Title: [226436] trunk/Source/_javascript_Core








Revision 226436
Author sbar...@apple.com
Date 2018-01-04 21:12:51 -0800 (Thu, 04 Jan 2018)


Log Message
Do value profiling in to_this
https://bugs.webkit.org/show_bug.cgi?id=181299

Reviewed by Filip Pizlo.

This patch adds value profiling to to_this. We use the result of the value
profiling only for strict mode code when we don't predict that the input is
of a specific type. This helps when the input is SpecCellOther. Such cells
might implement a custom ToThis, which can produce an arbitrary result. Before
this patch, in prediction propagation, we were saying that a ToThis with a
SpecCellOther input also produced SpecCellOther. However, this is incorrect,
given that the input may implement ToThis that produces an arbitrary result.
This is seen inside Speedometer. This patch fixes an OSR exit loop in Speedometer.

Interestingly, this patch only does value profiling on the slow path. The fast
path of to_this in the LLInt/baseline just perform a structure check. If it
passes, the result is the same as the input. Therefore, doing value profiling
from the fast path wouldn't actually produce new information for the ValueProfile.

* bytecode/BytecodeDumper.cpp:
(JSC::BytecodeDumper::dumpBytecode):
* bytecode/BytecodeList.json:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitToThis):
* bytecompiler/BytecodeGenerator.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
* dfg/DFGPredictionPropagationPhase.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/BytecodeDumper.cpp
trunk/Source/_javascript_Core/bytecode/BytecodeList.json
trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp
trunk/Source/_javascript_Core/bytecompiler/BytecodeGenerator.cpp
trunk/Source/_javascript_Core/bytecompiler/BytecodeGenerator.h
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp
trunk/Source/_javascript_Core/dfg/DFGNode.h
trunk/Source/_javascript_Core/dfg/DFGPredictionPropagationPhase.cpp
trunk/Source/_javascript_Core/runtime/CommonSlowPaths.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (226435 => 226436)

--- trunk/Source/_javascript_Core/ChangeLog	2018-01-05 04:34:07 UTC (rev 226435)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-01-05 05:12:51 UTC (rev 226436)
@@ -1,3 +1,41 @@
+2018-01-04  Saam Barati  
+
+Do value profiling in to_this
+https://bugs.webkit.org/show_bug.cgi?id=181299
+
+Reviewed by Filip Pizlo.
+
+This patch adds value profiling to to_this. We use the result of the value
+profiling only for strict mode code when we don't predict that the input is
+of a specific type. This helps when the input is SpecCellOther. Such cells
+might implement a custom ToThis, which can produce an arbitrary result. Before
+this patch, in prediction propagation, we were saying that a ToThis with a
+SpecCellOther input also produced SpecCellOther. However, this is incorrect,
+given that the input may implement ToThis that produces an arbitrary result.
+This is seen inside Speedometer. This patch fixes an OSR exit loop in Speedometer.
+
+Interestingly, this patch only does value profiling on the slow path. The fast
+path of to_this in the LLInt/baseline just perform a structure check. If it
+passes, the result is the same as the input. Therefore, doing value profiling
+from the fast path wouldn't actually produce new information for the ValueProfile.
+
+* bytecode/BytecodeDumper.cpp:
+(JSC::BytecodeDumper::dumpBytecode):
+* bytecode/BytecodeList.json:
+* bytecode/CodeBlock.cpp:
+(JSC::CodeBlock::finishCreation):
+* bytecompiler/BytecodeGenerator.cpp:
+(JSC::BytecodeGenerator::BytecodeGenerator):
+(JSC::BytecodeGenerator::emitToThis):
+* bytecompiler/BytecodeGenerator.h:
+* dfg/DFGByteCodeParser.cpp:
+(JSC::DFG::ByteCodeParser::parseBlock):
+* dfg/DFGNode.h:
+(JSC::DFG::Node::hasHeapPrediction):
+* dfg/DFGPredictionPropagationPhase.cpp:
+* runtime/CommonSlowPaths.cpp:
+(JSC::SLOW_PATH_DECL):
+
 2018-01-04  Yusuke Suzuki  
 
 [DFG] Unify ToNumber implementation in 32bit and 64bit by changing 32bit Int32Tag and LowestTag


Modified: trunk/Source/_javascript_Core/bytecode/BytecodeDumper.cpp (226435 => 226436)

--- trunk/Source/_javascript_Core/bytecode/BytecodeDumper.cpp	2018-01-05 04:34:07 UTC (rev 226435)
+++ trunk/Source/_javascript_Core/bytecode/BytecodeDumper.cpp	2018-01-05 05:12:51 UTC (rev 226436)
@@ -705,6 +705,7 @@
 if (structure)
 out.print(",

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

2018-01-04 Thread sbarati

Title: [226426] trunk/Source/_javascript_Core








Revision 226426
Author sbar...@apple.com
Date 2018-01-04 16:01:32 -0800 (Thu, 04 Jan 2018)


Log Message
Add a new pattern matching rule to Graph::methodOfGettingAValueProfileFor for SetLocal(@nodeWithHeapPrediction)
https://bugs.webkit.org/show_bug.cgi?id=181296

Reviewed by Filip Pizlo.

Inside Speedometer's Ember test, there is a recompile loop like:
a: GetByVal(..., semanticOriginX)
b: SetLocal(Cell:@a, semanticOriginX)

where the cell check always fails. For reasons I didn't investigate, the
baseline JIT's value profiling doesn't accurately capture the GetByVal's
result.

However, when compiling this cell speculation check in the DFG, we get a null
MethodOfGettingAValueProfile inside Graph::methodOfGettingAValueProfileFor for
this IR pattern because both @a and @b have the same semantic origin. We
should not follow the same semantic origin heuristic when dealing with
SetLocal since SetLocal(@nodeWithHeapPrediction) is such a common IR pattern.
For patterns like this, we introduce a new heuristic: @NodeThatDoesNotProduceAValue(@nodeWithHeapPrediction).
For this IR pattern, we will update the value profile for the semantic origin
for @nodeWithHeapPrediction. So, for the Speedometer example above, we
will correctly update the GetByVal's value profile, which will prevent
an OSR exit loop.

* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::methodOfGettingAValueProfileFor):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGGraph.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (226425 => 226426)

--- trunk/Source/_javascript_Core/ChangeLog	2018-01-05 00:00:25 UTC (rev 226425)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-01-05 00:01:32 UTC (rev 226426)
@@ -1,3 +1,32 @@
+2018-01-04  Saam Barati  
+
+Add a new pattern matching rule to Graph::methodOfGettingAValueProfileFor for SetLocal(@nodeWithHeapPrediction)
+https://bugs.webkit.org/show_bug.cgi?id=181296
+
+Reviewed by Filip Pizlo.
+
+Inside Speedometer's Ember test, there is a recompile loop like:
+a: GetByVal(..., semanticOriginX)
+b: SetLocal(Cell:@a, semanticOriginX)
+
+where the cell check always fails. For reasons I didn't investigate, the
+baseline JIT's value profiling doesn't accurately capture the GetByVal's
+result.
+
+However, when compiling this cell speculation check in the DFG, we get a null
+MethodOfGettingAValueProfile inside Graph::methodOfGettingAValueProfileFor for
+this IR pattern because both @a and @b have the same semantic origin. We
+should not follow the same semantic origin heuristic when dealing with
+SetLocal since SetLocal(@nodeWithHeapPrediction) is such a common IR pattern.
+For patterns like this, we introduce a new heuristic: @NodeThatDoesNotProduceAValue(@nodeWithHeapPrediction).
+For this IR pattern, we will update the value profile for the semantic origin
+for @nodeWithHeapPrediction. So, for the Speedometer example above, we
+will correctly update the GetByVal's value profile, which will prevent
+an OSR exit loop.
+
+* dfg/DFGGraph.cpp:
+(JSC::DFG::Graph::methodOfGettingAValueProfileFor):
+
 2018-01-04  Keith Miller  
 
 Array Storage operations sometimes did not update the indexing mask correctly.


Modified: trunk/Source/_javascript_Core/dfg/DFGGraph.cpp (226425 => 226426)

--- trunk/Source/_javascript_Core/dfg/DFGGraph.cpp	2018-01-05 00:00:25 UTC (rev 226425)
+++ trunk/Source/_javascript_Core/dfg/DFGGraph.cpp	2018-01-05 00:01:32 UTC (rev 226426)
@@ -1617,9 +1617,11 @@
 
 MethodOfGettingAValueProfile Graph::methodOfGettingAValueProfileFor(Node* currentNode, Node* operandNode)
 {
+// This represents IR like `CurrentNode(@operandNode)`. For example: `GetByVal(..., Int32:@GetLocal)`.
+
 for (Node* node = operandNode; node;) {
 // currentNode is null when we're doing speculation checks for checkArgumentTypes().
-if (!currentNode || node->origin.semantic != currentNode->origin.semantic) {
+if (!currentNode || node->origin.semantic != currentNode->origin.semantic || !currentNode->hasResult()) {
 CodeBlock* profiledBlock = baselineCodeBlockFor(node->origin.semantic);
 
 if (node->accessesStack(*this)) {






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2018-01-03 Thread sbarati

Title: [226379] trunk/Source/_javascript_Core








Revision 226379
Author sbar...@apple.com
Date 2018-01-03 16:44:37 -0800 (Wed, 03 Jan 2018)


Log Message
Fix BytecodeParser op_catch assert to work with useProfiler=1
https://bugs.webkit.org/show_bug.cgi?id=181260

Reviewed by Keith Miller.

op_catch was asserting that the current block was empty. This is only true
if the profiler isn't enabled. When the profiler is enabled, we will
insert a CountExecution node before each bytecode. This patch fixes the
assert to work with the profiler.

* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (226378 => 226379)

--- trunk/Source/_javascript_Core/ChangeLog	2018-01-04 00:42:21 UTC (rev 226378)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-01-04 00:44:37 UTC (rev 226379)
@@ -1,3 +1,18 @@
+2018-01-03  Saam Barati  
+
+Fix BytecodeParser op_catch assert to work with useProfiler=1
+https://bugs.webkit.org/show_bug.cgi?id=181260
+
+Reviewed by Keith Miller.
+
+op_catch was asserting that the current block was empty. This is only true
+if the profiler isn't enabled. When the profiler is enabled, we will
+insert a CountExecution node before each bytecode. This patch fixes the
+assert to work with the profiler.
+
+* dfg/DFGByteCodeParser.cpp:
+(JSC::DFG::ByteCodeParser::parseBlock):
+
 2018-01-03  Per Arne Vollan  
 
 [Win][Debug] testapi link error.


Modified: trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp (226378 => 226379)

--- trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp	2018-01-04 00:42:21 UTC (rev 226378)
+++ trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp	2018-01-04 00:44:37 UTC (rev 226379)
@@ -5410,7 +5410,7 @@
 NEXT_OPCODE(op_catch);
 }
 
-RELEASE_ASSERT(!m_currentBlock->size());
+RELEASE_ASSERT(!m_currentBlock->size() || (m_graph.compilation() && m_currentBlock->size() == 1 && m_currentBlock->at(0)->op() == CountExecution));
 
 ValueProfileAndOperandBuffer* buffer = static_cast(currentInstruction[3].u.pointer);
 






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [226351] trunk

2018-01-02 Thread sbarati

Title: [226351] trunk








Revision 226351
Author sbar...@apple.com
Date 2018-01-02 19:59:16 -0800 (Tue, 02 Jan 2018)


Log Message
Incorrect assertion inside AccessCase
https://bugs.webkit.org/show_bug.cgi?id=181200


Reviewed by Yusuke Suzuki.

JSTests:

* stress/setter-same-base-and-rhs-invalid-assertion-inside-access-case.js: Added.
(ctor):
(theFunc):
(run):

Source/_javascript_Core:

Consider a PutById compiled to a setter in a function like so:

```
function foo(o) { o.f = o; }
```

The DFG will often assign the same registers to the baseGPR (o in o.f) and the
valueRegsPayloadGPR (o in the RHS). The code totally works when these are assigned
to the same register. However, we're asserting that they're not the same register.
This patch just removes this invalid assertion.

* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/AccessCase.cpp


Added Paths

trunk/JSTests/stress/setter-same-base-and-rhs-invalid-assertion-inside-access-case.js




Diff

Modified: trunk/JSTests/ChangeLog (226350 => 226351)

--- trunk/JSTests/ChangeLog	2018-01-03 03:44:01 UTC (rev 226350)
+++ trunk/JSTests/ChangeLog	2018-01-03 03:59:16 UTC (rev 226351)
@@ -1,3 +1,16 @@
+2018-01-02  Saam Barati  
+
+Incorrect assertion inside AccessCase
+https://bugs.webkit.org/show_bug.cgi?id=181200
+
+
+Reviewed by Yusuke Suzuki.
+
+* stress/setter-same-base-and-rhs-invalid-assertion-inside-access-case.js: Added.
+(ctor):
+(theFunc):
+(run):
+
 2018-01-02  Caio Lima  
 
 [ESNext][BigInt] Implement BigIntConstructor and BigIntPrototype


Added: trunk/JSTests/stress/setter-same-base-and-rhs-invalid-assertion-inside-access-case.js (0 => 226351)

--- trunk/JSTests/stress/setter-same-base-and-rhs-invalid-assertion-inside-access-case.js	(rev 0)
+++ trunk/JSTests/stress/setter-same-base-and-rhs-invalid-assertion-inside-access-case.js	2018-01-03 03:59:16 UTC (rev 226351)
@@ -0,0 +1,17 @@
+function ctor() {}
+ctor.prototype.__defineSetter__("f", function () { });
+
+function theFunc(o) {
+o.f = o;
+}
+noInline(theFunc);
+function run(o) {
+theFunc(o);
+}
+
+for (let i = 0; i < 10; ++i) {
+run(new ctor())
+let o = new ctor();
+o.g = 54;
+run(o);
+}


Modified: trunk/Source/_javascript_Core/ChangeLog (226350 => 226351)

--- trunk/Source/_javascript_Core/ChangeLog	2018-01-03 03:44:01 UTC (rev 226350)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-01-03 03:59:16 UTC (rev 226351)
@@ -1,3 +1,25 @@
+2018-01-02  Saam Barati  
+
+Incorrect assertion inside AccessCase
+https://bugs.webkit.org/show_bug.cgi?id=181200
+
+
+Reviewed by Yusuke Suzuki.
+
+Consider a PutById compiled to a setter in a function like so:
+
+```
+function foo(o) { o.f = o; }
+```
+
+The DFG will often assign the same registers to the baseGPR (o in o.f) and the
+valueRegsPayloadGPR (o in the RHS). The code totally works when these are assigned
+to the same register. However, we're asserting that they're not the same register.
+This patch just removes this invalid assertion.
+
+* bytecode/AccessCase.cpp:
+(JSC::AccessCase::generateImpl):
+
 2018-01-02  Caio Lima  
 
 [ESNext][BigInt] Implement BigIntConstructor and BigIntPrototype


Modified: trunk/Source/_javascript_Core/bytecode/AccessCase.cpp (226350 => 226351)

--- trunk/Source/_javascript_Core/bytecode/AccessCase.cpp	2018-01-03 03:44:01 UTC (rev 226350)
+++ trunk/Source/_javascript_Core/bytecode/AccessCase.cpp	2018-01-03 03:59:16 UTC (rev 226351)
@@ -692,7 +692,7 @@
 if (m_type == Getter || m_type == Setter) {
 auto& access = this->as();
 ASSERT(baseGPR != loadedValueGPR);
-ASSERT(m_type != Setter || (baseGPR != valueRegsPayloadGPR && loadedValueGPR != valueRegsPayloadGPR));
+ASSERT(m_type != Setter || valueRegsPayloadGPR != loadedValueGPR);
 
 // Create a JS call using a JS call inline cache. Assume that:
 //






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [226305] trunk

2017-12-28 Thread sbarati

Title: [226305] trunk








Revision 226305
Author sbar...@apple.com
Date 2017-12-28 10:13:15 -0800 (Thu, 28 Dec 2017)


Log Message
Assertion used to determine if something is an async generator is wrong
https://bugs.webkit.org/show_bug.cgi?id=181168


Reviewed by Yusuke Suzuki.

JSTests:

* stress/async-generator-assertion.js: Added.

Source/_javascript_Core:

Previous assertions were doing a get on the base value for @@asyncIterator.
This symbol is defined on AsyncGeneratorPrototype. The base value may change
its prototype, but it's still an async generator as far as our system is
concerned. This patch updates the assertion to check for a private property
on the base value.

* builtins/AsyncGeneratorPrototype.js:
(globalPrivate.asyncGeneratorReject):
(globalPrivate.asyncGeneratorResolve):
(globalPrivate.asyncGeneratorResumeNext):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/builtins/AsyncGeneratorPrototype.js


Added Paths

trunk/JSTests/stress/async-generator-assertion.js




Diff

Modified: trunk/JSTests/ChangeLog (226304 => 226305)

--- trunk/JSTests/ChangeLog	2017-12-28 14:17:06 UTC (rev 226304)
+++ trunk/JSTests/ChangeLog	2017-12-28 18:13:15 UTC (rev 226305)
@@ -1,3 +1,13 @@
+2017-12-28  Saam Barati  
+
+Assertion used to determine if something is an async generator is wrong
+https://bugs.webkit.org/show_bug.cgi?id=181168
+
+
+Reviewed by Yusuke Suzuki.
+
+* stress/async-generator-assertion.js: Added.
+
 2017-12-21  Guillaume Emont  
 
 Skip stress/splay-flash-access tests on memory limited platforms


Added: trunk/JSTests/stress/async-generator-assertion.js (0 => 226305)

--- trunk/JSTests/stress/async-generator-assertion.js	(rev 0)
+++ trunk/JSTests/stress/async-generator-assertion.js	2017-12-28 18:13:15 UTC (rev 226305)
@@ -0,0 +1,36 @@
+function assert(b) {
+if (!b)
+throw new Error("Bad");
+}
+
+async function* asyncIterator() {
+yield 42;
+}
+
+function test1() {
+let p = asyncIterator();
+p.next().then((x) => {
+assert(x.value === 42);
+assert(x.done === false);
+});
+p.__proto__ = {};
+assert(p.next === undefined);
+}
+test1();
+
+let error = null;
+async function test2() {
+let p2 = asyncIterator();
+p2.__proto__ = {};
+try {
+for await (let x of p2) {
+throw new Error("Bad!");
+}
+} 
+catch(e) {
+error = e;
+}
+}
+test2();
+assert(error instanceof TypeError);
+assert(error.message === "undefined is not a function (near '...x of p2...')");


Modified: trunk/Source/_javascript_Core/ChangeLog (226304 => 226305)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-28 14:17:06 UTC (rev 226304)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-28 18:13:15 UTC (rev 226305)
@@ -1,3 +1,22 @@
+2017-12-28  Saam Barati  
+
+Assertion used to determine if something is an async generator is wrong
+https://bugs.webkit.org/show_bug.cgi?id=181168
+
+
+Reviewed by Yusuke Suzuki.
+
+Previous assertions were doing a get on the base value for @@asyncIterator.
+This symbol is defined on AsyncGeneratorPrototype. The base value may change
+its prototype, but it's still an async generator as far as our system is
+concerned. This patch updates the assertion to check for a private property
+on the base value.
+
+* builtins/AsyncGeneratorPrototype.js:
+(globalPrivate.asyncGeneratorReject):
+(globalPrivate.asyncGeneratorResolve):
+(globalPrivate.asyncGeneratorResumeNext):
+
 2017-12-27  Carlos Alberto Lopez Perez  
 
 Build fix after r226299 (3)


Modified: trunk/Source/_javascript_Core/builtins/AsyncGeneratorPrototype.js (226304 => 226305)

--- trunk/Source/_javascript_Core/builtins/AsyncGeneratorPrototype.js	2017-12-28 14:17:06 UTC (rev 226304)
+++ trunk/Source/_javascript_Core/builtins/AsyncGeneratorPrototype.js	2017-12-28 18:13:15 UTC (rev 226305)
@@ -103,7 +103,7 @@
 {
 "use strict";
 
-@assert(generator.@asyncIteratorSymbol !== @undefined, "Generator is not an AsyncGenerator instance.");
+@assert(typeof generator.@asyncGeneratorSuspendReason === "number", "Generator is not an AsyncGenerator instance.");
 
 const { promiseCapability } = @asyncGeneratorDequeue(generator);
 promiseCapability.@reject.@call(@undefined, exception);
@@ -116,7 +116,7 @@
 {
 "use strict";
 
-@assert(generator.@asyncIteratorSymbol !== @undefined, "Generator is not an AsyncGenerator instance.");
+@assert(typeof generator.@asyncGeneratorSuspendReason === "number", "Generator is not an AsyncGenerator instance.");
 
 const { promiseCapability } = @asyncGeneratorDequeue(generator);
 promiseCapability.@resolve.@call(@undefined, { done, value: value });
@@ -203,7

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

2017-12-21 Thread sbarati

Title: [226254] trunk/Source/_javascript_Core








Revision 226254
Author sbar...@apple.com
Date 2017-12-21 19:05:18 -0800 (Thu, 21 Dec 2017)


Log Message
lowering get_by_val to GetById inside bytecode parser should check for BadType exit kind
https://bugs.webkit.org/show_bug.cgi?id=181112

Reviewed by Mark Lam.

The React subtest in Speedometer has a get_by_val it always converts
into a GetById in the DFG. This GetById always exits because of the incoming
identifier is a rope. This patch fixes this infinite exit loop
by only doing this transformation if we haven't exited due to BadType.

* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (226253 => 226254)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-22 02:17:58 UTC (rev 226253)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-22 03:05:18 UTC (rev 226254)
@@ -1,3 +1,18 @@
+2017-12-21  Saam Barati  
+
+lowering get_by_val to GetById inside bytecode parser should check for BadType exit kind
+https://bugs.webkit.org/show_bug.cgi?id=181112
+
+Reviewed by Mark Lam.
+
+The React subtest in Speedometer has a get_by_val it always converts
+into a GetById in the DFG. This GetById always exits because of the incoming
+identifier is a rope. This patch fixes this infinite exit loop
+by only doing this transformation if we haven't exited due to BadType.
+
+* dfg/DFGByteCodeParser.cpp:
+(JSC::DFG::ByteCodeParser::parseBlock):
+
 2017-12-21  Mark Lam  
 
 Add WTF::PoisonedUniquePtr to replace std::unique_ptr when poisoning is desired.


Modified: trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp (226253 => 226254)

--- trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp	2017-12-22 02:17:58 UTC (rev 226253)
+++ trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp	2017-12-22 03:05:18 UTC (rev 226254)
@@ -4875,7 +4875,12 @@
 ByValInfo* byValInfo = m_inlineStackTop->m_byValInfos.get(CodeOrigin(currentCodeOrigin().bytecodeIndex));
 // FIXME: When the bytecode is not compiled in the baseline JIT, byValInfo becomes null.
 // At that time, there is no information.
-if (byValInfo && byValInfo->stubInfo && !byValInfo->tookSlowPath && !m_inlineStackTop->m_exitProfile.hasExitSite(m_currentIndex, BadIdent) && !m_inlineStackTop->m_exitProfile.hasExitSite(m_currentIndex, BadCell)) {
+if (byValInfo
+&& byValInfo->stubInfo
+&& !byValInfo->tookSlowPath
+&& !m_inlineStackTop->m_exitProfile.hasExitSite(m_currentIndex, BadIdent)
+&& !m_inlineStackTop->m_exitProfile.hasExitSite(m_currentIndex, BadType)
+&& !m_inlineStackTop->m_exitProfile.hasExitSite(m_currentIndex, BadCell)) {
 compiledAsGetById = true;
 identifierNumber = m_graph.identifiers().ensure(byValInfo->cachedId.impl());
 UniquedStringImpl* uid = m_graph.identifiers()[identifierNumber];






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-12-20 Thread sbarati

Title: [226208] trunk/Source/_javascript_Core








Revision 226208
Author sbar...@apple.com
Date 2017-12-20 17:54:46 -0800 (Wed, 20 Dec 2017)


Log Message
GetPropertyEnumerator in DFG/FTL should not unconditionally speculate cell
https://bugs.webkit.org/show_bug.cgi?id=181054

Reviewed by Mark Lam.

Speedometer's react subtest has a function that is in an OSR exit loop because
we used to unconditionally speculate cell for the operand to GetPropertyEnumerator.
This fix doesn't seem to speed up Speedometer at all, but it's good hygiene
for our compiler to not have this pathology. This patch adds a generic
GetPropertyEnumerator to prevent the exit loop.

* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetPropertyEnumerator):
* jit/JITOperations.cpp:
* jit/JITOperations.h:

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGFixupPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT32_64.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
trunk/Source/_javascript_Core/jit/JITOperations.cpp
trunk/Source/_javascript_Core/jit/JITOperations.h




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (226207 => 226208)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-21 01:49:00 UTC (rev 226207)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-21 01:54:46 UTC (rev 226208)
@@ -1,3 +1,27 @@
+2017-12-20  Saam Barati  
+
+GetPropertyEnumerator in DFG/FTL should not unconditionally speculate cell
+https://bugs.webkit.org/show_bug.cgi?id=181054
+
+Reviewed by Mark Lam.
+
+Speedometer's react subtest has a function that is in an OSR exit loop because
+we used to unconditionally speculate cell for the operand to GetPropertyEnumerator.
+This fix doesn't seem to speed up Speedometer at all, but it's good hygiene 
+for our compiler to not have this pathology. This patch adds a generic
+GetPropertyEnumerator to prevent the exit loop.
+
+* dfg/DFGFixupPhase.cpp:
+(JSC::DFG::FixupPhase::fixupNode):
+* dfg/DFGSpeculativeJIT32_64.cpp:
+(JSC::DFG::SpeculativeJIT::compile):
+* dfg/DFGSpeculativeJIT64.cpp:
+(JSC::DFG::SpeculativeJIT::compile):
+* ftl/FTLLowerDFGToB3.cpp:
+(JSC::FTL::DFG::LowerDFGToB3::compileGetPropertyEnumerator):
+* jit/JITOperations.cpp:
+* jit/JITOperations.h:
+
 2017-12-20  Daniel Bates  
 
 Remove Alternative Presentation Button


Modified: trunk/Source/_javascript_Core/dfg/DFGFixupPhase.cpp (226207 => 226208)

--- trunk/Source/_javascript_Core/dfg/DFGFixupPhase.cpp	2017-12-21 01:49:00 UTC (rev 226207)
+++ trunk/Source/_javascript_Core/dfg/DFGFixupPhase.cpp	2017-12-21 01:54:46 UTC (rev 226208)
@@ -1725,7 +1725,8 @@
 break;
 }
 case GetPropertyEnumerator: {
-fixEdge(node->child1());
+if (node->child1()->shouldSpeculateCell())
+fixEdge(node->child1());
 break;
 }
 case GetEnumeratorStructurePname: {


Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT32_64.cpp (226207 => 226208)

--- trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT32_64.cpp	2017-12-21 01:49:00 UTC (rev 226207)
+++ trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT32_64.cpp	2017-12-21 01:54:46 UTC (rev 226208)
@@ -5358,14 +5358,25 @@
 break;
 }
 case GetPropertyEnumerator: {
-SpeculateCellOperand base(this, node->child1());
-GPRFlushedCallResult result(this);
-GPRReg resultGPR = result.gpr();
+if (node->child1().useKind() == CellUse) {
+SpeculateCellOperand base(this, node->child1());
+GPRFlushedCallResult result(this);
+GPRReg resultGPR = result.gpr();
 
-flushRegisters();
-callOperation(operationGetPropertyEnumerator, resultGPR, base.gpr());
-m_jit.exceptionCheck();
-cellResult(resultGPR, node);
+flushRegisters();
+callOperation(operationGetPropertyEnumeratorCell, resultGPR, base.gpr());
+m_jit.exceptionCheck();
+cellResult(resultGPR, node);
+} else {
+JSValueOperand base(this, node->child1());
+GPRFlushedCallResult result(this);
+GPRReg resultGPR = result.gpr();
+
+flushRegisters();
+callOperation(operationGetPropertyEnumerator, resultGPR, base.jsValueRegs());
+m_jit.exceptionCheck();
+cellResult(resultGPR, node);
+}
 break;
 }
 case GetEnumeratorStructurePname:


Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp (226207

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

2017-12-19 Thread sbarati

Title: [226139] trunk/Source/_javascript_Core








Revision 226139
Author sbar...@apple.com
Date 2017-12-19 13:51:27 -0800 (Tue, 19 Dec 2017)


Log Message
We forgot to do index masking for in bounds int32 arrays in the FTL
https://bugs.webkit.org/show_bug.cgi?id=180987

Reviewed by Keith Miller.

* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (226138 => 226139)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-19 21:48:19 UTC (rev 226138)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-19 21:51:27 UTC (rev 226139)
@@ -1,3 +1,13 @@
+2017-12-19  Saam Barati  
+
+We forgot to do index masking for in bounds int32 arrays in the FTL
+https://bugs.webkit.org/show_bug.cgi?id=180987
+
+Reviewed by Keith Miller.
+
+* ftl/FTLLowerDFGToB3.cpp:
+(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
+
 2017-12-19  Yusuke Suzuki  
 
 [DFG][FTL] NewRegexp shoud be fast


Modified: trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp (226138 => 226139)

--- trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp	2017-12-19 21:48:19 UTC (rev 226138)
+++ trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp	2017-12-19 21:51:27 UTC (rev 226139)
@@ -3638,9 +3638,11 @@
 
 IndexedAbstractHeap& heap = m_node->arrayMode().type() == Array::Int32 ?
 m_heaps.indexedInt32Properties : m_heaps.indexedContiguousProperties;
-
+
+LValue base = lowCell(m_node->child1());
+
 if (m_node->arrayMode().isInBounds()) {
-LValue result = m_out.load64(baseIndex(heap, storage, index, m_node->child2()));
+LValue result = m_out.load64(maskedIndex(heap, storage, index, base, m_node->child2()));
 LValue isHole = m_out.isZero64(result);
 if (m_node->arrayMode().isSaneChain()) {
 DFG_ASSERT(
@@ -3653,8 +3655,6 @@
 return;
 }
 
-LValue base = lowCell(m_node->child1());
-
 LBasicBlock fastCase = m_out.newBlock();
 LBasicBlock slowCase = m_out.newBlock();
 LBasicBlock continuation = m_out.newBlock();






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-12-18 Thread sbarati

Title: [226081] trunk/Source/_javascript_Core








Revision 226081
Author sbar...@apple.com
Date 2017-12-18 14:20:22 -0800 (Mon, 18 Dec 2017)


Log Message
Follow up to bug#179762. Fix PreciseLocalClobberize to handle Spread/PhantomSpread(PhantomNewArrayBuffer)

* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGPreciseLocalClobberize.h




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (226080 => 226081)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-18 22:05:23 UTC (rev 226080)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-18 22:20:22 UTC (rev 226081)
@@ -1,3 +1,10 @@
+2017-12-18  Saam Barati  
+
+Follow up to bug#179762. Fix PreciseLocalClobberize to handle Spread/PhantomSpread(PhantomNewArrayBuffer)
+
+* dfg/DFGPreciseLocalClobberize.h:
+(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
+
 2017-12-16  Filip Pizlo  
 
 Vector index masking


Modified: trunk/Source/_javascript_Core/dfg/DFGPreciseLocalClobberize.h (226080 => 226081)

--- trunk/Source/_javascript_Core/dfg/DFGPreciseLocalClobberize.h	2017-12-18 22:05:23 UTC (rev 226080)
+++ trunk/Source/_javascript_Core/dfg/DFGPreciseLocalClobberize.h	2017-12-18 22:20:22 UTC (rev 226081)
@@ -120,9 +120,16 @@
 m_read(VirtualRegister(inlineCallFrame->stackOffset + CallFrameSlot::argumentCount));
 };
 
-auto readSpreadOfPhantomCreateRest = [&] (Node* spread) {
+auto readSpread = [&] (Node* spread) {
 ASSERT(spread->op() == Spread || spread->op() == PhantomSpread);
-ASSERT(spread->child1()->op() == PhantomCreateRest);
+if (!spread->child1()->isPhantomAllocation())
+return;
+
+ASSERT(spread->child1()->op() == PhantomCreateRest || spread->child1()->op() == PhantomNewArrayBuffer);
+if (spread->child1()->op() == PhantomNewArrayBuffer) {
+// This reads from a constant buffer.
+return;
+}
 InlineCallFrame* inlineCallFrame = spread->child1()->origin.semantic.inlineCallFrame;
 unsigned numberOfArgumentsToSkip = spread->child1()->numberOfArgumentsToSkip();
 readFrame(inlineCallFrame, numberOfArgumentsToSkip);
@@ -135,7 +142,7 @@
 if (bitVector->get(i)) {
 Node* child = m_graph.varArgChild(arrayWithSpread, i).node();
 if (child->op() == PhantomSpread)
-readSpreadOfPhantomCreateRest(child);
+readSpread(child);
 }
 }
 };
@@ -181,7 +188,7 @@
 if (m_node->argumentsChild()->op() == PhantomNewArrayWithSpread)
 readNewArrayWithSpreadNode(m_node->argumentsChild().node());
 else
-readSpreadOfPhantomCreateRest(m_node->argumentsChild().node());
+readSpread(m_node->argumentsChild().node());
 } else {
 InlineCallFrame* inlineCallFrame;
 if (m_node->hasArgumentsChild() && m_node->argumentsChild())
@@ -204,8 +211,7 @@
 }
 
 case Spread:
-if (m_node->child1()->op() == PhantomCreateRest)
-readSpreadOfPhantomCreateRest(m_node);
+readSpread(m_node);
 break;
 
 case NewArrayWithSpread: {






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [225966] trunk

2017-12-14 Thread sbarati

Title: [225966] trunk








Revision 225966
Author sbar...@apple.com
Date 2017-12-14 22:20:07 -0800 (Thu, 14 Dec 2017)


Log Message
The CleanUp after LICM is erroneously removing a Check
https://bugs.webkit.org/show_bug.cgi?id=180852


Reviewed by Filip Pizlo.

JSTests:

* stress/dont-run-cleanup-after-licm.js: Added.

Source/_javascript_Core:

There was a bug where CleanUp phase relied on isProved() bits and LICM
changed them in an invalid way. The bug is as follows:

We have two loops, L1 and L2, and two preheaders, P1 and P2. L2 is nested
inside of L1. We have a Check inside a node inside L1, say in basic block BB,
and that Check dominates all of L2. This is also a hoisting candidate, so we
hoist it outside of L1 and put it inside P1. Then, when we run AI, we look at
the preheader for each loop inside L1, so P1 and P2. When considering P2,
we execute the Check. Inside P2, before any hoisting is done, this Check
is dead code, because BB dominates P2. When we use AI to "execute" the
Check, it'll set its proof status to proved. This is because inside P2,
in the program before LICM runs, the Check is indeed proven at P2. But
it is not proven inside P1. This "execute" call will set our proof status
for the node inside *P1*, hence, we crash.

The fix here is to make LICM precise when updating the ProofStatus of an edge.
It can trust the AI state at the preheader it hoists the node to, but it can't
trust the state when executing effects inside inner loops's preheaders.

* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreter.h
trunk/Source/_javascript_Core/dfg/DFGAtTailAbstractState.h
trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.h
trunk/Source/_javascript_Core/dfg/DFGLICMPhase.cpp


Added Paths

trunk/JSTests/stress/dont-run-cleanup-after-licm.js




Diff

Modified: trunk/JSTests/ChangeLog (225965 => 225966)

--- trunk/JSTests/ChangeLog	2017-12-15 05:45:17 UTC (rev 225965)
+++ trunk/JSTests/ChangeLog	2017-12-15 06:20:07 UTC (rev 225966)
@@ -1,3 +1,13 @@
+2017-12-14  Saam Barati  
+
+The CleanUp after LICM is erroneously removing a Check
+https://bugs.webkit.org/show_bug.cgi?id=180852
+
+
+Reviewed by Filip Pizlo.
+
+* stress/dont-run-cleanup-after-licm.js: Added.
+
 2017-12-14  Michael Saboff  
 
 REGRESSION (r225695): Repro crash on yahoo login page


Added: trunk/JSTests/stress/dont-run-cleanup-after-licm.js (0 => 225966)

--- trunk/JSTests/stress/dont-run-cleanup-after-licm.js	(rev 0)
+++ trunk/JSTests/stress/dont-run-cleanup-after-licm.js	2017-12-15 06:20:07 UTC (rev 225966)
@@ -0,0 +1,14 @@
+function foo(string) {
+var result1, result2;
+for (var i = 0; i < 1000; ++i) {
+result1 = string[0]; 
+for (var j = 0; j < 10; ++j)
+result2 = 1;
+}
+   return [result1, result2];
+}
+noInline(foo);
+
+foo(" ");
+for (var i = 0; i < 1000; i++)
+foo(new Error());


Modified: trunk/Source/_javascript_Core/ChangeLog (225965 => 225966)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-15 05:45:17 UTC (rev 225965)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-15 06:20:07 UTC (rev 225966)
@@ -1,3 +1,33 @@
+2017-12-14  Saam Barati  
+
+The CleanUp after LICM is erroneously removing a Check
+https://bugs.webkit.org/show_bug.cgi?id=180852
+
+
+Reviewed by Filip Pizlo.
+
+There was a bug where CleanUp phase relied on isProved() bits and LICM
+changed them in an invalid way. The bug is as follows:
+
+We have two loops, L1 and L2, and two preheaders, P1 and P2. L2 is nested
+inside of L1. We have a Check inside a node inside L1, say in basic block BB,
+and that Check dominates all of L2. This is also a hoisting candidate, so we
+hoist it outside of L1 and put it inside P1. Then, when we run AI, we look at
+the preheader for each loop inside L1, so P1 and P2. When considering P2,
+we execute the Check. Inside P2, before any hoisting is done, this Check
+is dead code, because BB dominates P2. When we use AI to "execute" the
+Check, it'll set its proof status to proved. This is because inside P2,
+in the program before LICM runs, the Check is indeed proven at P2. But
+it is not proven inside P1. This "execute" call will set our proof status
+for the node inside *P1*, hence, we crash.
+
+The fix here is to make LICM precise when updating the ProofStatus of an edge.
+It can trust the AI state at the preheader it hoists the node to, but it can't
+trust the state when executing effects inside inner loops's preheaders.
+
+* dfg/DFGPlan.cpp:
+(JSC::DFG::Plan::compileInThreadImpl):
+
 2017-12-14  David Kilzer

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

2017-12-14 Thread sbarati

Title: [225912] trunk/Source/bmalloc








Revision 225912
Author sbar...@apple.com
Date 2017-12-14 11:10:54 -0800 (Thu, 14 Dec 2017)


Log Message
logVMFailure should not simulate crash on iOS
https://bugs.webkit.org/show_bug.cgi?id=180790

Reviewed by JF Bastien.

The Gigacage allocation on iOS is expected to fail in certain circumstances.
Let's not simulate a crash on failure because since this is expected behavior.

* bmalloc/VMAllocate.h:
(bmalloc::tryVMAllocate):

Modified Paths

trunk/Source/bmalloc/ChangeLog
trunk/Source/bmalloc/bmalloc/VMAllocate.h




Diff

Modified: trunk/Source/bmalloc/ChangeLog (225911 => 225912)

--- trunk/Source/bmalloc/ChangeLog	2017-12-14 19:08:32 UTC (rev 225911)
+++ trunk/Source/bmalloc/ChangeLog	2017-12-14 19:10:54 UTC (rev 225912)
@@ -1,3 +1,16 @@
+2017-12-14  Saam Barati  
+
+logVMFailure should not simulate crash on iOS
+https://bugs.webkit.org/show_bug.cgi?id=180790
+
+Reviewed by JF Bastien.
+
+The Gigacage allocation on iOS is expected to fail in certain circumstances. 
+Let's not simulate a crash on failure because since this is expected behavior.
+
+* bmalloc/VMAllocate.h:
+(bmalloc::tryVMAllocate):
+
 2017-12-11  Tim Horton  
 
 Stop using deprecated target conditional for simulator builds


Modified: trunk/Source/bmalloc/bmalloc/VMAllocate.h (225911 => 225912)

--- trunk/Source/bmalloc/bmalloc/VMAllocate.h	2017-12-14 19:08:32 UTC (rev 225911)
+++ trunk/Source/bmalloc/bmalloc/VMAllocate.h	2017-12-14 19:10:54 UTC (rev 225912)
@@ -122,10 +122,8 @@
 {
 vmValidate(vmSize);
 void* result = mmap(0, vmSize, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON | BMALLOC_NORESERVE, BMALLOC_VM_TAG, 0);
-if (result == MAP_FAILED) {
-logVMFailure(vmSize);
+if (result == MAP_FAILED)
 return nullptr;
-}
 return result;
 }
 






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [225891] trunk

2017-12-13 Thread sbarati

Title: [225891] trunk








Revision 225891
Author sbar...@apple.com
Date 2017-12-13 20:10:02 -0800 (Wed, 13 Dec 2017)


Log Message
Arrow functions need their own structure because they have different properties than sloppy functions
https://bugs.webkit.org/show_bug.cgi?id=180779


Reviewed by Mark Lam.

JSTests:

* stress/arrow-function-needs-its-own-structure.js: Added.
(assert):
(readPrototype):
(noInline.let.f1):
(noInline):

Source/_javascript_Core:

We were using the same structure for sloppy functions and
arrow functions. This broke our IC caching machinery because
these two types of functions actually have different properties.
This patch gives them different structures.

* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter::executeEffects):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewFunction):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/JSFunction.cpp:
(JSC::JSFunction::selectStructureForNewFuncExp):
(JSC::JSFunction::create):
* runtime/JSFunction.h:
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::arrowFunctionStructure const):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
trunk/Source/_javascript_Core/runtime/FunctionConstructor.cpp
trunk/Source/_javascript_Core/runtime/JSFunction.cpp
trunk/Source/_javascript_Core/runtime/JSFunction.h
trunk/Source/_javascript_Core/runtime/JSFunctionInlines.h
trunk/Source/_javascript_Core/runtime/JSGlobalObject.cpp
trunk/Source/_javascript_Core/runtime/JSGlobalObject.h


Added Paths

trunk/JSTests/stress/arrow-function-needs-its-own-structure.js




Diff

Modified: trunk/JSTests/ChangeLog (225890 => 225891)

--- trunk/JSTests/ChangeLog	2017-12-14 03:05:39 UTC (rev 225890)
+++ trunk/JSTests/ChangeLog	2017-12-14 04:10:02 UTC (rev 225891)
@@ -1,5 +1,19 @@
 2017-12-13  Saam Barati  
 
+Arrow functions need their own structure because they have different properties than sloppy functions
+https://bugs.webkit.org/show_bug.cgi?id=180779
+
+
+Reviewed by Mark Lam.
+
+* stress/arrow-function-needs-its-own-structure.js: Added.
+(assert):
+(readPrototype):
+(noInline.let.f1):
+(noInline):
+
+2017-12-13  Saam Barati  
+
 Fix how JSFunction handles "caller" and "arguments" for functions that don't have those properties
 https://bugs.webkit.org/show_bug.cgi?id=163579
 


Added: trunk/JSTests/stress/arrow-function-needs-its-own-structure.js (0 => 225891)

--- trunk/JSTests/stress/arrow-function-needs-its-own-structure.js	(rev 0)
+++ trunk/JSTests/stress/arrow-function-needs-its-own-structure.js	2017-12-14 04:10:02 UTC (rev 225891)
@@ -0,0 +1,23 @@
+function assert(b) {
+if (!b)
+throw new Error;
+}
+
+function readPrototype(f) {
+return f.prototype;
+}
+noInline(readPrototype);
+
+{
+let f1 = function () { };
+let f2 = () => undefined;
+for (let i = 0; i < 100; ++i) {
+assert(!f2.hasOwnProperty("prototype"));
+assert(f1.hasOwnProperty("prototype"));
+}
+
+for (let i = 0; i < 100; ++i)
+assert(readPrototype(f2) === undefined);
+assert(readPrototype(f1) !== undefined);
+assert(readPrototype(f1) === f1.prototype);
+}


Modified: trunk/Source/_javascript_Core/ChangeLog (225890 => 225891)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-14 03:05:39 UTC (rev 225890)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-14 04:10:02 UTC (rev 225891)
@@ -1,3 +1,36 @@
+2017-12-13  Saam Barati  
+
+Arrow functions need their own structure because they have different properties than sloppy functions
+https://bugs.webkit.org/show_bug.cgi?id=180779
+
+
+Reviewed by Mark Lam.
+
+We were using the same structure for sloppy functions and
+arrow functions. This broke our IC caching machinery because
+these two types of functions actually have different properties.
+This patch gives them different structures.
+
+* dfg/DFGAbstractInterpreterInlines.h:
+(JSC::DFG::AbstractInterpreter::executeEffects):
+* dfg/DFGSpeculativeJIT.cpp:
+(JSC::DFG::SpeculativeJIT::compileNewFunction):
+* ftl/FTLLowerDFGToB3.cpp:
+(JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
+* runtime/FunctionConstructor.cpp:
+(JSC::constructFunctionSkippingEvalEnabledCheck):
+*

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

2017-12-13 Thread sbarati

Title: [225880] trunk/Source/_javascript_Core








Revision 225880
Author sbar...@apple.com
Date 2017-12-13 16:31:58 -0800 (Wed, 13 Dec 2017)


Log Message
Take a value driven approach to how we emit structure checks in TypeCheckHoistingPhase to obviate the need for static_assert guards
https://bugs.webkit.org/show_bug.cgi?id=180771

Reviewed by JF Bastien.

* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::run):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGTypeCheckHoistingPhase.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (225879 => 225880)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-14 00:29:31 UTC (rev 225879)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-14 00:31:58 UTC (rev 225880)
@@ -1,5 +1,15 @@
 2017-12-13  Saam Barati  
 
+Take a value driven approach to how we emit structure checks in TypeCheckHoistingPhase to obviate the need for static_assert guards
+https://bugs.webkit.org/show_bug.cgi?id=180771
+
+Reviewed by JF Bastien.
+
+* dfg/DFGTypeCheckHoistingPhase.cpp:
+(JSC::DFG::TypeCheckHoistingPhase::run):
+
+2017-12-13  Saam Barati  
+
 REGRESSION(r225844): Around 850 new JSC failures on 32-bit
 https://bugs.webkit.org/show_bug.cgi?id=180764
 


Modified: trunk/Source/_javascript_Core/dfg/DFGTypeCheckHoistingPhase.cpp (225879 => 225880)

--- trunk/Source/_javascript_Core/dfg/DFGTypeCheckHoistingPhase.cpp	2017-12-14 00:29:31 UTC (rev 225879)
+++ trunk/Source/_javascript_Core/dfg/DFGTypeCheckHoistingPhase.cpp	2017-12-14 00:31:58 UTC (rev 225880)
@@ -145,8 +145,7 @@
 OpInfo(variable), Edge(node));
 if (iter->value.m_structure) {
 auto checkOp = CheckStructure;
-if (is64Bit()) {
-static_assert(is64Bit() || !(SpecCellCheck & SpecEmpty), "");
+if (SpecCellCheck & SpecEmpty) {
 VirtualRegister local = node->variableAccessData()->local();
 auto* inlineCallFrame = node->origin.semantic.inlineCallFrame;
 if ((local - (inlineCallFrame ? inlineCallFrame->stackOffset : 0)) == virtualRegisterForArgument(0)) {
@@ -195,9 +194,8 @@
 // to emit a node that explicitly handles the empty value. Most of the time, CheckStructureOrEmpty
 // will be folded to CheckStructure because AI proves that the incoming value is
 // definitely not empty.
-static_assert(is64Bit() || !(SpecCellCheck & SpecEmpty), "");
 insertionSet.insertNode(
-indexForChecks, SpecNone, is64Bit() ? CheckStructureOrEmpty : CheckStructure,
+indexForChecks, SpecNone, (SpecCellCheck & SpecEmpty) ? CheckStructureOrEmpty : CheckStructure,
 originForChecks.withSemantic(origin.semantic),
 OpInfo(m_graph.addStructureSet(iter->value.m_structure)),
 Edge(child1.node(), CellUse));






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-12-13 Thread sbarati

Title: [225865] trunk/Source/_javascript_Core








Revision 225865
Author sbar...@apple.com
Date 2017-12-13 12:46:33 -0800 (Wed, 13 Dec 2017)


Log Message
REGRESSION(r225844): Around 850 new JSC failures on 32-bit
https://bugs.webkit.org/show_bug.cgi?id=180764

Unreviewed. We should only emit CheckStructureOrEmpty on 64 bit platforms.

* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::run):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGTypeCheckHoistingPhase.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (225864 => 225865)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-13 20:20:18 UTC (rev 225864)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-13 20:46:33 UTC (rev 225865)
@@ -1,3 +1,13 @@
+2017-12-13  Saam Barati  
+
+REGRESSION(r225844): Around 850 new JSC failures on 32-bit
+https://bugs.webkit.org/show_bug.cgi?id=180764
+
+Unreviewed. We should only emit CheckStructureOrEmpty on 64 bit platforms.
+
+* dfg/DFGTypeCheckHoistingPhase.cpp:
+(JSC::DFG::TypeCheckHoistingPhase::run):
+
 2017-12-13  Michael Saboff  
 
 Unreviewed rollout of r225695. Caused a crash on yahoo login page.


Modified: trunk/Source/_javascript_Core/dfg/DFGTypeCheckHoistingPhase.cpp (225864 => 225865)

--- trunk/Source/_javascript_Core/dfg/DFGTypeCheckHoistingPhase.cpp	2017-12-13 20:20:18 UTC (rev 225864)
+++ trunk/Source/_javascript_Core/dfg/DFGTypeCheckHoistingPhase.cpp	2017-12-13 20:46:33 UTC (rev 225865)
@@ -145,12 +145,15 @@
 OpInfo(variable), Edge(node));
 if (iter->value.m_structure) {
 auto checkOp = CheckStructure;
-VirtualRegister local = node->variableAccessData()->local();
-auto* inlineCallFrame = node->origin.semantic.inlineCallFrame;
-if ((local - (inlineCallFrame ? inlineCallFrame->stackOffset : 0)) == virtualRegisterForArgument(0)) {
-// |this| can be the TDZ value. The call entrypoint won't have |this| as TDZ,
-// but a catch or a loop OSR entry may have |this| be TDZ.
-checkOp = CheckStructureOrEmpty;
+if (is64Bit()) {
+static_assert(is64Bit() || !(SpecCellCheck & SpecEmpty), "");
+VirtualRegister local = node->variableAccessData()->local();
+auto* inlineCallFrame = node->origin.semantic.inlineCallFrame;
+if ((local - (inlineCallFrame ? inlineCallFrame->stackOffset : 0)) == virtualRegisterForArgument(0)) {
+// |this| can be the TDZ value. The call entrypoint won't have |this| as TDZ,
+// but a catch or a loop OSR entry may have |this| be TDZ.
+checkOp = CheckStructureOrEmpty;
+}
 }
 
 insertionSet.insertNode(






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [225845] trunk

2017-12-13 Thread sbarati

Title: [225845] trunk








Revision 225845
Author sbar...@apple.com
Date 2017-12-13 09:29:21 -0800 (Wed, 13 Dec 2017)


Log Message
Fix how JSFunction handles "caller" and "arguments" for functions that don't have those properties
https://bugs.webkit.org/show_bug.cgi?id=163579


Reviewed by Mark Lam.

JSTests:

* stress/caller-and-arguments-properties-for-functions-that-dont-have-them.js: Added.
(assert):
(test1):
(i.test1):
(i.test1.C):
(i.test1.async.foo):
(i.test1.foo):
(test2):

Source/_javascript_Core:

Some functions in _javascript_ do not have the "caller" and "arguments" properties.
For example, strict functions do not. When reading our code that dealt with these
types of functions, it was simply all wrong. We were doing weird things depending
on the method table hook. This patch fixes this by doing what we should've been
doing all along: when the JSFunction does not own the "caller"/"arguments" property,
it should defer to its base class implementation for the various method table hooks.

* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
(JSC::JSFunction::deleteProperty):
(JSC::JSFunction::defineOwnProperty):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/JSFunction.cpp


Added Paths

trunk/JSTests/stress/caller-and-arguments-properties-for-functions-that-dont-have-them.js




Diff

Modified: trunk/JSTests/ChangeLog (225844 => 225845)

--- trunk/JSTests/ChangeLog	2017-12-13 17:19:24 UTC (rev 225844)
+++ trunk/JSTests/ChangeLog	2017-12-13 17:29:21 UTC (rev 225845)
@@ -1,5 +1,22 @@
 2017-12-13  Saam Barati  
 
+Fix how JSFunction handles "caller" and "arguments" for functions that don't have those properties
+https://bugs.webkit.org/show_bug.cgi?id=163579
+
+
+Reviewed by Mark Lam.
+
+* stress/caller-and-arguments-properties-for-functions-that-dont-have-them.js: Added.
+(assert):
+(test1):
+(i.test1):
+(i.test1.C):
+(i.test1.async.foo):
+(i.test1.foo):
+(test2):
+
+2017-12-13  Saam Barati  
+
 TypeCheckHoistingPhase needs to emit a CheckStructureOrEmpty if it's doing it for |this|
 https://bugs.webkit.org/show_bug.cgi?id=180734
 


Added: trunk/JSTests/stress/caller-and-arguments-properties-for-functions-that-dont-have-them.js (0 => 225845)

--- trunk/JSTests/stress/caller-and-arguments-properties-for-functions-that-dont-have-them.js	(rev 0)
+++ trunk/JSTests/stress/caller-and-arguments-properties-for-functions-that-dont-have-them.js	2017-12-13 17:29:21 UTC (rev 225845)
@@ -0,0 +1,74 @@
+function assert(b) {
+if (!b)
+throw new Error;
+}
+
+function test1(f) {
+f.__proto__ = {};
+Object.defineProperty(f, "caller", {value:42});
+assert(f.caller === 42);
+Object.defineProperty(f, "arguments", {value:32});
+assert(f.arguments === 32);
+}
+for (let i = 0; i < 1000; ++i) {
+test1(function () { "use strict"; });
+test1(class C { });
+test1(() => undefined);
+test1(async function foo(){});
+test1(function* foo() { });
+}
+
+function test2(f, p = {}) {
+f.__proto__ = p;
+f.caller = 42;
+assert(f.caller === 42);
+f.arguments = 44;
+assert(f.arguments === 44);
+}
+
+{
+let proxy = new Proxy({}, {
+has(...args) {
+throw new Error("Should not be called!");
+}
+});
+for (let i = 0; i < 1000; ++i) {
+test2(function () { "use strict"; }, proxy);
+test2(class C { }, proxy);
+test2(() => undefined, proxy);
+test2(async function foo(){}, proxy);
+test2(function* foo() { }, proxy);
+}
+}
+
+for (let i = 0; i < 1000; ++i) {
+test2(function () { "use strict"; });
+test2(class C { });
+test2(() => undefined);
+test2(async function foo(){});
+test2(function* foo() { });
+}
+
+function test3(f) {
+f.__proto__ = {};
+f.caller = 42;
+assert(f.caller === 42);
+assert(f.hasOwnProperty("caller"));
+assert(delete f.caller === true);
+assert(f.caller === undefined);
+assert(!f.hasOwnProperty("caller"));
+
+f.arguments = 44;
+assert(f.arguments === 44);
+assert(f.hasOwnProperty("arguments"));
+assert(delete f.arguments === true);
+assert(f.arguments === undefined);
+assert(!f.hasOwnProperty("arguments"));
+}
+for (let i = 0; i < 1000; ++i) {
+test3(function () { "use strict"; });
+test3(class C { });
+test3(() => undefined);
+test3(async function foo(){});
+test3(function* foo() { });
+}


Modified: trunk/Source/_javascript_Core/ChangeLog (225844 => 225845)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-13 17:19:24 UTC (rev 225844)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-13 17:29:21 UTC (rev 225845)
@@ -1,5 +1,25 @@
 2017-12-13  Saam Barati  
 
+Fix how JSFunction handles "caller" and

[webkit-changes] [225844] trunk

2017-12-13 Thread sbarati

Title: [225844] trunk








Revision 225844
Author sbar...@apple.com
Date 2017-12-13 09:19:24 -0800 (Wed, 13 Dec 2017)


Log Message
TypeCheckHoistingPhase needs to emit a CheckStructureOrEmpty if it's doing it for |this|
https://bugs.webkit.org/show_bug.cgi?id=180734


Reviewed by Yusuke Suzuki.

JSTests:

* stress/type-check-hoisting-phase-hoist-check-structure-on-tdz-this-value.js: Added.
(__isPropertyOfType):
(__getProperties):
(__getObjects):
(__getRandomObject):
(theClass.):
(theClass):
(childClass):
(counter.catch):

Source/_javascript_Core:

The |this| value may be TDZ. If type check hoisting phase
hoists a CheckStructure to it, it will crash. This patch
makes it so we emit CheckStructureOrEmpty for |this|.

* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::run):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGTypeCheckHoistingPhase.cpp


Added Paths

trunk/JSTests/stress/type-check-hoisting-phase-hoist-check-structure-on-tdz-this-value.js




Diff

Modified: trunk/JSTests/ChangeLog (225843 => 225844)

--- trunk/JSTests/ChangeLog	2017-12-13 12:39:42 UTC (rev 225843)
+++ trunk/JSTests/ChangeLog	2017-12-13 17:19:24 UTC (rev 225844)
@@ -1,3 +1,21 @@
+2017-12-13  Saam Barati  
+
+TypeCheckHoistingPhase needs to emit a CheckStructureOrEmpty if it's doing it for |this|
+https://bugs.webkit.org/show_bug.cgi?id=180734
+
+
+Reviewed by Yusuke Suzuki.
+
+* stress/type-check-hoisting-phase-hoist-check-structure-on-tdz-this-value.js: Added.
+(__isPropertyOfType):
+(__getProperties):
+(__getObjects):
+(__getRandomObject):
+(theClass.):
+(theClass):
+(childClass):
+(counter.catch):
+
 2017-12-12  Saam Barati  
 
 We need to model effects of Spread(@PhantomCreateRest) in Clobberize/PreciseLocalClobberize


Added: trunk/JSTests/stress/type-check-hoisting-phase-hoist-check-structure-on-tdz-this-value.js (0 => 225844)

--- trunk/JSTests/stress/type-check-hoisting-phase-hoist-check-structure-on-tdz-this-value.js	(rev 0)
+++ trunk/JSTests/stress/type-check-hoisting-phase-hoist-check-structure-on-tdz-this-value.js	2017-12-13 17:19:24 UTC (rev 225844)
@@ -0,0 +1,51 @@
+function __isPropertyOfType(obj, name, type) {
+desc = Object.getOwnPropertyDescriptor(obj, name)
+return typeof type === 'undefined' || typeof desc.value === type;
+}
+function __getProperties(obj, type) {
+let properties = [];
+for (let name of Object.getOwnPropertyNames(obj)) {
+if (__isPropertyOfType(obj, name, type)) properties.push(name);
+}
+let proto = Object.getPrototypeOf(obj);
+while (proto && proto != Object.prototype) {
+Object.getOwnPropertyNames(proto).forEach(name => {
+});
+proto = Object.getPrototypeOf(proto);
+}
+return properties;
+}
+function* __getObjects(root = this, level = 0) {
+if (level > 4) return;
+let obj_names = __getProperties(root, 'object');
+for (let obj_name of obj_names) {
+let obj = root[obj_name];
+yield* __getObjects(obj, level + 1);
+}
+}
+function __getRandomObject() {
+for (let obj of __getObjects()) {
+}
+}
+var theClass = class {
+constructor() {
+if (242487 != null && typeof __getRandomObject() == "object") try {
+} catch (e) {}
+}
+};
+var childClass = class Class extends theClass {
+constructor() {
+var arrow = () => {
+try {
+super();
+} catch (e) {}
+this.idValue
+};
+arrow()()();
+}
+};
+for (var counter = 0; counter < 1000; counter++) {
+try {
+new childClass();
+} catch (e) {}
+}


Modified: trunk/Source/_javascript_Core/ChangeLog (225843 => 225844)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-13 12:39:42 UTC (rev 225843)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-13 17:19:24 UTC (rev 225844)
@@ -1,3 +1,18 @@
+2017-12-13  Saam Barati  
+
+TypeCheckHoistingPhase needs to emit a CheckStructureOrEmpty if it's doing it for |this|
+https://bugs.webkit.org/show_bug.cgi?id=180734
+
+
+Reviewed by Yusuke Suzuki.
+
+The |this| value may be TDZ. If type check hoisting phase
+hoists a CheckStructure to it, it will crash. This patch
+makes it so we emit CheckStructureOrEmpty for |this|.
+
+* dfg/DFGTypeCheckHoistingPhase.cpp:
+(JSC::DFG::TypeCheckHoistingPhase::run):
+
 2017-12-12  Yusuke Suzuki  
 
 [JSC] Optimize Object.assign by single transition acceleration


Modified: trunk/Source/_javascript_Core/dfg/DFGTypeCheckHoistingPhase.cpp (225843 => 225844)

--- trunk/Source/_javascript_Core/dfg/DFGTypeCheckHoistingPhase.cpp	2017-12-13 12:39:42 UTC (rev 225843)
+++

[webkit-changes] [225834] trunk

2017-12-12 Thread sbarati

Title: [225834] trunk








Revision 225834
Author sbar...@apple.com
Date 2017-12-12 19:04:22 -0800 (Tue, 12 Dec 2017)


Log Message
We need to model effects of Spread(@PhantomCreateRest) in Clobberize/PreciseLocalClobberize
https://bugs.webkit.org/show_bug.cgi?id=180725


Reviewed by Michael Saboff.

JSTests:

* stress/model-effects-properly-of-spread-over-phantom-create-rest.js: Added.
(f1):
(f2):
(let.o2.valueOf):

Source/_javascript_Core:

* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGClobberize.h
trunk/Source/_javascript_Core/dfg/DFGPreciseLocalClobberize.h


Added Paths

trunk/JSTests/stress/model-effects-properly-of-spread-over-phantom-create-rest.js




Diff

Modified: trunk/JSTests/ChangeLog (225833 => 225834)

--- trunk/JSTests/ChangeLog	2017-12-13 02:52:43 UTC (rev 225833)
+++ trunk/JSTests/ChangeLog	2017-12-13 03:04:22 UTC (rev 225834)
@@ -1,3 +1,16 @@
+2017-12-12  Saam Barati  
+
+We need to model effects of Spread(@PhantomCreateRest) in Clobberize/PreciseLocalClobberize
+https://bugs.webkit.org/show_bug.cgi?id=180725
+
+
+Reviewed by Michael Saboff.
+
+* stress/model-effects-properly-of-spread-over-phantom-create-rest.js: Added.
+(f1):
+(f2):
+(let.o2.valueOf):
+
 2017-12-12  Yusuke Suzuki  
 
 [JSC] Implement optimized WeakMap and WeakSet


Added: trunk/JSTests/stress/model-effects-properly-of-spread-over-phantom-create-rest.js (0 => 225834)

--- trunk/JSTests/stress/model-effects-properly-of-spread-over-phantom-create-rest.js	(rev 0)
+++ trunk/JSTests/stress/model-effects-properly-of-spread-over-phantom-create-rest.js	2017-12-13 03:04:22 UTC (rev 225834)
@@ -0,0 +1,25 @@
+"use strict";
+function f1(o) {
+let result = [];
+for (let key of Object.getOwnPropertyNames(o)) {
+result.push(key)
+}
+return result;
+}
+function f2(a1, a2, ...args) {
+let r = f1(a1);
+let index = r[a2 % r.length];
+a1[index](...args)
+}
+let theObj = {};
+let o2 = {
+valueOf: function (a, b) {
+a === 42
+b === theObj
+try {} catch (e) {}
+}
+};
+for (let i = 0; i < 1e5; ++i) {
+for (let j = 0; j < 100; j++) {}
+f2(o2, 897989, 42, theObj);
+}


Modified: trunk/Source/_javascript_Core/ChangeLog (225833 => 225834)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-13 02:52:43 UTC (rev 225833)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-13 03:04:22 UTC (rev 225834)
@@ -1,3 +1,16 @@
+2017-12-12  Saam Barati  
+
+We need to model effects of Spread(@PhantomCreateRest) in Clobberize/PreciseLocalClobberize
+https://bugs.webkit.org/show_bug.cgi?id=180725
+
+
+Reviewed by Michael Saboff.
+
+* dfg/DFGClobberize.h:
+(JSC::DFG::clobberize):
+* dfg/DFGPreciseLocalClobberize.h:
+(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
+
 2017-12-12  Yusuke Suzuki  
 
 [JSC] Implement optimized WeakMap and WeakSet


Modified: trunk/Source/_javascript_Core/dfg/DFGClobberize.h (225833 => 225834)

--- trunk/Source/_javascript_Core/dfg/DFGClobberize.h	2017-12-13 02:52:43 UTC (rev 225833)
+++ trunk/Source/_javascript_Core/dfg/DFGClobberize.h	2017-12-13 03:04:22 UTC (rev 225834)
@@ -1312,6 +1312,9 @@
 }
 
 case Spread: {
+if (node->child1()->op() == PhantomCreateRest)
+read(Stack);
+
 if (node->child1().useKind() == ArrayUse) {
 // FIXME: We can probably CSE these together, but we need to construct the right rules
 // to prove that nobody writes to child1() in between two Spreads: https://bugs.webkit.org/show_bug.cgi?id=164531


Modified: trunk/Source/_javascript_Core/dfg/DFGPreciseLocalClobberize.h (225833 => 225834)

--- trunk/Source/_javascript_Core/dfg/DFGPreciseLocalClobberize.h	2017-12-13 02:52:43 UTC (rev 225833)
+++ trunk/Source/_javascript_Core/dfg/DFGPreciseLocalClobberize.h	2017-12-13 03:04:22 UTC (rev 225834)
@@ -120,8 +120,8 @@
 m_read(VirtualRegister(inlineCallFrame->stackOffset + CallFrameSlot::argumentCount));
 };
 
-auto readPhantomSpreadNode = [&] (Node* spread) {
-ASSERT(spread->op() == PhantomSpread);
+auto readSpreadOfPhantomCreateRest = [&] (Node* spread) {
+ASSERT(spread->op() == Spread || spread->op() == PhantomSpread);
 ASSERT(spread->child1()->op() == PhantomCreateRest);
 InlineCallFrame* inlineCallFrame = spread->child1()->origin.semantic.inlineCallFrame;
 unsigned numberOfArgumentsToSkip = spread->child1()->numberOfArgumentsToSkip();
@@ -135,7 +135,7 @@
 if (bitVector->get(i)) {
 Node*

[webkit-changes] [225821] trunk

2017-12-12 Thread sbarati

Title: [225821] trunk








Revision 225821
Author sbar...@apple.com
Date 2017-12-12 16:32:57 -0800 (Tue, 12 Dec 2017)


Log Message
ConstantFoldingPhase rule for GetMyArgumentByVal must check for negative indices
https://bugs.webkit.org/show_bug.cgi?id=180723


Reviewed by JF Bastien.

JSTests:

* stress/get-my-argument-by-val-constant-folding.js: Added.
(test):
(catch):

Source/_javascript_Core:

* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGConstantFoldingPhase.cpp


Added Paths

trunk/JSTests/stress/get-my-argument-by-val-constant-folding.js




Diff

Modified: trunk/JSTests/ChangeLog (225820 => 225821)

--- trunk/JSTests/ChangeLog	2017-12-13 00:31:15 UTC (rev 225820)
+++ trunk/JSTests/ChangeLog	2017-12-13 00:32:57 UTC (rev 225821)
@@ -1,3 +1,15 @@
+2017-12-12  Saam Barati  
+
+ConstantFoldingPhase rule for GetMyArgumentByVal must check for negative indices
+https://bugs.webkit.org/show_bug.cgi?id=180723
+
+
+Reviewed by JF Bastien.
+
+* stress/get-my-argument-by-val-constant-folding.js: Added.
+(test):
+(catch):
+
 2017-12-12  Caio Lima  
 
 [ESNext][BigInt] Implement BigInt literals and JSBigInt


Added: trunk/JSTests/stress/get-my-argument-by-val-constant-folding.js (0 => 225821)

--- trunk/JSTests/stress/get-my-argument-by-val-constant-folding.js	(rev 0)
+++ trunk/JSTests/stress/get-my-argument-by-val-constant-folding.js	2017-12-13 00:32:57 UTC (rev 225821)
@@ -0,0 +1,14 @@
+function test() {
+  for (var i = 0; i < 100; ++i) {
+try {
+  (function () {
+return arguments[-9];
+  })(42);
+} catch (e) {}
+  }
+}
+noInline(test);
+
+try {
+  test(42);
+} catch (e) {}


Modified: trunk/Source/_javascript_Core/ChangeLog (225820 => 225821)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-13 00:31:15 UTC (rev 225820)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-13 00:32:57 UTC (rev 225821)
@@ -1,3 +1,14 @@
+2017-12-12  Saam Barati  
+
+ConstantFoldingPhase rule for GetMyArgumentByVal must check for negative indices
+https://bugs.webkit.org/show_bug.cgi?id=180723
+
+
+Reviewed by JF Bastien.
+
+* dfg/DFGConstantFoldingPhase.cpp:
+(JSC::DFG::ConstantFoldingPhase::foldConstants):
+
 2017-12-04  Brian Burg  
 
 Web Inspector: modernize InjectedScript a bit


Modified: trunk/Source/_javascript_Core/dfg/DFGConstantFoldingPhase.cpp (225820 => 225821)

--- trunk/Source/_javascript_Core/dfg/DFGConstantFoldingPhase.cpp	2017-12-13 00:31:15 UTC (rev 225820)
+++ trunk/Source/_javascript_Core/dfg/DFGConstantFoldingPhase.cpp	2017-12-13 00:32:57 UTC (rev 225821)
@@ -342,11 +342,15 @@
 case GetMyArgumentByVal:
 case GetMyArgumentByValOutOfBounds: {
 JSValue indexValue = m_state.forNode(node->child2()).value();
-if (!indexValue || !indexValue.isInt32())
+if (!indexValue || !indexValue.isUInt32())
 break;
 
-unsigned index = indexValue.asUInt32() + node->numberOfArgumentsToSkip();
+Checked checkedIndex = indexValue.asUInt32();
+checkedIndex += node->numberOfArgumentsToSkip();
+if (checkedIndex.hasOverflowed())
+break;
 
+unsigned index = checkedIndex.unsafeGet();
 Node* arguments = node->child1().node();
 InlineCallFrame* inlineCallFrame = arguments->origin.semantic.inlineCallFrame;
 






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [225768] trunk

2017-12-11 Thread sbarati

Title: [225768] trunk








Revision 225768
Author sbar...@apple.com
Date 2017-12-11 19:24:43 -0800 (Mon, 11 Dec 2017)


Log Message
We need to disableCaching() in ErrorInstance when we materialize properties
https://bugs.webkit.org/show_bug.cgi?id=180343


Reviewed by Mark Lam.

JSTests:

* stress/disable-caching-when-lazy-materializing-error-property-on-put.js: Added.
(assert):
(makeError):
(storeToStack):
(storeToStackAlreadyMaterialized):

Source/_javascript_Core:

This patch fixes a bug in ErrorInstance where we forgot to call PutPropertySlot::disableCaching
on puts() to a property that we lazily materialized. Forgetting to do this goes against the
PutPropertySlot's caching API. This lazy materialization caused the ErrorInstance to transition
from a Structure A to a Structure B. However, we were telling the IC that we were caching an
existing property only found on Structure B. This is obviously wrong as it would lead to an
OOB store if we didn't already crash when generating the IC.

* jit/Repatch.cpp:
(JSC::tryCachePutByID):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::materializeErrorInfoIfNeeded):
(JSC::ErrorInstance::put):
* runtime/ErrorInstance.h:
* runtime/Structure.cpp:
(JSC::Structure::didCachePropertyReplacement):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/jit/Repatch.cpp
trunk/Source/_javascript_Core/runtime/ErrorInstance.cpp
trunk/Source/_javascript_Core/runtime/ErrorInstance.h
trunk/Source/_javascript_Core/runtime/Structure.cpp


Added Paths

trunk/JSTests/stress/disable-caching-when-lazy-materializing-error-property-on-put.js




Diff

Modified: trunk/JSTests/ChangeLog (225767 => 225768)

--- trunk/JSTests/ChangeLog	2017-12-12 02:45:13 UTC (rev 225767)
+++ trunk/JSTests/ChangeLog	2017-12-12 03:24:43 UTC (rev 225768)
@@ -1,3 +1,17 @@
+2017-12-11  Saam Barati  
+
+We need to disableCaching() in ErrorInstance when we materialize properties
+https://bugs.webkit.org/show_bug.cgi?id=180343
+
+
+Reviewed by Mark Lam.
+
+* stress/disable-caching-when-lazy-materializing-error-property-on-put.js: Added.
+(assert):
+(makeError):
+(storeToStack):
+(storeToStackAlreadyMaterialized):
+
 2017-12-05  JF Bastien  
 
 WebAssembly: don't eagerly checksum


Added: trunk/JSTests/stress/disable-caching-when-lazy-materializing-error-property-on-put.js (0 => 225768)

--- trunk/JSTests/stress/disable-caching-when-lazy-materializing-error-property-on-put.js	(rev 0)
+++ trunk/JSTests/stress/disable-caching-when-lazy-materializing-error-property-on-put.js	2017-12-12 03:24:43 UTC (rev 225768)
@@ -0,0 +1,27 @@
+function assert(b) {
+if (!b)
+throw new Error;
+}
+
+function makeError() { return new Error; }
+noInline(makeError);
+
+function storeToStack(e) {
+e.stack = "foo";
+}
+noInline(storeToStack);
+
+function storeToStackAlreadyMaterialized(e) {
+e.stack = "bar";
+}
+noInline(storeToStackAlreadyMaterialized);
+
+for (let i = 0; i < 1; ++i) {
+let e = makeError();
+storeToStack(e);
+assert(e.stack === "foo");
+if (!!(i % 2))
+e.fooBar = 25;
+storeToStackAlreadyMaterialized(e);
+assert(e.stack === "bar");
+}


Modified: trunk/Source/_javascript_Core/ChangeLog (225767 => 225768)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-12 02:45:13 UTC (rev 225767)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-12 03:24:43 UTC (rev 225768)
@@ -1,3 +1,27 @@
+2017-12-11  Saam Barati  
+
+We need to disableCaching() in ErrorInstance when we materialize properties
+https://bugs.webkit.org/show_bug.cgi?id=180343
+
+
+Reviewed by Mark Lam.
+
+This patch fixes a bug in ErrorInstance where we forgot to call PutPropertySlot::disableCaching
+on puts() to a property that we lazily materialized. Forgetting to do this goes against the
+PutPropertySlot's caching API. This lazy materialization caused the ErrorInstance to transition
+from a Structure A to a Structure B. However, we were telling the IC that we were caching an
+existing property only found on Structure B. This is obviously wrong as it would lead to an
+OOB store if we didn't already crash when generating the IC.
+
+* jit/Repatch.cpp:
+(JSC::tryCachePutByID):
+* runtime/ErrorInstance.cpp:
+(JSC::ErrorInstance::materializeErrorInfoIfNeeded):
+(JSC::ErrorInstance::put):
+* runtime/ErrorInstance.h:
+* runtime/Structure.cpp:
+(JSC::Structure::didCachePropertyReplacement):
+
 2017-12-11  Fujii Hironori  
 
 [WinCairo] DLLLauncherMain should use SetDllDirectory


Modified: trunk/Source/_javascript_Core/jit/Repatch.cpp (225767 => 225768)

--- trunk/Source/_javascript_Core/jit/Repatch.cpp	2017-12-12 02:45:13 UTC

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

2017-12-08 Thread sbarati

Title: [225701] trunk/Source/bmalloc








Revision 225701
Author sbar...@apple.com
Date 2017-12-08 14:28:31 -0800 (Fri, 08 Dec 2017)


Log Message
Enable gigacage on iOS with a 32GB runway and ensure it doesn't break WasmBench
https://bugs.webkit.org/show_bug.cgi?id=178557

Reviewed by Mark Lam.

* bmalloc/Algorithm.h:
(bmalloc::isPowerOfTwo):
* bmalloc/Gigacage.cpp:
* bmalloc/Gigacage.h:

Modified Paths

trunk/Source/bmalloc/ChangeLog
trunk/Source/bmalloc/bmalloc/Algorithm.h
trunk/Source/bmalloc/bmalloc/Gigacage.cpp
trunk/Source/bmalloc/bmalloc/Gigacage.h




Diff

Modified: trunk/Source/bmalloc/ChangeLog (225700 => 225701)

--- trunk/Source/bmalloc/ChangeLog	2017-12-08 22:23:22 UTC (rev 225700)
+++ trunk/Source/bmalloc/ChangeLog	2017-12-08 22:28:31 UTC (rev 225701)
@@ -1,3 +1,15 @@
+2017-12-08  Saam Barati  
+
+Enable gigacage on iOS with a 32GB runway and ensure it doesn't break WasmBench
+https://bugs.webkit.org/show_bug.cgi?id=178557
+
+Reviewed by Mark Lam.
+
+* bmalloc/Algorithm.h:
+(bmalloc::isPowerOfTwo):
+* bmalloc/Gigacage.cpp:
+* bmalloc/Gigacage.h:
+
 2017-12-05  Andy Estes  
 
 [Darwin] Simplify use of TargetConditionals


Modified: trunk/Source/bmalloc/bmalloc/Algorithm.h (225700 => 225701)

--- trunk/Source/bmalloc/bmalloc/Algorithm.h	2017-12-08 22:23:22 UTC (rev 225700)
+++ trunk/Source/bmalloc/bmalloc/Algorithm.h	2017-12-08 22:28:31 UTC (rev 225701)
@@ -63,8 +63,10 @@
 return !!(reinterpret_cast(value) & mask);
 }
 
-inline constexpr bool isPowerOfTwo(size_t size)
+template 
+inline constexpr bool isPowerOfTwo(T size)
 {
+static_assert(std::is_integral::value, "");
 return size && !(size & (size - 1));
 }
 


Modified: trunk/Source/bmalloc/bmalloc/Gigacage.cpp (225700 => 225701)

--- trunk/Source/bmalloc/bmalloc/Gigacage.cpp	2017-12-08 22:23:22 UTC (rev 225700)
+++ trunk/Source/bmalloc/bmalloc/Gigacage.cpp	2017-12-08 22:28:31 UTC (rev 225701)
@@ -34,13 +34,12 @@
 #include 
 #include 
 
-#if BCPU(ARM64)
-// FIXME: There is no good reason for ARM64 to be special.
-// https://bugs.webkit.org/show_bug.cgi?id=177605
-#define GIGACAGE_RUNWAY 0
-#else
+// This is exactly 32GB because inside JSC, indexed accesses for arrays, typed arrays, etc,
+// use unsigned 32-bit ints as indices. The items those indices access are 8 bytes or less
+// in size. 2^32 * 8 = 32GB. This means if an access on a caged type happens to go out of
+// bounds, the access is guaranteed to land somewhere else in the cage or inside the runway.
+// If this were less than 32GB, those OOB accesses could reach outside of the cage.
 #define GIGACAGE_RUNWAY (32llu * 1024 * 1024 * 1024)
-#endif
 
 char g_gigacageBasePtrs[GIGACAGE_BASE_PTRS_SIZE] __attribute__((aligned(GIGACAGE_BASE_PTRS_SIZE)));
 


Modified: trunk/Source/bmalloc/bmalloc/Gigacage.h (225700 => 225701)

--- trunk/Source/bmalloc/bmalloc/Gigacage.h	2017-12-08 22:23:22 UTC (rev 225700)
+++ trunk/Source/bmalloc/bmalloc/Gigacage.h	2017-12-08 22:28:31 UTC (rev 225701)
@@ -25,6 +25,7 @@
 
 #pragma once
 
+#include "Algorithm.h"
 #include "BAssert.h"
 #include "BExport.h"
 #include "BInline.h"
@@ -33,9 +34,7 @@
 #include 
 
 #if BCPU(ARM64)
-// FIXME: This can probably be a lot bigger on iOS. I just haven't tried to make it bigger yet.
-// https://bugs.webkit.org/show_bug.cgi?id=177605
-#define PRIMITIVE_GIGACAGE_SIZE 0x4000llu
+#define PRIMITIVE_GIGACAGE_SIZE 0x8000llu
 #define JSVALUE_GIGACAGE_SIZE 0x4000llu
 #define STRING_GIGACAGE_SIZE 0x4000llu
 #define GIGACAGE_ALLOCATION_CAN_FAIL 1
@@ -46,6 +45,10 @@
 #define GIGACAGE_ALLOCATION_CAN_FAIL 0
 #endif
 
+static_assert(bmalloc::isPowerOfTwo(PRIMITIVE_GIGACAGE_SIZE), "");
+static_assert(bmalloc::isPowerOfTwo(JSVALUE_GIGACAGE_SIZE), "");
+static_assert(bmalloc::isPowerOfTwo(STRING_GIGACAGE_SIZE), "");
+
 #define GIGACAGE_SIZE_TO_MASK(size) ((size) - 1)
 
 #define PRIMITIVE_GIGACAGE_MASK GIGACAGE_SIZE_TO_MASK(PRIMITIVE_GIGACAGE_SIZE)
@@ -52,9 +55,8 @@
 #define JSVALUE_GIGACAGE_MASK GIGACAGE_SIZE_TO_MASK(JSVALUE_GIGACAGE_SIZE)
 #define STRING_GIGACAGE_MASK GIGACAGE_SIZE_TO_MASK(STRING_GIGACAGE_SIZE)
 
-// FIXME: Make WasmBench run with gigacage on iOS and re-enable on ARM64:
-// https://bugs.webkit.org/show_bug.cgi?id=178557
-#if (BOS(DARWIN) || BOS(LINUX)) && (/* (BCPU(ARM64) && !defined(__ILP32__))  || */ BCPU(X86_64))
+#if ((BOS(DARWIN) || BOS(LINUX)) && \
+(BCPU(X86_64) || (BCPU(ARM64) && !defined(__ILP32__) && (!BPLATFORM(IOS) || __IPHONE_OS_VERSION_MIN_REQUIRED >= 110300
 #define GIGACAGE_ENABLED 1
 #else
 #define GIGACAGE_ENABLED 0






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-12-07 Thread sbarati

Title: [225664] trunk/Source/_javascript_Core








Revision 225664
Author sbar...@apple.com
Date 2017-12-07 18:08:03 -0800 (Thu, 07 Dec 2017)


Log Message
Modify our dollar VM clflush intrinsic to aid in some perf testing
https://bugs.webkit.org/show_bug.cgi?id=180559

Reviewed by Mark Lam.

* tools/JSDollarVM.cpp:
(JSC::functionCpuClflush):
(JSC::functionDeltaBetweenButterflies):
(JSC::JSDollarVM::finishCreation):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/tools/JSDollarVM.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (225663 => 225664)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-08 01:53:31 UTC (rev 225663)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-08 02:08:03 UTC (rev 225664)
@@ -1,3 +1,15 @@
+2017-12-07  Saam Barati  
+
+Modify our dollar VM clflush intrinsic to aid in some perf testing
+https://bugs.webkit.org/show_bug.cgi?id=180559
+
+Reviewed by Mark Lam.
+
+* tools/JSDollarVM.cpp:
+(JSC::functionCpuClflush):
+(JSC::functionDeltaBetweenButterflies):
+(JSC::JSDollarVM::finishCreation):
+
 2017-12-07  Eric Carlson  
 
 Simplify log channel configuration UI


Modified: trunk/Source/_javascript_Core/tools/JSDollarVM.cpp (225663 => 225664)

--- trunk/Source/_javascript_Core/tools/JSDollarVM.cpp	2017-12-08 01:53:31 UTC (rev 225663)
+++ trunk/Source/_javascript_Core/tools/JSDollarVM.cpp	2017-12-08 02:08:03 UTC (rev 225664)
@@ -1107,32 +1107,28 @@
 asm volatile ("clflush %0" :: "m"(*ptrToFlush) : "memory");
 };
 
+Vector toFlush;
+
 uint32_t offset = exec->argument(1).asUInt32();
 
-char* ptr = nullptr;
-if (JSArrayBuffer* buffer = jsDynamicCast(vm, exec->argument(0))) {
-if (ArrayBuffer* impl = buffer->impl()) {
-if (offset < impl->byteLength()) {
-clflush(impl);
-ptr = bitwise_cast(impl) + offset;
-}
-}
-} else if (JSArrayBufferView* view = jsDynamicCast(vm, exec->argument(0)))
-ptr = bitwise_cast(view);
+if (JSArrayBufferView* view = jsDynamicCast(vm, exec->argument(0)))
+toFlush.append(bitwise_cast(view->vector()) + offset);
 else if (JSObject* object = jsDynamicCast(vm, exec->argument(0))) {
 switch (object->indexingType()) {
 case ALL_INT32_INDEXING_TYPES:
 case ALL_CONTIGUOUS_INDEXING_TYPES:
 case ALL_DOUBLE_INDEXING_TYPES:
-clflush(object);
-ptr = bitwise_cast(object->butterfly()) + offset;
+toFlush.append(bitwise_cast(object) + JSObject::butterflyOffset());
+toFlush.append(bitwise_cast(object->butterfly()) + Butterfly::offsetOfVectorLength());
+toFlush.append(bitwise_cast(object->butterfly()) + Butterfly::offsetOfPublicLength());
 }
 }
 
-if (!ptr)
+if (!toFlush.size())
 return JSValue::encode(jsBoolean(false));
 
-clflush(ptr);
+for (void* ptr : toFlush)
+clflush(ptr);
 return JSValue::encode(jsBoolean(true));
 #else
 UNUSED_PARAM(exec);
@@ -1698,6 +1694,22 @@
 return JSValue::encode(JSTestCustomGetterSetter::create(vm, globalObject, JSTestCustomGetterSetter::createStructure(vm, globalObject)));
 }
 
+static EncodedJSValue JSC_HOST_CALL functionDeltaBetweenButterflies(ExecState* exec)
+{
+VM& vm = exec->vm();
+JSObject* a = jsDynamicCast(vm, exec->argument(0));
+JSObject* b = jsDynamicCast(vm, exec->argument(1));
+if (!a || !b)
+return JSValue::encode(jsNumber(PNaN));
+
+ptrdiff_t delta = bitwise_cast(a->butterfly()) - bitwise_cast(b->butterfly());
+if (delta < 0)
+return JSValue::encode(jsNumber(PNaN));
+if (delta > std::numeric_limits::max())
+return JSValue::encode(jsNumber(PNaN));
+return JSValue::encode(jsNumber(static_cast(delta)));
+}
+
 void JSDollarVM::finishCreation(VM& vm)
 {
 Base::finishCreation(vm);
@@ -1779,6 +1791,8 @@
 addFunction(vm, "getGetterSetter", functionGetGetterSetter, 2);
 addFunction(vm, "loadGetterFromGetterSetter", functionLoadGetterFromGetterSetter, 1);
 addFunction(vm, "createCustomTestGetterSetter", functionCreateCustomTestGetterSetter, 1);
+
+addFunction(vm, "deltaBetweenButterflies", functionDeltaBetweenButterflies, 2);
 }
 
 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] [225658] trunk/Source/WebKit

2017-12-07 Thread sbarati

Title: [225658] trunk/Source/WebKit








Revision 225658
Author sbar...@apple.com
Date 2017-12-07 17:12:18 -0800 (Thu, 07 Dec 2017)


Log Message
We need to grab the JSLock in InjectedBundle::createWebDataFromUint8Array
https://bugs.webkit.org/show_bug.cgi?id=180492

Reviewed by Alex Christensen.

InjectedBundle::createWebDataFromUint8Array calls into WebCore APIs that allocate
out of the JS heap. It's only legal to allocate out of the JS heap when holding the JS lock.

* WebProcess/InjectedBundle/InjectedBundle.cpp:
(WebKit::InjectedBundle::createWebDataFromUint8Array):

Modified Paths

trunk/Source/WebKit/ChangeLog
trunk/Source/WebKit/WebProcess/InjectedBundle/InjectedBundle.cpp




Diff

Modified: trunk/Source/WebKit/ChangeLog (225657 => 225658)

--- trunk/Source/WebKit/ChangeLog	2017-12-08 00:59:02 UTC (rev 225657)
+++ trunk/Source/WebKit/ChangeLog	2017-12-08 01:12:18 UTC (rev 225658)
@@ -1,3 +1,16 @@
+2017-12-07  Saam Barati  
+
+We need to grab the JSLock in InjectedBundle::createWebDataFromUint8Array
+https://bugs.webkit.org/show_bug.cgi?id=180492
+
+Reviewed by Alex Christensen.
+
+InjectedBundle::createWebDataFromUint8Array calls into WebCore APIs that allocate
+out of the JS heap. It's only legal to allocate out of the JS heap when holding the JS lock.
+
+* WebProcess/InjectedBundle/InjectedBundle.cpp:
+(WebKit::InjectedBundle::createWebDataFromUint8Array):
+
 2017-12-07  Simon Fraser  
 
 Propagate WebKit2Logging channels to the Web Process


Modified: trunk/Source/WebKit/WebProcess/InjectedBundle/InjectedBundle.cpp (225657 => 225658)

--- trunk/Source/WebKit/WebProcess/InjectedBundle/InjectedBundle.cpp	2017-12-08 00:59:02 UTC (rev 225657)
+++ trunk/Source/WebKit/WebProcess/InjectedBundle/InjectedBundle.cpp	2017-12-08 01:12:18 UTC (rev 225658)
@@ -581,6 +581,7 @@
 Ref InjectedBundle::createWebDataFromUint8Array(JSContextRef context, JSValueRef data)
 {
 JSC::ExecState* execState = toJS(context);
+JSLockHolder lock(execState);
 RefPtr arrayData = WebCore::toUnsharedUint8Array(execState->vm(), toJS(execState, data));
 return API::Data::create(static_cast(arrayData->baseAddress()), arrayData->byteLength());
 }






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-12-06 Thread sbarati

Title: [225621] trunk/Source/WebCore








Revision 225621
Author sbar...@apple.com
Date 2017-12-06 22:47:16 -0800 (Wed, 06 Dec 2017)


Log Message
Unreviewed. Fix iOS (and maybe other platform) build

* workers/service/server/RegistrationDatabase.cpp:
(WebCore::RegistrationDatabase::openSQLiteDatabase):

Modified Paths

trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/workers/service/server/RegistrationDatabase.cpp




Diff

Modified: trunk/Source/WebCore/ChangeLog (225620 => 225621)

--- trunk/Source/WebCore/ChangeLog	2017-12-07 06:10:06 UTC (rev 225620)
+++ trunk/Source/WebCore/ChangeLog	2017-12-07 06:47:16 UTC (rev 225621)
@@ -1,3 +1,10 @@
+2017-12-06  Saam Barati  
+
+Unreviewed. Fix iOS (and maybe other platform) build
+
+* workers/service/server/RegistrationDatabase.cpp:
+(WebCore::RegistrationDatabase::openSQLiteDatabase):
+
 2017-12-02  Darin Adler  
 
 Modernize some aspects of text codecs, eliminate WebKit use of strcasecmp


Modified: trunk/Source/WebCore/workers/service/server/RegistrationDatabase.cpp (225620 => 225621)

--- trunk/Source/WebCore/workers/service/server/RegistrationDatabase.cpp	2017-12-07 06:10:06 UTC (rev 225620)
+++ trunk/Source/WebCore/workers/service/server/RegistrationDatabase.cpp	2017-12-07 06:47:16 UTC (rev 225621)
@@ -88,7 +88,7 @@
 
 String errorMessage;
 auto scopeExit = makeScopeExit([&, errorMessage = ] {
-ASSERT(!errorMessage->isNull());
+ASSERT_UNUSED(errorMessage, !errorMessage->isNull());
 LOG_ERROR("Failed to open Service Worker registration database: %s", errorMessage->utf8().data());
 m_database = nullptr;
 postTaskReply(createCrossThreadTask(*this, ::databaseFailedToOpen));






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-12-06 Thread sbarati

Title: [225579] trunk/Source/_javascript_Core








Revision 225579
Author sbar...@apple.com
Date 2017-12-06 10:58:00 -0800 (Wed, 06 Dec 2017)


Log Message
ASSERTION FAILED: vm->currentThreadIsHoldingAPILock() in void JSC::sanitizeStackForVM(JSC::VM *)
https://bugs.webkit.org/show_bug.cgi?id=180438


Reviewed by Yusuke Suzuki.

A couple inspector methods that take stacktraces need
to grab the JSLock.

* inspector/ScriptCallStackFactory.cpp:
(Inspector::createScriptCallStack):
(Inspector::createScriptCallStackForConsole):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/inspector/ScriptCallStackFactory.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (225578 => 225579)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-06 18:55:49 UTC (rev 225578)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-06 18:58:00 UTC (rev 225579)
@@ -1,3 +1,18 @@
+2017-12-06  Saam Barati  
+
+ASSERTION FAILED: vm->currentThreadIsHoldingAPILock() in void JSC::sanitizeStackForVM(JSC::VM *)
+https://bugs.webkit.org/show_bug.cgi?id=180438
+
+
+Reviewed by Yusuke Suzuki.
+
+A couple inspector methods that take stacktraces need
+to grab the JSLock.
+
+* inspector/ScriptCallStackFactory.cpp:
+(Inspector::createScriptCallStack):
+(Inspector::createScriptCallStackForConsole):
+
 2017-12-05  Stephan Szabo  
 
 Switch windows build to Visual Studio 2017


Modified: trunk/Source/_javascript_Core/inspector/ScriptCallStackFactory.cpp (225578 => 225579)

--- trunk/Source/_javascript_Core/inspector/ScriptCallStackFactory.cpp	2017-12-06 18:55:49 UTC (rev 225578)
+++ trunk/Source/_javascript_Core/inspector/ScriptCallStackFactory.cpp	2017-12-06 18:58:00 UTC (rev 225579)
@@ -89,6 +89,7 @@
 if (!exec)
 return ScriptCallStack::create();
 
+JSLockHolder locker(exec);
 Vector frames;
 
 CallFrame* frame = exec->vm().topCallFrame;
@@ -103,6 +104,7 @@
 if (!exec)
 return ScriptCallStack::create();
 
+JSLockHolder locker(exec);
 Vector frames;
 
 CallFrame* frame = exec->vm().topCallFrame;






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [225492] trunk

2017-12-04 Thread sbarati

Title: [225492] trunk








Revision 225492
Author sbar...@apple.com
Date 2017-12-04 14:00:24 -0800 (Mon, 04 Dec 2017)


Log Message
We need to leave room on the top of the stack for the FTL TailCall slow path so it doesn't overwrite things we want to retrieve when doing a stack walk when throwing an exception
https://bugs.webkit.org/show_bug.cgi?id=180366


Reviewed by Michael Saboff.

JSTests:

* stress/ftl-tail-call-throw-exception-from-slow-path-recover-stack-values.js: Added.
(theParent):
(test1.base.getParentStaticValue):
(test1.base):
(test1.__v_24888.prototype.set prop):
(test1.__v_24888):
(test2.base.getParentStaticValue):
(test2.base):
(test2.__v_24888.prototype.set prop):
(test2.__v_24888):
(test2):

Source/_javascript_Core:

On the TailCall slow path, the CallFrameShuffler will build the frame with
respect to SP instead of FP. However, this may overwrite slots on the stack
that are needed if the slow path C call does a stack walk. The slow path
C call does a stack walk when it throws an exception. This patch fixes
this bug by ensuring that the top of the stack in the FTL always has enough
space to allow CallFrameShuffler to build a frame without overwriting any
items on the stack that are needed when doing a stack walk.

* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileTailCall):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp


Added Paths

trunk/JSTests/stress/ftl-tail-call-throw-exception-from-slow-path-recover-stack-values.js




Diff

Modified: trunk/JSTests/ChangeLog (225491 => 225492)

--- trunk/JSTests/ChangeLog	2017-12-04 21:56:25 UTC (rev 225491)
+++ trunk/JSTests/ChangeLog	2017-12-04 22:00:24 UTC (rev 225492)
@@ -1,3 +1,23 @@
+2017-12-04  Saam Barati  
+
+We need to leave room on the top of the stack for the FTL TailCall slow path so it doesn't overwrite things we want to retrieve when doing a stack walk when throwing an exception
+https://bugs.webkit.org/show_bug.cgi?id=180366
+
+
+Reviewed by Michael Saboff.
+
+* stress/ftl-tail-call-throw-exception-from-slow-path-recover-stack-values.js: Added.
+(theParent):
+(test1.base.getParentStaticValue):
+(test1.base):
+(test1.__v_24888.prototype.set prop):
+(test1.__v_24888):
+(test2.base.getParentStaticValue):
+(test2.base):
+(test2.__v_24888.prototype.set prop):
+(test2.__v_24888):
+(test2):
+
 2017-12-01  JF Bastien  
 
 Try proxying all function arguments


Added: trunk/JSTests/stress/ftl-tail-call-throw-exception-from-slow-path-recover-stack-values.js (0 => 225492)

--- trunk/JSTests/stress/ftl-tail-call-throw-exception-from-slow-path-recover-stack-values.js	(rev 0)
+++ trunk/JSTests/stress/ftl-tail-call-throw-exception-from-slow-path-recover-stack-values.js	2017-12-04 22:00:24 UTC (rev 225492)
@@ -0,0 +1,31 @@
+var theParent = function () { };
+
+function test1() {
+var base = class C extends theParent {
+static getParentStaticValue() {
+let arrow = (a,b,c) => super.getStaticValue(a,b,c);
+return arrow(1,1,1);
+}
+};
+
+for (let i = 0; i < 1; i++) {
+try { base.getParentStaticValue()  } catch (e) {}
+try { base.getParentStaticValue()  } catch (e) {}
+}
+}
+test1();
+
+function test2() {
+var base = class C extends theParent {
+static getParentStaticValue() {
+let arrow = () => super.getStaticValue();
+return arrow();
+}
+};
+
+for (let i = 0; i < 1; i++) {
+try { base.getParentStaticValue()  } catch (e) {}
+try { base.getParentStaticValue()  } catch (e) {}
+}
+}
+test2();


Modified: trunk/Source/_javascript_Core/ChangeLog (225491 => 225492)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-04 21:56:25 UTC (rev 225491)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-04 22:00:24 UTC (rev 225492)
@@ -1,3 +1,22 @@
+2017-12-04  Saam Barati  
+
+We need to leave room on the top of the stack for the FTL TailCall slow path so it doesn't overwrite things we want to retrieve when doing a stack walk when throwing an exception
+https://bugs.webkit.org/show_bug.cgi?id=180366
+
+
+Reviewed by Michael Saboff.
+
+On the TailCall slow path, the CallFrameShuffler will build the frame with
+respect to SP instead of FP. However, this may overwrite slots on the stack
+that are needed if the slow path C call does a stack walk. The slow path
+C call does a stack walk when it throws an exception. This patch fixes
+this bug by ensuring that the top of the stack in the FTL always has enough
+space to allow CallFrameShuffler to build a frame without overwriting any
+items on the stack that are needed when

[webkit-changes] [225423] trunk

2017-12-01 Thread sbarati

Title: [225423] trunk








Revision 225423
Author sbar...@apple.com
Date 2017-12-01 15:40:13 -0800 (Fri, 01 Dec 2017)


Log Message
Having a bad time needs to handle ArrayClass indexing type as well
https://bugs.webkit.org/show_bug.cgi?id=180274


Reviewed by Keith Miller and Mark Lam.

JSTests:

* stress/array-prototype-slow-put-having-a-bad-time-2.js: Added.
(assert):
* stress/array-prototype-slow-put-having-a-bad-time.js: Added.
(assert):

Source/_javascript_Core:

We need to make sure to transition ArrayClass to SlowPutArrayStorage as well.
Otherwise, we'll end up with the wrong Structure, which will lead us to not
adhere to the spec. The bug was that we were not considering ArrayClass inside
hasBrokenIndexing. This patch rewrites that function to automatically opt
in non-empty indexing types as broken, instead of having to opt out all
non-empty indexing types besides SlowPutArrayStorage.

* runtime/IndexingType.h:
(JSC::hasSlowPutArrayStorage):
(JSC::shouldUseSlowPut):
* runtime/JSGlobalObject.cpp:
* runtime/JSObject.cpp:
(JSC::JSObject::switchToSlowPutArrayStorage):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/IndexingType.h
trunk/Source/_javascript_Core/runtime/JSGlobalObject.cpp
trunk/Source/_javascript_Core/runtime/JSObject.cpp


Added Paths

trunk/JSTests/stress/array-prototype-slow-put-having-a-bad-time-2.js
trunk/JSTests/stress/array-prototype-slow-put-having-a-bad-time.js




Diff

Modified: trunk/JSTests/ChangeLog (225422 => 225423)

--- trunk/JSTests/ChangeLog	2017-12-01 23:36:41 UTC (rev 225422)
+++ trunk/JSTests/ChangeLog	2017-12-01 23:40:13 UTC (rev 225423)
@@ -1,3 +1,16 @@
+2017-12-01  Saam Barati  
+
+Having a bad time needs to handle ArrayClass indexing type as well
+https://bugs.webkit.org/show_bug.cgi?id=180274
+
+
+Reviewed by Keith Miller and Mark Lam.
+
+* stress/array-prototype-slow-put-having-a-bad-time-2.js: Added.
+(assert):
+* stress/array-prototype-slow-put-having-a-bad-time.js: Added.
+(assert):
+
 2017-12-01  JF Bastien  
 
 WebAssembly: restore cached stack limit after out-call


Added: trunk/JSTests/stress/array-prototype-slow-put-having-a-bad-time-2.js (0 => 225423)

--- trunk/JSTests/stress/array-prototype-slow-put-having-a-bad-time-2.js	(rev 0)
+++ trunk/JSTests/stress/array-prototype-slow-put-having-a-bad-time-2.js	2017-12-01 23:40:13 UTC (rev 225423)
@@ -0,0 +1,14 @@
+function assert(b) {
+if (!b)
+throw new Error;
+}
+
+let result;
+Object.defineProperty(Object.prototype, '1', {
+get() { return result; },
+set(x) { result = x; }
+});
+Array.prototype.length = 0x1000;
+Array.prototype[1] = 42;
+assert(result === 42);
+assert(Array.prototype[1] === 42);


Added: trunk/JSTests/stress/array-prototype-slow-put-having-a-bad-time.js (0 => 225423)

--- trunk/JSTests/stress/array-prototype-slow-put-having-a-bad-time.js	(rev 0)
+++ trunk/JSTests/stress/array-prototype-slow-put-having-a-bad-time.js	2017-12-01 23:40:13 UTC (rev 225423)
@@ -0,0 +1,15 @@
+function assert(b) {
+if (!b)
+throw new Error;
+}
+
+let result;
+Object.defineProperty(Object.prototype, '1', {
+get() { return result; },
+set(x) { result = x; }
+});
+
+Array.prototype.length = 5;
+Array.prototype[1] = 42;
+assert(result === 42);
+assert(Array.prototype[1] === 42);


Modified: trunk/Source/_javascript_Core/ChangeLog (225422 => 225423)

--- trunk/Source/_javascript_Core/ChangeLog	2017-12-01 23:36:41 UTC (rev 225422)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-12-01 23:40:13 UTC (rev 225423)
@@ -1,3 +1,25 @@
+2017-12-01  Saam Barati  
+
+Having a bad time needs to handle ArrayClass indexing type as well
+https://bugs.webkit.org/show_bug.cgi?id=180274
+
+
+Reviewed by Keith Miller and Mark Lam.
+
+We need to make sure to transition ArrayClass to SlowPutArrayStorage as well.
+Otherwise, we'll end up with the wrong Structure, which will lead us to not
+adhere to the spec. The bug was that we were not considering ArrayClass inside 
+hasBrokenIndexing. This patch rewrites that function to automatically opt
+in non-empty indexing types as broken, instead of having to opt out all
+non-empty indexing types besides SlowPutArrayStorage.
+
+* runtime/IndexingType.h:
+(JSC::hasSlowPutArrayStorage):
+(JSC::shouldUseSlowPut):
+* runtime/JSGlobalObject.cpp:
+* runtime/JSObject.cpp:
+(JSC::JSObject::switchToSlowPutArrayStorage):
+
 2017-12-01  JF Bastien  
 
 WebAssembly: stack trace improvement follow-ups


Modified: trunk/Source/_javascript_Core/runtime/IndexingType.h (225422 => 225423)

--- trunk/Source/_javascript_Core/runtime/IndexingType.h	2017-12-01 23:36:41 UTC

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

2017-11-29 Thread sbarati

Title: [225307] trunk/Source/_javascript_Core








Revision 225307
Author sbar...@apple.com
Date 2017-11-29 17:05:01 -0800 (Wed, 29 Nov 2017)


Log Message
Remove pointer caging for double arrays
https://bugs.webkit.org/show_bug.cgi?id=180163

Reviewed by Mark Lam.

This patch removes pointer caging from double arrays. Like
my previous removals of pointer caging, this is a security vs
performance tradeoff. We believe that butterflies being allocated
in the cage and with a 32GB runway gives us enough security that
pointer caging the butterfly just for double arrays does not add
enough security benefit for the performance hit it incurs.

This patch also removes the GetButterflyWithoutCaging node and
the FixedButterflyAccessUncaging phase. The node is no longer needed
because now all GetButterfly nodes are not caged. The phase is removed
since we no longer have two nodes.

* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixedButterflyAccessUncagingPhase.cpp: Removed.
* dfg/DFGFixedButterflyAccessUncagingPhase.h: Removed.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGNodeType.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileSpread):
(JSC::DFG::SpeculativeJIT::compileArraySlice):
(JSC::DFG::SpeculativeJIT::compileGetButterfly):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileGetButterfly):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitDoubleLoad):
(JSC::JIT::emitGenericContiguousPutByVal):
* runtime/Butterfly.h:
(JSC::Butterfly::pointer):
(JSC::Butterfly::contiguousDouble):
(JSC::Butterfly::caged): Deleted.
* runtime/ButterflyInlines.h:
(JSC::Butterfly::createOrGrowPropertyStorage):
* runtime/JSObject.cpp:
(JSC::JSObject::ensureLengthSlow):
(JSC::JSObject::reallocateAndShrinkButterfly):

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/dfg/DFGAbstractInterpreterInlines.h
trunk/Source/_javascript_Core/dfg/DFGArgumentsEliminationPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGClobberize.h
trunk/Source/_javascript_Core/dfg/DFGDoesGC.cpp
trunk/Source/_javascript_Core/dfg/DFGFixupPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGHeapLocation.cpp
trunk/Source/_javascript_Core/dfg/DFGHeapLocation.h
trunk/Source/_javascript_Core/dfg/DFGNodeType.h
trunk/Source/_javascript_Core/dfg/DFGPlan.cpp
trunk/Source/_javascript_Core/dfg/DFGPredictionPropagationPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGSafeToExecute.h
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT32_64.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp
trunk/Source/_javascript_Core/dfg/DFGTypeCheckHoistingPhase.cpp
trunk/Source/_javascript_Core/ftl/FTLCapabilities.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
trunk/Source/_javascript_Core/jit/JITPropertyAccess.cpp
trunk/Source/_javascript_Core/runtime/Butterfly.h
trunk/Source/_javascript_Core/runtime/ButterflyInlines.h
trunk/Source/_javascript_Core/runtime/JSObject.cpp


Removed Paths

trunk/Source/_javascript_Core/dfg/DFGFixedButterflyAccessUncagingPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGFixedButterflyAccessUncagingPhase.h




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (225306 => 225307)

--- trunk/Source/_javascript_Core/ChangeLog	2017-11-30 00:39:14 UTC (rev 225306)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-11-30 01:05:01 UTC (rev 225307)
@@ -1,3 +1,71 @@
+2017-11-29  Saam Barati  
+
+Remove pointer caging for double arrays
+https://bugs.webkit.org/show_bug.cgi?id=180163
+
+Reviewed by Mark Lam.
+
+This patch removes pointer caging from double arrays. Like
+my previous removals of pointer caging, this is a security vs
+performance tradeoff. We believe that butterflies being allocated
+in the cage and with a 32GB runway gives us enough security that
+pointer caging the butterfly just for double arrays does not add
+enough security benefit for the performance hit it incurs.
+
+This patch also

[webkit-changes] [225202] trunk

2017-11-27 Thread sbarati

Title: [225202] trunk








Revision 225202
Author sbar...@apple.com
Date 2017-11-27 16:14:07 -0800 (Mon, 27 Nov 2017)


Log Message
Spread can escape when CreateRest does not
https://bugs.webkit.org/show_bug.cgi?id=180057


Reviewed by JF Bastien.

JSTests:

* stress/spread-escapes-but-create-rest-does-not.js: Added.
(assert):
(getProperties):
(theFunc):
(let.obj.valueOf):

Source/_javascript_Core:

We previously did not handle Spread(PhantomCreateRest) only because I did not
think it was possible to generate this IR. I was wrong. We can generate
such IR when we have a PutStack(Spread) but nothing escapes the CreateRest.
This IR is rare to generate since we normally don't PutStack(Spread) because
the SetLocal almost always gets eliminated because of how our bytecode generates
op_spread. However, there exists a test case showing it is possible. Supporting
this IR pattern in FTLLower is trivial. This patch implements it and rewrites
the Validation rule for Spread.

* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGValidate.cpp:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileSpread):
* runtime/JSFixedArray.h:
(JSC::JSFixedArray::tryCreate):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGOperations.cpp
trunk/Source/_javascript_Core/dfg/DFGOperations.h
trunk/Source/_javascript_Core/dfg/DFGValidate.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
trunk/Source/_javascript_Core/runtime/JSFixedArray.h


Added Paths

trunk/JSTests/stress/spread-escapes-but-create-rest-does-not.js




Diff

Modified: trunk/JSTests/ChangeLog (225201 => 225202)

--- trunk/JSTests/ChangeLog	2017-11-27 23:51:21 UTC (rev 225201)
+++ trunk/JSTests/ChangeLog	2017-11-28 00:14:07 UTC (rev 225202)
@@ -1,3 +1,17 @@
+2017-11-27  Saam Barati  
+
+Spread can escape when CreateRest does not
+https://bugs.webkit.org/show_bug.cgi?id=180057
+
+
+Reviewed by JF Bastien.
+
+* stress/spread-escapes-but-create-rest-does-not.js: Added.
+(assert):
+(getProperties):
+(theFunc):
+(let.obj.valueOf):
+
 2017-11-21  Yusuke Suzuki  
 
 [DFG] Add NormalizeMapKey DFG IR


Added: trunk/JSTests/stress/spread-escapes-but-create-rest-does-not.js (0 => 225202)

--- trunk/JSTests/stress/spread-escapes-but-create-rest-does-not.js	(rev 0)
+++ trunk/JSTests/stress/spread-escapes-but-create-rest-does-not.js	2017-11-28 00:14:07 UTC (rev 225202)
@@ -0,0 +1,35 @@
+function assert(b) {
+if (!b)
+throw new Error;
+}
+noInline(assert);
+
+function getProperties(obj) {
+let properties = [];
+for (let name of Object.getOwnPropertyNames(obj)) {
+properties.push(name);
+}
+return properties;
+}
+
+function theFunc(obj, index, ...args) {
+let functions = getProperties(obj);
+let func = functions[index % functions.length];
+obj[func](...args);
+}
+
+let o = {};
+let obj = {
+valueOf: function (x, y) {
+assert(x === 42);
+assert(y === o);
+try {
+} catch (e) {}
+}
+};
+
+for (let i = 0; i < 1e5; ++i) {
+for (let _i = 0; _i < 100; _i++) {
+}
+theFunc(obj, 897989, 42, o);
+}


Modified: trunk/Source/_javascript_Core/ChangeLog (225201 => 225202)

--- trunk/Source/_javascript_Core/ChangeLog	2017-11-27 23:51:21 UTC (rev 225201)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-11-28 00:14:07 UTC (rev 225202)
@@ -1,3 +1,28 @@
+2017-11-27  Saam Barati  
+
+Spread can escape when CreateRest does not
+https://bugs.webkit.org/show_bug.cgi?id=180057
+
+
+Reviewed by JF Bastien.
+
+We previously did not handle Spread(PhantomCreateRest) only because I did not
+think it was possible to generate this IR. I was wrong. We can generate
+such IR when we have a PutStack(Spread) but nothing escapes the CreateRest.
+This IR is rare to generate since we normally don't PutStack(Spread) because
+the SetLocal almost always gets eliminated because of how our bytecode generates
+op_spread. However, there exists a test case showing it is possible. Supporting
+this IR pattern in FTLLower is trivial. This patch implements it and rewrites
+the Validation rule for Spread.
+
+* dfg/DFGOperations.cpp:
+* dfg/DFGOperations.h:
+* dfg/DFGValidate.cpp:
+* ftl/FTLLowerDFGToB3.cpp:
+(JSC::FTL::DFG::LowerDFGToB3::compileSpread):
+* runtime/JSFixedArray.h:
+(JSC::JSFixedArray::tryCreate):
+
 2017-11-27  Don Olmstead  
 
 [CMake][Win] Conditionally select DLL CRT or static CRT


Modified: trunk/Source/_javascript_Core/dfg/DFGOperations.cpp (225201 => 225202)

--- trunk/Source/_javascript_Core/dfg/DFGOperations.cpp	2017-11-27 23:51:21 UTC (rev 225201)
+++

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

2017-11-27 Thread sbarati

Title: [225188] trunk/Source/_javascript_Core








Revision 225188
Author sbar...@apple.com
Date 2017-11-27 12:40:51 -0800 (Mon, 27 Nov 2017)


Log Message
Having a bad time watchpoint firing during compilation revealed a racy assertion
https://bugs.webkit.org/show_bug.cgi?id=180048


Reviewed by Mark Lam.

While a DFG compilation is watching the having a bad time watchpoint, it was
asserting that the rest parameter structure has indexing type ArrayWithContiguous.
However, if the having a bad time watchpoint fires during the compilation,
this particular structure will no longer have ArrayWithContiguous indexing type.
This patch fixes this racy assertion to be aware that the watchpoint may fire
during compilation.

* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCreateRest):
(JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (225187 => 225188)

--- trunk/Source/_javascript_Core/ChangeLog	2017-11-27 20:39:18 UTC (rev 225187)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-11-27 20:40:51 UTC (rev 225188)
@@ -1,3 +1,22 @@
+2017-11-27  Saam Barati  
+
+Having a bad time watchpoint firing during compilation revealed a racy assertion
+https://bugs.webkit.org/show_bug.cgi?id=180048
+
+
+Reviewed by Mark Lam.
+
+While a DFG compilation is watching the having a bad time watchpoint, it was
+asserting that the rest parameter structure has indexing type ArrayWithContiguous.
+However, if the having a bad time watchpoint fires during the compilation,
+this particular structure will no longer have ArrayWithContiguous indexing type.
+This patch fixes this racy assertion to be aware that the watchpoint may fire
+during compilation.
+
+* dfg/DFGSpeculativeJIT.cpp:
+(JSC::DFG::SpeculativeJIT::compileCreateRest):
+(JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
+
 2017-11-27  Tim Horton  
 
 One too many zeroes in macOS version number in FeatureDefines


Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp (225187 => 225188)

--- trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp	2017-11-27 20:39:18 UTC (rev 225187)
+++ trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp	2017-11-27 20:40:51 UTC (rev 225188)
@@ -7246,7 +7246,7 @@
 GPRReg arrayResultGPR = arrayResult.gpr();
 
 bool shouldAllowForArrayStorageStructureForLargeArrays = false;
-ASSERT(m_jit.graph().globalObjectFor(node->origin.semantic)->restParameterStructure()->indexingType() == ArrayWithContiguous);
+ASSERT(m_jit.graph().globalObjectFor(node->origin.semantic)->restParameterStructure()->indexingType() == ArrayWithContiguous || m_jit.graph().globalObjectFor(node->origin.semantic)->isHavingABadTime());
 compileAllocateNewArrayWithSize(m_jit.graph().globalObjectFor(node->origin.semantic), arrayResultGPR, arrayLengthGPR, ArrayWithContiguous, shouldAllowForArrayStorageStructureForLargeArrays);
 
 GPRTemporary argumentsStart(this);
@@ -7446,7 +7446,7 @@
 
 
 bool shouldAllowForArrayStorageStructureForLargeArrays = false;
-ASSERT(m_jit.graph().globalObjectFor(node->origin.semantic)->restParameterStructure()->indexingType() == ArrayWithContiguous);
+ASSERT(m_jit.graph().globalObjectFor(node->origin.semantic)->restParameterStructure()->indexingType() == ArrayWithContiguous || m_jit.graph().globalObjectFor(node->origin.semantic)->isHavingABadTime());
 compileAllocateNewArrayWithSize(m_jit.graph().globalObjectFor(node->origin.semantic), resultGPR, lengthGPR, ArrayWithContiguous, shouldAllowForArrayStorageStructureForLargeArrays);
 }
 






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-11-16 Thread sbarati

Title: [224942] trunk/Source/_javascript_Core








Revision 224942
Author sbar...@apple.com
Date 2017-11-16 16:35:49 -0800 (Thu, 16 Nov 2017)


Log Message
Fix a bug with cpuid in the FTL.

Rubber stamped by Mark Lam.

Before uploading the previous patch, I tried to condense the code. I
accidentally removed a crucial line saying that CPUID clobbers various
registers.

* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCPUIntrinsic):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (224941 => 224942)

--- trunk/Source/_javascript_Core/ChangeLog	2017-11-17 00:28:30 UTC (rev 224941)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-11-17 00:35:49 UTC (rev 224942)
@@ -1,5 +1,18 @@
 2017-11-16  Saam Barati  
 
+Fix a bug with cpuid in the FTL.
+
+Rubber stamped by Mark Lam.
+
+Before uploading the previous patch, I tried to condense the code. I
+accidentally removed a crucial line saying that CPUID clobbers various
+registers.
+
+* ftl/FTLLowerDFGToB3.cpp:
+(JSC::FTL::DFG::LowerDFGToB3::compileCPUIntrinsic):
+
+2017-11-16  Saam Barati  
+
 Add some X86 intrinsics to $vm to help with some perf testing
 https://bugs.webkit.org/show_bug.cgi?id=179693
 


Modified: trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp (224941 => 224942)

--- trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp	2017-11-17 00:28:30 UTC (rev 224941)
+++ trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp	2017-11-17 00:35:49 UTC (rev 224942)
@@ -8208,6 +8208,9 @@
 case CPUPauseIntrinsic: {
 PatchpointValue* patchpoint = m_out.patchpoint(Void);
 patchpoint->effects = Effects::forCall();
+if (intrinsic == CPUCpuidIntrinsic)
+patchpoint->clobber(RegisterSet { X86Registers::eax, X86Registers::ebx, X86Registers::ecx, X86Registers::edx });
+
 patchpoint->setGenerator([=] (CCallHelpers& jit, const B3::StackmapGenerationParams&) {
 switch (intrinsic) {
 case CPUMfenceIntrinsic:






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-11-16 Thread sbarati

Title: [224938] trunk/Source/_javascript_Core








Revision 224938
Author sbar...@apple.com
Date 2017-11-16 15:44:12 -0800 (Thu, 16 Nov 2017)


Log Message
Add some X86 intrinsics to $vm to help with some perf testing
https://bugs.webkit.org/show_bug.cgi?id=179693

Reviewed by Mark Lam.

I've been doing some local perf testing of various ideas and have
had these come in handy. I'm going to land them to dollarVM to prevent
having to add them to my local build every time I do perf testing.

* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::mfence):
(JSC::MacroAssemblerX86Common::rdtsc):
(JSC::MacroAssemblerX86Common::pause):
(JSC::MacroAssemblerX86Common::cpuid):
* assembler/X86Assembler.h:
(JSC::X86Assembler::rdtsc):
(JSC::X86Assembler::pause):
(JSC::X86Assembler::cpuid):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGNode.h:
(JSC::DFG::Node::intrinsic):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCPUIntrinsic):
* runtime/Intrinsic.cpp:
(JSC::intrinsicName):
* runtime/Intrinsic.h:
* tools/JSDollarVM.cpp:
(JSC::functionCpuMfence):
(JSC::functionCpuRdtsc):
(JSC::functionCpuCpuid):
(JSC::functionCpuPause):
(JSC::functionCpuClflush):
(JSC::JSDollarVM::finishCreation):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/assembler/MacroAssemblerX86Common.h
trunk/Source/_javascript_Core/assembler/X86Assembler.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/DFGDoesGC.cpp
trunk/Source/_javascript_Core/dfg/DFGFixupPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGGraph.cpp
trunk/Source/_javascript_Core/dfg/DFGNode.h
trunk/Source/_javascript_Core/dfg/DFGNodeType.h
trunk/Source/_javascript_Core/dfg/DFGPredictionPropagationPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGSafeToExecute.h
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT32_64.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp
trunk/Source/_javascript_Core/dfg/DFGValidate.cpp
trunk/Source/_javascript_Core/ftl/FTLCapabilities.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
trunk/Source/_javascript_Core/runtime/Intrinsic.cpp
trunk/Source/_javascript_Core/runtime/Intrinsic.h
trunk/Source/_javascript_Core/tools/JSDollarVM.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (224937 => 224938)

--- trunk/Source/_javascript_Core/ChangeLog	2017-11-16 23:27:59 UTC (rev 224937)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-11-16 23:44:12 UTC (rev 224938)
@@ -1,3 +1,62 @@
+2017-11-16  Saam Barati  
+
+Add some X86 intrinsics to $vm to help with some perf testing
+https://bugs.webkit.org/show_bug.cgi?id=179693
+
+Reviewed by Mark Lam.
+
+I've been doing some local perf testing of various ideas and have
+had these come in handy. I'm going to land them to dollarVM to prevent
+having to add them to my local build every time I do perf testing.
+
+* assembler/MacroAssemblerX86Common.h:
+(JSC::MacroAssemblerX86Common::mfence):
+(JSC::MacroAssemblerX86Common::rdtsc):
+(JSC::MacroAssemblerX86Common::pause):
+(JSC::MacroAssemblerX86Common::cpuid):
+* assembler/X86Assembler.h:
+(JSC::X86Assembler::rdtsc):
+(JSC::X86Assembler::pause):
+(JSC::X86Assembler::cpuid):
+* dfg/DFGAbstractInterpreterInlines.h:
+(JSC::DFG::AbstractInterpreter::executeEffects):
+* dfg/DFGByteCodeParser.cpp:
+(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
+* dfg/DFGClobberize.h:
+(JSC::DFG::clobberize):
+* dfg/DFGDoesGC.cpp:
+(JSC::DFG::doesGC):
+* dfg/DFGFixupPhase.cpp:
+(JSC::DFG::FixupPhase::fixupNode):
+* dfg/DFGGraph.cpp:
+(JSC::DFG::Graph::dump):
+* dfg/DFGNode.h:
+(JSC::DFG::Node::intrinsic):
+* dfg/DFGNodeType.h:
+* dfg/DFGPredictionPropagationPhase.cpp:
+* dfg/DFGSafeToExecute.h:
+(JSC::DFG::safeToExecute):
+* dfg/DFGSpeculativeJIT32_64.cpp:
+(JSC::DFG::SpeculativeJIT::compile):
+* dfg/DFGSpeculativeJIT64.cpp:
+

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

2017-11-14 Thread sbarati

Title: [224811] trunk/Source/bmalloc








Revision 224811
Author sbar...@apple.com
Date 2017-11-14 01:08:06 -0800 (Tue, 14 Nov 2017)


Log Message
Make the gigacage runway 32GB
https://bugs.webkit.org/show_bug.cgi?id=175062

Reviewed by Mark Lam.

Making the gigacage runway 32GB defends us against buffer overflows in the
cage reaching memory outside the cage assuming indices are 32-bit unsigned
integers and the type they're indexing into has size <= 8 bytes. This is
exactly the case for many things in JSC. For example, butterfly access in
JSC meet this criteria, as does typed array access.

The 32GB comes from 8 * 2^32 = 32GB.

* bmalloc/Gigacage.cpp:

Modified Paths

trunk/Source/bmalloc/ChangeLog
trunk/Source/bmalloc/bmalloc/Gigacage.cpp




Diff

Modified: trunk/Source/bmalloc/ChangeLog (224810 => 224811)

--- trunk/Source/bmalloc/ChangeLog	2017-11-14 09:05:33 UTC (rev 224810)
+++ trunk/Source/bmalloc/ChangeLog	2017-11-14 09:08:06 UTC (rev 224811)
@@ -1,3 +1,20 @@
+2017-11-14  Saam Barati  
+
+Make the gigacage runway 32GB
+https://bugs.webkit.org/show_bug.cgi?id=175062
+
+Reviewed by Mark Lam.
+
+Making the gigacage runway 32GB defends us against buffer overflows in the
+cage reaching memory outside the cage assuming indices are 32-bit unsigned
+integers and the type they're indexing into has size <= 8 bytes. This is
+exactly the case for many things in JSC. For example, butterfly access in
+JSC meet this criteria, as does typed array access.
+
+The 32GB comes from 8 * 2^32 = 32GB.
+
+* bmalloc/Gigacage.cpp:
+
 2017-11-08  Michael Catanzaro  
 
 Gigacage.cpp:44:46: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context]


Modified: trunk/Source/bmalloc/bmalloc/Gigacage.cpp (224810 => 224811)

--- trunk/Source/bmalloc/bmalloc/Gigacage.cpp	2017-11-14 09:05:33 UTC (rev 224810)
+++ trunk/Source/bmalloc/bmalloc/Gigacage.cpp	2017-11-14 09:08:06 UTC (rev 224811)
@@ -39,9 +39,7 @@
 // https://bugs.webkit.org/show_bug.cgi?id=177605
 #define GIGACAGE_RUNWAY 0
 #else
-// FIXME: Consider making this 32GB, in case unsigned 32-bit indices find their way into indexed accesses.
-// https://bugs.webkit.org/show_bug.cgi?id=175062
-#define GIGACAGE_RUNWAY (16llu * 1024 * 1024 * 1024)
+#define GIGACAGE_RUNWAY (32llu * 1024 * 1024 * 1024)
 #endif
 
 char g_gigacageBasePtrs[GIGACAGE_BASE_PTRS_SIZE] __attribute__((aligned(GIGACAGE_BASE_PTRS_SIZE)));






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [224810] trunk

2017-11-14 Thread sbarati

Title: [224810] trunk








Revision 224810
Author sbar...@apple.com
Date 2017-11-14 01:05:33 -0800 (Tue, 14 Nov 2017)


Log Message
We need to set topCallFrame when calling Wasm::Memory::grow from the JIT
https://bugs.webkit.org/show_bug.cgi?id=179639


Reviewed by JF Bastien.

JSTests:

* wasm/function-tests/grow-memory-cause-gc.js: Added.
(escape):
(i.func):

Source/_javascript_Core:

Calling Wasm::Memory::grow from the JIT may cause us to GC. When we GC, we will
walk the stack for ShadowChicken (and maybe other things). We weren't updating
topCallFrame when calling grow from the Wasm JIT. This would cause the GC to
use stale topCallFrame bits in VM, often leading to crashes. This patch fixes
this bug by giving Wasm::Instance a lambda that is called when we need to store
the topCallFrame. Users of Wasm::Instance can provide a function to do this action.
Currently, JSWebAssemblyInstance passes in a lambda that stores to
VM.topCallFrame.

* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addGrowMemory):
* wasm/WasmInstance.cpp:
(JSC::Wasm::Instance::Instance):
(JSC::Wasm::Instance::create):
* wasm/WasmInstance.h:
(JSC::Wasm::Instance::storeTopCallFrame):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::create):
* wasm/js/JSWebAssemblyInstance.h:
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJSException):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::instantiate):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/wasm/WasmB3IRGenerator.cpp
trunk/Source/_javascript_Core/wasm/WasmInstance.cpp
trunk/Source/_javascript_Core/wasm/WasmInstance.h
trunk/Source/_javascript_Core/wasm/js/JSWebAssemblyInstance.cpp
trunk/Source/_javascript_Core/wasm/js/JSWebAssemblyInstance.h
trunk/Source/_javascript_Core/wasm/js/WasmToJS.cpp
trunk/Source/_javascript_Core/wasm/js/WebAssemblyInstanceConstructor.cpp
trunk/Source/_javascript_Core/wasm/js/WebAssemblyPrototype.cpp


Added Paths

trunk/JSTests/wasm/function-tests/grow-memory-cause-gc.js




Diff

Modified: trunk/JSTests/ChangeLog (224809 => 224810)

--- trunk/JSTests/ChangeLog	2017-11-14 08:56:15 UTC (rev 224809)
+++ trunk/JSTests/ChangeLog	2017-11-14 09:05:33 UTC (rev 224810)
@@ -1,3 +1,15 @@
+2017-11-14  Saam Barati  
+
+We need to set topCallFrame when calling Wasm::Memory::grow from the JIT
+https://bugs.webkit.org/show_bug.cgi?id=179639
+
+
+Reviewed by JF Bastien.
+
+* wasm/function-tests/grow-memory-cause-gc.js: Added.
+(escape):
+(i.func):
+
 2017-11-13  Mark Lam  
 
 Add more overflow check book-keeping for MarkedArgumentBuffer.


Added: trunk/JSTests/wasm/function-tests/grow-memory-cause-gc.js (0 => 224810)

--- trunk/JSTests/wasm/function-tests/grow-memory-cause-gc.js	(rev 0)
+++ trunk/JSTests/wasm/function-tests/grow-memory-cause-gc.js	2017-11-14 09:05:33 UTC (rev 224810)
@@ -0,0 +1,61 @@
+import Builder from '../Builder.js';
+import * as assert from '../assert.js';
+
+function escape(){}
+noInline(escape);
+
+for (let i = 0; i < 10; ++i) {
+const max = 1024*2;
+const memoryDescription = {initial: 0, maximum: max};
+const growMemoryAmount = 256;
+
+const builder = (new Builder())
+.Type().End()
+.Import()
+.Function("imp", "func", {params: [], ret: "void"})
+.Memory("imp", "memory", memoryDescription)
+.End()
+.Function().End()
+.Export()
+.Function("foo")
+.End()
+.Code()
+.Function("foo", {params: [], ret: "i32"})
+.I32Const(1)
+.I32Const(1)
+.I32Const(1)
+.I32Const(1)
+.I32Const(1)
+.I32Const(1)
+.I32Const(1)
+.I32Const(1)
+.I32Const(1)
+.I32Const(1)
+.I32Const(1)
+.I32Const(1)
+.I32Const(1)
+.I32Const(1)
+.I32Const(1)
+.I32Const(1)
+.Call(2)
+.I32Const(growMemoryAmount)
+.GrowMemory(0)
+.Return()
+.End()
+.Function("bar", {params: ["i32", "i32", "i32", "i32", "i32", "i32", "i32", "i32", "i32", "i32", "i32", "i32", "i32", "i32", "i32", "i32"], ret: "void"})
+.Call(0)
+.Return()
+.End()
+.End();
+
+const bin = builder.WebAssembly().get();
+const module = new WebAssembly.Module(bin);
+const memory = new WebAssembly.Memory(memoryDescription);
+
+function func() { }
+
+const instance = new WebAssembly.Instance(module, {imp: {memory, func}});
+for (let i = 0; i < max/growMemoryAmount; ++i) {
+instance.exports.foo();
+}
+}


Modified:

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

2017-11-13 Thread sbarati

Title: [224802] trunk/Source/_javascript_Core








Revision 224802
Author sbar...@apple.com
Date 2017-11-13 21:33:30 -0800 (Mon, 13 Nov 2017)


Log Message
Remove pointer caging for HashMapImpl, JSLexicalEnvironment, DirectArguments, ScopedArguments, and ScopedArgumentsTable
https://bugs.webkit.org/show_bug.cgi?id=179203

Reviewed by Yusuke Suzuki.

This patch only removes the pointer caging for the described types in the title.
These types still allocate out of the gigacage. This is a just a cost vs benefit
tradeoff of performance vs security.

* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
(JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitDirectArgumentsGetByVal):
(JSC::JIT::emitScopedArgumentsGetByVal):
* runtime/DirectArguments.h:
(JSC::DirectArguments::storage):
* runtime/HashMapImpl.cpp:
(JSC::HashMapImpl::visitChildren):
* runtime/HashMapImpl.h:
* runtime/JSLexicalEnvironment.h:
(JSC::JSLexicalEnvironment::variables):
* runtime/ScopedArguments.h:
(JSC::ScopedArguments::overflowStorage const):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
trunk/Source/_javascript_Core/jit/JITPropertyAccess.cpp
trunk/Source/_javascript_Core/runtime/DirectArguments.h
trunk/Source/_javascript_Core/runtime/HashMapImpl.cpp
trunk/Source/_javascript_Core/runtime/HashMapImpl.h
trunk/Source/_javascript_Core/runtime/JSLexicalEnvironment.h
trunk/Source/_javascript_Core/runtime/ScopedArguments.h




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (224801 => 224802)

--- trunk/Source/_javascript_Core/ChangeLog	2017-11-14 03:58:01 UTC (rev 224801)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-11-14 05:33:30 UTC (rev 224802)
@@ -1,3 +1,32 @@
+2017-11-13  Saam Barati  
+
+Remove pointer caging for HashMapImpl, JSLexicalEnvironment, DirectArguments, ScopedArguments, and ScopedArgumentsTable
+https://bugs.webkit.org/show_bug.cgi?id=179203
+
+Reviewed by Yusuke Suzuki.
+
+This patch only removes the pointer caging for the described types in the title.
+These types still allocate out of the gigacage. This is a just a cost vs benefit
+tradeoff of performance vs security.
+
+* dfg/DFGSpeculativeJIT.cpp:
+(JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
+(JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
+* ftl/FTLLowerDFGToB3.cpp:
+(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
+* jit/JITPropertyAccess.cpp:
+(JSC::JIT::emitDirectArgumentsGetByVal):
+(JSC::JIT::emitScopedArgumentsGetByVal):
+* runtime/DirectArguments.h:
+(JSC::DirectArguments::storage):
+* runtime/HashMapImpl.cpp:
+(JSC::HashMapImpl::visitChildren):
+* runtime/HashMapImpl.h:
+* runtime/JSLexicalEnvironment.h:
+(JSC::JSLexicalEnvironment::variables):
+* runtime/ScopedArguments.h:
+(JSC::ScopedArguments::overflowStorage const):
+
 2017-11-08  Keith Miller  
 
 Async iteration should only fetch the next method once and add feature flag


Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp (224801 => 224802)

--- trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp	2017-11-14 03:58:01 UTC (rev 224801)
+++ trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp	2017-11-14 05:33:30 UTC (rev 224802)
@@ -6496,8 +6496,6 @@
 MacroAssembler::AboveOrEqual, propertyReg,
 MacroAssembler::Address(baseReg, DirectArguments::offsetOfLength(;
 
-m_jit.cage(Gigacage::JSValue, baseReg);
-
 m_jit.loadValue(
 MacroAssembler::BaseIndex(
 baseReg, propertyReg, MacroAssembler::TimesEight, DirectArguments::storageOffset()),
@@ -6552,7 +6550,6 @@
 m_jit.loadPtr(
 MacroAssembler::Address(scratchReg, ScopedArgumentsTable::offsetOfArguments()),
 scratchReg);
-m_jit.cage(ScopedArgumentsTable::ArgumentsPtr::kind, scratchReg);
 m_jit.load32(
 MacroAssembler::BaseIndex(scratchReg, propertyReg, MacroAssembler::TimesFour),
 scratchReg);
@@ -6562,8 +6559,6 @@
 m_jit.branch32(
 MacroAssembler::Equal, scratchReg, TrustedImm32(ScopeOffset::invalidOffset)));
 
-m_jit.cage(Gigacage::JSValue, scratch2Reg);
-
 m_jit.loadValue(
 MacroAssembler::BaseIndex(
 scratch2Reg, propertyReg, MacroAssembler::TimesEight,
@@ -6576,8 +6571,6 @@
 m_jit.sub32(propertyReg, scratch2Reg);
 m_jit.neg32(scratch2Reg);
 
-m_jit.cage(Gigacage::JSValue, baseReg);
-
 m_jit.loadValue(
 MacroAssembler::BaseIndex(
 baseReg, scratch2Reg, MacroAssembler::TimesEight,

[webkit-changes] [224603] trunk

2017-11-08 Thread sbarati

Title: [224603] trunk








Revision 224603
Author sbar...@apple.com
Date 2017-11-08 15:38:55 -0800 (Wed, 08 Nov 2017)


Log Message
A JSFunction's ObjectAllocationProfile should watch the poly prototype watchpoint so it can clear its object allocation profile
https://bugs.webkit.org/show_bug.cgi?id=177792

Reviewed by Yusuke Suzuki.

JSTests:

* microbenchmarks/poly-proto-clear-js-function-allocation-profile.js: Added.
(assert):
(foo.Foo.prototype.ensureX):
(foo.Foo):
(foo):
(access):

Source/_javascript_Core:

Before this patch, if a JSFunction's rare data initialized its allocation profile
before its backing Executable's poly proto watchpoint was invalidated, that
JSFunction would continue to allocate non-poly proto objects until its allocation
profile was cleared (which essentially never happens in practice). This patch
improves on this pathology. A JSFunction's rare data will now watch the poly
proto watchpoint if it's still valid and clear its allocation profile when we
detect that we should go poly proto.

* bytecode/ObjectAllocationProfile.h:
* bytecode/ObjectAllocationProfileInlines.h:
(JSC::ObjectAllocationProfile::initializeProfile):
* runtime/FunctionRareData.cpp:
(JSC::FunctionRareData::initializeObjectAllocationProfile):
(JSC::FunctionRareData::AllocationProfileClearingWatchpoint::fireInternal):
* runtime/FunctionRareData.h:
(JSC::FunctionRareData::hasAllocationProfileClearingWatchpoint const):
(JSC::FunctionRareData::createAllocationProfileClearingWatchpoint):
(JSC::FunctionRareData::AllocationProfileClearingWatchpoint::AllocationProfileClearingWatchpoint):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/ObjectAllocationProfile.h
trunk/Source/_javascript_Core/bytecode/ObjectAllocationProfileInlines.h
trunk/Source/_javascript_Core/runtime/FunctionRareData.cpp
trunk/Source/_javascript_Core/runtime/FunctionRareData.h


Added Paths

trunk/JSTests/microbenchmarks/poly-proto-clear-js-function-allocation-profile.js




Diff

Modified: trunk/JSTests/ChangeLog (224602 => 224603)

--- trunk/JSTests/ChangeLog	2017-11-08 23:22:32 UTC (rev 224602)
+++ trunk/JSTests/ChangeLog	2017-11-08 23:38:55 UTC (rev 224603)
@@ -1,3 +1,17 @@
+2017-11-08  Saam Barati  
+
+A JSFunction's ObjectAllocationProfile should watch the poly prototype watchpoint so it can clear its object allocation profile
+https://bugs.webkit.org/show_bug.cgi?id=177792
+
+Reviewed by Yusuke Suzuki.
+
+* microbenchmarks/poly-proto-clear-js-function-allocation-profile.js: Added.
+(assert):
+(foo.Foo.prototype.ensureX):
+(foo.Foo):
+(foo):
+(access):
+
 2017-11-08  Ryan Haddad  
 
 Mark test262.yaml/test262/test/language/statements/try/tco-catch.js as passing.


Added: trunk/JSTests/microbenchmarks/poly-proto-clear-js-function-allocation-profile.js (0 => 224603)

--- trunk/JSTests/microbenchmarks/poly-proto-clear-js-function-allocation-profile.js	(rev 0)
+++ trunk/JSTests/microbenchmarks/poly-proto-clear-js-function-allocation-profile.js	2017-11-08 23:38:55 UTC (rev 224603)
@@ -0,0 +1,36 @@
+function assert(b) {
+if (!b)
+throw new Error("Bad assertion")
+}
+
+function foo() {
+class Foo {
+ensureX() {
+if (!this.x)
+this.x = 22;
+return this;
+}
+};
+return Foo;
+}
+
+function access(o) {
+return assert(o.ensureX().x === 22);
+}
+noInline(access);
+
+let ctors = [];
+
+for (let i = 0; i < 50; ++i) {
+let ctor = foo();
+new ctor; // warm things up
+ctors.push(ctor);
+}
+
+let start = Date.now();
+for (let i = 0; i < 5000; ++i) {
+for (let i = 0; i < ctors.length; ++i)
+access(new ctors[i]);
+}
+if (false)
+print(Date.now() - start);


Modified: trunk/Source/_javascript_Core/ChangeLog (224602 => 224603)

--- trunk/Source/_javascript_Core/ChangeLog	2017-11-08 23:22:32 UTC (rev 224602)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-11-08 23:38:55 UTC (rev 224603)
@@ -1,3 +1,29 @@
+2017-11-08  Saam Barati  
+
+A JSFunction's ObjectAllocationProfile should watch the poly prototype watchpoint so it can clear its object allocation profile
+https://bugs.webkit.org/show_bug.cgi?id=177792
+
+Reviewed by Yusuke Suzuki.
+
+Before this patch, if a JSFunction's rare data initialized its allocation profile
+before its backing Executable's poly proto watchpoint was invalidated, that
+JSFunction would continue to allocate non-poly proto objects until its allocation
+profile was cleared (which essentially never happens in practice). This patch
+improves on this pathology. A JSFunction's rare data will now watch the poly
+proto watchpoint if it's still valid and clear its allocation profile when we
+detect that we should go poly proto.
+
+

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

2017-11-07 Thread sbarati

Title: [224564] trunk/Source/_javascript_Core








Revision 224564
Author sbar...@apple.com
Date 2017-11-07 22:29:31 -0800 (Tue, 07 Nov 2017)


Log Message
Only cage double butterfly accesses
https://bugs.webkit.org/show_bug.cgi?id=179202

Reviewed by Mark Lam.

This patch removes caging from all butterfly accesses except double loads/stores.
This is a performance vs security tradeoff. Double loads/stores are the only butterfly
loads/stores that can write arbitrary bit patterns, so we choose to keep them safe
by caging. The other load/stores we are no longer caging to get back performance on
various benchmarks.

* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* bytecode/InlineAccess.cpp:
(JSC::InlineAccess::dumpCacheSizesAndCrash):
(JSC::InlineAccess::generateSelfPropertyAccess):
(JSC::InlineAccess::generateSelfPropertyReplace):
(JSC::InlineAccess::generateArrayLength):
* dfg/DFGFixedButterflyAccessUncagingPhase.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCreateRest):
(JSC::DFG::SpeculativeJIT::compileSpread):
(JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitContiguousLoad):
(JSC::JIT::emitArrayStorageLoad):
(JSC::JIT::emitGenericContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emit_op_put_to_scope):
* llint/LowLevelInterpreter64.asm:
* runtime/AuxiliaryBarrier.h:
(JSC::AuxiliaryBarrier::operator-> const):
* runtime/Butterfly.h:
(JSC::Butterfly::caged):
(JSC::Butterfly::contiguousDouble):
* runtime/JSArray.cpp:
(JSC::JSArray::setLength):
(JSC::JSArray::pop):
(JSC::JSArray::shiftCountWithAnyIndexingType):
(JSC::JSArray::unshiftCountWithAnyIndexingType):
(JSC::JSArray::fillArgList):
(JSC::JSArray::copyToArguments):
* runtime/JSArrayInlines.h:
(JSC::JSArray::pushInline):
* runtime/JSObject.cpp:
(JSC::JSObject::heapSnapshot):
(JSC::JSObject::createInitialIndexedStorage):
(JSC::JSObject::createArrayStorage):
(JSC::JSObject::convertUndecidedToInt32):
(JSC::JSObject::ensureLengthSlow):
(JSC::JSObject::reallocateAndShrinkButterfly):
(JSC::JSObject::allocateMoreOutOfLineStorage):
* runtime/JSObject.h:
(JSC::JSObject::canGetIndexQuickly):
(JSC::JSObject::getIndexQuickly):
(JSC::JSObject::tryGetIndexQuickly const):
(JSC::JSObject::canSetIndexQuickly):
(JSC::JSObject::butterfly const):
(JSC::JSObject::butterfly):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/AccessCase.cpp
trunk/Source/_javascript_Core/bytecode/InlineAccess.cpp
trunk/Source/_javascript_Core/dfg/DFGFixedButterflyAccessUncagingPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
trunk/Source/_javascript_Core/jit/JITPropertyAccess.cpp
trunk/Source/_javascript_Core/llint/LowLevelInterpreter64.asm
trunk/Source/_javascript_Core/runtime/AuxiliaryBarrier.h
trunk/Source/_javascript_Core/runtime/Butterfly.h
trunk/Source/_javascript_Core/runtime/ButterflyInlines.h
trunk/Source/_javascript_Core/runtime/JSArray.cpp
trunk/Source/_javascript_Core/runtime/JSArrayInlines.h
trunk/Source/_javascript_Core/runtime/JSObject.cpp
trunk/Source/_javascript_Core/runtime/JSObject.h




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (224563 => 224564)

--- trunk/Source/_javascript_Core/ChangeLog	2017-11-08 05:41:30 UTC (rev 224563)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-11-08 06:29:31 UTC (rev 224564)
@@ -1,3 +1,70 @@
+2017-11-07  Saam Barati  
+
+Only cage double butterfly accesses
+https://bugs.webkit.org/show_bug.cgi?id=179202
+
+Reviewed by Mark Lam.
+
+This patch removes caging from all butterfly accesses except double loads/stores.
+This is a performance vs security tradeoff. Double loads/stores are the only butterfly
+loads/stores that can write arbitrary bit patterns, so we choose to keep them safe
+by caging. The other load/stores we are no longer caging to get back performance on
+various benchmarks.
+
+* bytecode/AccessCase.cpp:
+(JSC::AccessCase::generateImpl):
+* bytecode/InlineAccess.cpp:
+(JSC::InlineAccess::dumpCacheSizesAndCrash):
+(JSC::InlineAccess::generateSelfPropertyAccess):
+(JSC::InlineAccess::generateSelfPropertyReplace):
+(JSC::InlineAccess::generateArrayLength):
+* dfg/DFGFixedButterflyAccessUncagingPhase.cpp:
+* dfg/DFGSpeculativeJIT.cpp:
+(JSC::DFG::SpeculativeJIT::compileCreateRest):
+(JSC::DFG::SpeculativeJIT::compileSpread):
+(JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
+* dfg/DFGSpeculativeJIT64.cpp:
+(JSC::DFG::SpeculativeJIT::compile):
+*

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

2017-11-07 Thread sbarati

Title: [224555] trunk/Source/bmalloc








Revision 224555
Author sbar...@apple.com
Date 2017-11-07 15:31:22 -0800 (Tue, 07 Nov 2017)


Log Message
We should PROT_NONE the Gigacage runway so OOB accesses crash
https://bugs.webkit.org/show_bug.cgi?id=179392

Reviewed by Mark Lam.

If we assume that an attacker will exploit JSC and cause OOB accesses,
we should make OOB accesses in the Gigacage runway crash.

* bmalloc/Gigacage.cpp:
(Gigacage::ensureGigacage):

Modified Paths

trunk/Source/bmalloc/ChangeLog
trunk/Source/bmalloc/bmalloc/Gigacage.cpp




Diff

Modified: trunk/Source/bmalloc/ChangeLog (224554 => 224555)

--- trunk/Source/bmalloc/ChangeLog	2017-11-07 23:21:38 UTC (rev 224554)
+++ trunk/Source/bmalloc/ChangeLog	2017-11-07 23:31:22 UTC (rev 224555)
@@ -1,3 +1,16 @@
+2017-11-07  Saam Barati  
+
+We should PROT_NONE the Gigacage runway so OOB accesses crash
+https://bugs.webkit.org/show_bug.cgi?id=179392
+
+Reviewed by Mark Lam.
+
+If we assume that an attacker will exploit JSC and cause OOB accesses,
+we should make OOB accesses in the Gigacage runway crash.
+
+* bmalloc/Gigacage.cpp:
+(Gigacage::ensureGigacage):
+
 2017-10-31  Filip Pizlo  
 
 bmalloc should support strictly type-segregated isolated heaps


Modified: trunk/Source/bmalloc/bmalloc/Gigacage.cpp (224554 => 224555)

--- trunk/Source/bmalloc/bmalloc/Gigacage.cpp	2017-11-07 23:21:38 UTC (rev 224554)
+++ trunk/Source/bmalloc/bmalloc/Gigacage.cpp	2017-11-07 23:31:22 UTC (rev 224555)
@@ -155,6 +155,13 @@
 fprintf(stderr, "FATAL: Could not allocate gigacage memory with maxAlignment = %lu, totalSize = %lu.\n", maxAlignment, totalSize);
 BCRASH();
 }
+
+if (GIGACAGE_RUNWAY) {
+char* runway = reinterpret_cast(base) + totalSize - GIGACAGE_RUNWAY;
+// Make OOB accesses into the runway crash.
+vmRevokePermissions(runway, GIGACAGE_RUNWAY);
+}
+
 vmDeallocatePhysicalPages(base, totalSize);
 
 size_t nextCage = 0;






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-10-30 Thread sbarati

Title: [224217] trunk/Source/_javascript_Core








Revision 224217
Author sbar...@apple.com
Date 2017-10-30 18:15:08 -0700 (Mon, 30 Oct 2017)


Log Message
We need a storeStoreFence before storing to the instruction stream's live variable catch data
https://bugs.webkit.org/show_bug.cgi?id=178649

Reviewed by Keith Miller.

* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (224216 => 224217)

--- trunk/Source/_javascript_Core/ChangeLog	2017-10-31 00:49:41 UTC (rev 224216)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-10-31 01:15:08 UTC (rev 224217)
@@ -1,3 +1,13 @@
+2017-10-30  Saam Barati  
+
+We need a storeStoreFence before storing to the instruction stream's live variable catch data
+https://bugs.webkit.org/show_bug.cgi?id=178649
+
+Reviewed by Keith Miller.
+
+* bytecode/CodeBlock.cpp:
+(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
+
 2017-10-30  Michael Catanzaro  
 
 [WPE] Fix build warnings


Modified: trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp (224216 => 224217)

--- trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp	2017-10-31 00:49:41 UTC (rev 224216)
+++ trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp	2017-10-31 01:15:08 UTC (rev 224217)
@@ -1742,6 +1742,12 @@
 RELEASE_ASSERT(profiles->m_size == liveOperands.size());
 for (unsigned i = 0; i < profiles->m_size; ++i)
 profiles->m_buffer.get()[i].m_operand = liveOperands[i].offset();
+
+// The compiler thread will read this pointer value and then proceed to dereference it
+// if it is not null. We need to make sure all above stores happen before this store so
+// the compiler thread reads fully initialized data.
+WTF::storeStoreFence(); 
+
 m_instructions[bytecodeOffset + 3].u.pointer = profiles.get();
 
 {






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-10-27 Thread sbarati

Title: [224138] trunk/Source/_javascript_Core








Revision 224138
Author sbar...@apple.com
Date 2017-10-27 18:03:22 -0700 (Fri, 27 Oct 2017)


Log Message
Bytecode liveness should live on UnlinkedCodeBlock so it can be shared amongst CodeBlocks
https://bugs.webkit.org/show_bug.cgi?id=178949

Reviewed by Keith Miller.

This patch stores BytecodeLiveness on UnlinkedCodeBlock instead of CodeBlock
so that we don't need to recompute liveness for the same UnlinkedCodeBlock
more than once. To do this, this patch solidifies the invariant that CodeBlock
linking can't do anything that would change the result of liveness. For example,
it can't introduce new locals. This invariant was met my JSC before, because we
didn't do anything in bytecode linking that would change liveness. However, it is
now a correctness requirement that we don't do anything that would change the
result of running liveness. To support this change, I've refactored BytecodeGraph
to not be tied to a CodeBlockType*. Things that perform liveness will pass in
CodeBlockType* and the instruction stream as needed. This means that we may
compute liveness with one CodeBlock*'s instruction stream, and then perform
queries on that analysis with a different CodeBlock*'s instruction stream.

This seems to be a 2% JSBench progression.

* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::BytecodeGeneratorification):
(JSC::BytecodeGeneratorification::graph):
(JSC::BytecodeGeneratorification::storageForGeneratorLocal):
(JSC::GeneratorLivenessAnalysis::run):
(JSC::BytecodeGeneratorification::run):
* bytecode/BytecodeGraph.h:
(JSC::BytecodeGraph::BytecodeGraph):
(JSC::BytecodeGraph::codeBlock const): Deleted.
(JSC::BytecodeGraph::instructions): Deleted.
(JSC::BytecodeGraph::BytecodeGraph): Deleted.
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::BytecodeLivenessAnalysis::BytecodeLivenessAnalysis):
(JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset):
(JSC::BytecodeLivenessAnalysis::computeFullLiveness):
(JSC::BytecodeLivenessAnalysis::computeKills):
(JSC::BytecodeLivenessAnalysis::dumpResults):
(JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset): Deleted.
(JSC::BytecodeLivenessAnalysis::compute): Deleted.
* bytecode/BytecodeLivenessAnalysis.h:
* bytecode/BytecodeLivenessAnalysisInlines.h:
(JSC::BytecodeLivenessPropagation::stepOverInstruction):
(JSC::BytecodeLivenessPropagation::computeLocalLivenessForBytecodeOffset):
(JSC::BytecodeLivenessPropagation::computeLocalLivenessForBlock):
(JSC::BytecodeLivenessPropagation::getLivenessInfoAtBytecodeOffset):
(JSC::BytecodeLivenessPropagation::runLivenessFixpoint):
* bytecode/BytecodeRewriter.cpp:
(JSC::BytecodeRewriter::applyModification):
(JSC::BytecodeRewriter::execute):
(JSC::BytecodeRewriter::adjustJumpTargetsInFragment):
* bytecode/BytecodeRewriter.h:
(JSC::BytecodeRewriter::BytecodeRewriter):
(JSC::BytecodeRewriter::removeBytecode):
(JSC::BytecodeRewriter::graph):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
(JSC::CodeBlock::validate):
(JSC::CodeBlock::livenessAnalysisSlow): Deleted.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::livenessAnalysis):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::applyModification):
(JSC::UnlinkedCodeBlock::livenessAnalysisSlow):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::livenessAnalysis):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::livenessFor):
(JSC::DFG::Graph::killsFor):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/BytecodeGeneratorification.cpp
trunk/Source/_javascript_Core/bytecode/BytecodeGraph.h
trunk/Source/_javascript_Core/bytecode/BytecodeLivenessAnalysis.cpp
trunk/Source/_javascript_Core/bytecode/BytecodeLivenessAnalysis.h
trunk/Source/_javascript_Core/bytecode/BytecodeLivenessAnalysisInlines.h
trunk/Source/_javascript_Core/bytecode/BytecodeRewriter.cpp
trunk/Source/_javascript_Core/bytecode/BytecodeRewriter.h
trunk/Source/_javascript_Core/bytecode/CodeBlock.cpp
trunk/Source/_javascript_Core/bytecode/CodeBlock.h
trunk/Source/_javascript_Core/bytecode/UnlinkedCodeBlock.cpp
trunk/Source/_javascript_Core/bytecode/UnlinkedCodeBlock.h
trunk/Source/_javascript_Core/dfg/DFGGraph.cpp
trunk/Source/_javascript_Core/dfg/DFGPlan.cpp
trunk/Source/_javascript_Core/jit/JIT.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (224137 => 224138)

--- trunk/Source/_javascript_Core/ChangeLog	2017-10-28 00:09:47 UTC (rev 224137)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-10-28 01:03:22 UTC (rev 224138)
@@ -1,3 +1,79 @@
+2017-10-27  Saam Barati  
+
+Bytecode liveness should live on UnlinkedCodeBlock so it can be shared amongst CodeBlocks
+https://bugs.webkit.org/show_bug.cgi?id=178949
+
+Reviewed by Keith Miller.
+

[webkit-changes] [223746] trunk/Source

2017-10-20 Thread sbarati

Title: [223746] trunk/Source








Revision 223746
Author sbar...@apple.com
Date 2017-10-20 00:50:08 -0700 (Fri, 20 Oct 2017)


Log Message
Optimize accesses to how we get the direct prototype
https://bugs.webkit.org/show_bug.cgi?id=178548

Reviewed by Yusuke Suzuki.

Source/_javascript_Core:

This patch makes JSObject::getPrototypeDirect take VM& as a parameter
so it can use the faster version of the structure accessor function.
The reason for making this change is that JSObjet::getPrototypeDirect
is called on the hot path in property lookup.

* API/JSObjectRef.cpp:
(JSObjectGetPrototype):
* jsc.cpp:
(WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
(WTF::DOMJITGetterBaseJSObject::customGetter):
(functionCreateProxy):
* runtime/ArrayPrototype.cpp:
(JSC::speciesWatchpointIsValid):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::sanitizedToString):
* runtime/JSArray.cpp:
(JSC::JSArray::isIteratorProtocolFastAndNonObservable):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::lastInPrototypeChain):
(JSC::JSGlobalObject::resetPrototype):
(JSC::JSGlobalObject::finishCreation):
* runtime/JSGlobalObjectInlines.h:
(JSC::JSGlobalObject::objectPrototypeIsSane):
(JSC::JSGlobalObject::arrayPrototypeChainIsSane):
(JSC::JSGlobalObject::stringPrototypeChainIsSane):
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::getOwnPropertySlot):
* runtime/JSMap.cpp:
(JSC::JSMap::isIteratorProtocolFastAndNonObservable):
* runtime/JSObject.cpp:
(JSC::JSObject::calculatedClassName):
(JSC::JSObject::setPrototypeWithCycleCheck):
(JSC::JSObject::getPrototype):
(JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
(JSC::JSObject::attemptToInterceptPutByIndexOnHole):
(JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
(JSC::JSObject::prototypeChainMayInterceptStoreTo):
* runtime/JSObject.h:
(JSC::JSObject::finishCreation):
(JSC::JSObject::getPrototypeDirect const):
(JSC::JSObject::getPrototype):
* runtime/JSObjectInlines.h:
(JSC::JSObject::canPerformFastPutInline):
(JSC::JSObject::getPropertySlot):
(JSC::JSObject::getNonIndexPropertySlot):
* runtime/JSProxy.cpp:
(JSC::JSProxy::setTarget):
* runtime/JSSet.cpp:
(JSC::JSSet::isIteratorProtocolFastAndNonObservable):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/StructureInlines.h:
(JSC::Structure::isValid const):

Source/WebCore:

No new tests: no functionality change.

* bindings/js/JSDOMAbstractOperations.h:
(WebCore::isVisibleNamedProperty):
(WebCore::accessVisibleNamedProperty):
* bindings/js/JSDOMWindowBase.cpp:
(WebCore::toJSDOMWindow):
* bindings/js/JSDOMWindowProperties.cpp:
(WebCore::JSDOMWindowProperties::getOwnPropertySlot):
* bindings/js/JSPluginElementFunctions.cpp:
(WebCore::pluginElementCustomGetOwnPropertySlot):
* bindings/js/WorkerScriptController.cpp:
(WebCore::WorkerScriptController::initScript):
* bindings/scripts/CodeGeneratorJS.pm:
(GeneratePut):
(GeneratePutByIndex):
(GenerateConstructorHelperMethods):
* bindings/scripts/test/JS/JSTestGlobalObject.cpp:
(WebCore::JSTestGlobalObjectConstructor::initializeProperties):
* bindings/scripts/test/JS/JSTestNamedAndIndexedSetterNoIdentifier.cpp:
(WebCore::JSTestNamedAndIndexedSetterNoIdentifier::put):
(WebCore::JSTestNamedAndIndexedSetterNoIdentifier::putByIndex):
* bindings/scripts/test/JS/JSTestNamedAndIndexedSetterThrowingException.cpp:
(WebCore::JSTestNamedAndIndexedSetterThrowingException::put):
(WebCore::JSTestNamedAndIndexedSetterThrowingException::putByIndex):
* bindings/scripts/test/JS/JSTestNamedAndIndexedSetterWithIdentifier.cpp:
(WebCore::JSTestNamedAndIndexedSetterWithIdentifier::put):
(WebCore::JSTestNamedAndIndexedSetterWithIdentifier::putByIndex):
* bindings/scripts/test/JS/JSTestNamedSetterNoIdentifier.cpp:
(WebCore::JSTestNamedSetterNoIdentifier::put):
(WebCore::JSTestNamedSetterNoIdentifier::putByIndex):
* bindings/scripts/test/JS/JSTestNamedSetterThrowingException.cpp:
(WebCore::JSTestNamedSetterThrowingException::put):
(WebCore::JSTestNamedSetterThrowingException::putByIndex):
* bindings/scripts/test/JS/JSTestNamedSetterWithIdentifier.cpp:
(WebCore::JSTestNamedSetterWithIdentifier::put):
(WebCore::JSTestNamedSetterWithIdentifier::putByIndex):
* bindings/scripts/test/JS/JSTestNamedSetterWithIndexedGetter.cpp:
(WebCore::JSTestNamedSetterWithIndexedGetter::put):
(WebCore::JSTestNamedSetterWithIndexedGetter::putByIndex):
* bindings/scripts/test/JS/JSTestNamedSetterWithIndexedGetterAndSetter.cpp:
(WebCore::JSTestNamedSetterWithIndexedGetterAndSetter::put):
(WebCore::JSTestNamedSetterWithIndexedGetterAndSetter::putByIndex):
* bindings/scripts/test/JS/JSTestNamedSetterWithUnforgableProperties.cpp:
(WebCore::JSTestNamedSetterWithUnforgableProperties::put):
(WebCore::JSTestNamedSetterWithUnforgableProperties::putByIndex):

Modified Paths

trunk/Source/_javascript_Core/API/JSObjectRef.cpp
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/jsc.cpp

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

2017-10-19 Thread sbarati

Title: [223741] trunk/Source/bmalloc








Revision 223741
Author sbar...@apple.com
Date 2017-10-19 20:08:26 -0700 (Thu, 19 Oct 2017)


Log Message
Runtime disable gigacage on iOS because it broke WasmBench
https://bugs.webkit.org/show_bug.cgi?id=178556

Reviewed by Keith Miller.

* bmalloc/Gigacage.cpp:
(Gigacage::shouldBeEnabled):

Modified Paths

trunk/Source/bmalloc/ChangeLog
trunk/Source/bmalloc/bmalloc/Gigacage.cpp




Diff

Modified: trunk/Source/bmalloc/ChangeLog (223740 => 223741)

--- trunk/Source/bmalloc/ChangeLog	2017-10-20 02:41:22 UTC (rev 223740)
+++ trunk/Source/bmalloc/ChangeLog	2017-10-20 03:08:26 UTC (rev 223741)
@@ -1,3 +1,13 @@
+2017-10-19  Saam Barati  
+
+Runtime disable gigacage on iOS because it broke WasmBench
+https://bugs.webkit.org/show_bug.cgi?id=178556
+
+Reviewed by Keith Miller.
+
+* bmalloc/Gigacage.cpp:
+(Gigacage::shouldBeEnabled):
+
 2017-10-17  Filip Pizlo  
 
 You can't vmDeallocate null


Modified: trunk/Source/bmalloc/bmalloc/Gigacage.cpp (223740 => 223741)

--- trunk/Source/bmalloc/bmalloc/Gigacage.cpp	2017-10-20 02:41:22 UTC (rev 223740)
+++ trunk/Source/bmalloc/bmalloc/Gigacage.cpp	2017-10-20 03:08:26 UTC (rev 223741)
@@ -240,10 +240,15 @@
 bool shouldBeEnabled()
 {
 static std::once_flag onceFlag;
-static bool cached;
+static bool cached = false;
 std::call_once(
 onceFlag,
 [] {
+#if BCPU(ARM64)
+// FIXME: Make WasmBench run with gigacage on iOS and re-enable on ARM64:
+// https://bugs.webkit.org/show_bug.cgi?id=178557
+return;
+#endif
 bool result = GIGACAGE_ENABLED && !PerProcess::get()->isDebugHeapEnabled();
 if (!result)
 return;






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-10-19 Thread sbarati

Title: [223729] trunk/Source/_javascript_Core








Revision 223729
Author sbar...@apple.com
Date 2017-10-19 16:49:23 -0700 (Thu, 19 Oct 2017)


Log Message
REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning: comparison is always false due to limited range of data type [-Wtype-limits]
https://bugs.webkit.org/show_bug.cgi?id=178543

Reviewed by Filip Pizlo.

* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleRecursiveTailCall):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (223728 => 223729)

--- trunk/Source/_javascript_Core/ChangeLog	2017-10-19 23:48:45 UTC (rev 223728)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-10-19 23:49:23 UTC (rev 223729)
@@ -1,5 +1,15 @@
 2017-10-19  Saam Barati  
 
+REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning: comparison is always false due to limited range of data type [-Wtype-limits]
+https://bugs.webkit.org/show_bug.cgi?id=178543
+
+Reviewed by Filip Pizlo.
+
+* dfg/DFGByteCodeParser.cpp:
+(JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
+
+2017-10-19  Saam Barati  
+
 re-inline ObjectAllocationProfile::initializeProfile
 https://bugs.webkit.org/show_bug.cgi?id=178532
 


Modified: trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp (223728 => 223729)

--- trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp	2017-10-19 23:48:45 UTC (rev 223728)
+++ trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp	2017-10-19 23:49:23 UTC (rev 223729)
@@ -1480,7 +1480,7 @@
 addJumpTo(*entryBlockPtr);
 return true;
 // It would be unsound to jump over a non-tail call: the "tail" call is not really a tail call in that case.
-} while (stackEntry->m_inlineCallFrame && stackEntry->m_inlineCallFrame->kind == TailCall && (stackEntry = stackEntry->m_caller));
+} while (stackEntry->m_inlineCallFrame && stackEntry->m_inlineCallFrame->kind == InlineCallFrame::TailCall && (stackEntry = stackEntry->m_caller));
 
 // The tail call was not recursive
 return false;






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-10-19 Thread sbarati

Title: [223727] trunk/Source/_javascript_Core








Revision 223727
Author sbar...@apple.com
Date 2017-10-19 16:34:20 -0700 (Thu, 19 Oct 2017)


Log Message
re-inline ObjectAllocationProfile::initializeProfile
https://bugs.webkit.org/show_bug.cgi?id=178532

Rubber stamped by Michael Saboff.

I un-inlined this function when implementing poly proto.
This patch re-inlines it. In my testing, it looks like it
might be a 0.5% speedometer progression to inline it.

* _javascript_Core.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/CodeBlock.cpp:
* bytecode/ObjectAllocationProfile.cpp: Removed.
* bytecode/ObjectAllocationProfileInlines.h: Copied from Source/_javascript_Core/bytecode/ObjectAllocationProfile.cpp.
(JSC::ObjectAllocationProfile::initializeProfile):
(JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
* runtime/FunctionRareData.cpp:

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/CodeBlock.cpp
trunk/Source/_javascript_Core/runtime/FunctionRareData.cpp


Added Paths

trunk/Source/_javascript_Core/bytecode/ObjectAllocationProfileInlines.h


Removed Paths

trunk/Source/_javascript_Core/bytecode/ObjectAllocationProfile.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (223726 => 223727)

--- trunk/Source/_javascript_Core/ChangeLog	2017-10-19 23:34:16 UTC (rev 223726)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-10-19 23:34:20 UTC (rev 223727)
@@ -1,3 +1,23 @@
+2017-10-19  Saam Barati  
+
+re-inline ObjectAllocationProfile::initializeProfile
+https://bugs.webkit.org/show_bug.cgi?id=178532
+
+Rubber stamped by Michael Saboff.
+
+I un-inlined this function when implementing poly proto.
+This patch re-inlines it. In my testing, it looks like it
+might be a 0.5% speedometer progression to inline it.
+
+* _javascript_Core.xcodeproj/project.pbxproj:
+* Sources.txt:
+* bytecode/CodeBlock.cpp:
+* bytecode/ObjectAllocationProfile.cpp: Removed.
+* bytecode/ObjectAllocationProfileInlines.h: Copied from Source/_javascript_Core/bytecode/ObjectAllocationProfile.cpp.
+(JSC::ObjectAllocationProfile::initializeProfile):
+(JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
+* runtime/FunctionRareData.cpp:
+
 2017-10-19  Michael Saboff  
 
 Test262: RegExp/property-escapes/generated/Emoji_Component.js fails with current RegExp Unicode Properties implementation


Modified: trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj (223726 => 223727)

--- trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj	2017-10-19 23:34:16 UTC (rev 223726)
+++ trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj	2017-10-19 23:34:20 UTC (rev 223727)
@@ -1072,6 +1072,7 @@
 		79A090801D768465008B889B /* HashMapImpl.h in Headers */ = {isa = PBXBuildFile; fileRef = 79A0907E1D768465008B889B /* HashMapImpl.h */; settings = {ATTRIBUTES = (Private, ); }; };
 		79A228361D35D71F00D8E067 /* ArithProfile.h in Headers */ = {isa = PBXBuildFile; fileRef = 79A228341D35D71E00D8E067 /* ArithProfile.h */; };
 		79ABB17E1E5CCB570045B9A6 /* AirDisassembler.h in Headers */ = {isa = PBXBuildFile; fileRef = 79ABB17C1E5CCB570045B9A6 /* AirDisassembler.h */; settings = {ATTRIBUTES = (Private, ); }; };
+		79AC30FF1F99536400484FD7 /* ObjectAllocationProfileInlines.h in Headers */ = {isa = PBXBuildFile; fileRef = 79AC30FE1F99536300484FD7 /* ObjectAllocationProfileInlines.h */; };
 		79AF0BE41D3EFD4C00E95FA5 /* JITMathICInlineResult.h in Headers */ = {isa = PBXBuildFile; fileRef = 79AF0BE31D3EFD4C00E95FA5 /* JITMathICInlineResult.h */; settings = {ATTRIBUTES = (Private, ); }; };
 		79B00CBD1C6AB07E0088C65D /* ProxyConstructor.h in Headers */ = {isa = PBXBuildFile; fileRef = 79B00CB91C6AB07E0088C65D /* ProxyConstructor.h */; settings = {ATTRIBUTES = (Private, ); }; };
 		79B00CBF1C6AB07E0088C65D /* ProxyObject.h in Headers */ = {isa = PBXBuildFile; fileRef = 79B00CBB1C6AB07E0088C65D /* ProxyObject.h */; settings = {ATTRIBUTES = (Private, ); }; };
@@ -3528,6 +3529,7 @@
 		79A899FE1D38612E00D18C73 /* JITMathICForwards.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = JITMathICForwards.h; sourceTree = ""; };
 		79ABB17B1E5CCB570045B9A6 /* AirDisassembler.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; name = AirDisassembler.cpp; path = b3/air/AirDisassembler.cpp; sourceTree = ""; };
 		79ABB17C1E5CCB570045B9A6 /* AirDisassembler.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = AirDisassembler.h; path = b3/air/AirDisassembler.h; sourceTree = ""; };
+		79AC30FE1F99536300484FD7 /* ObjectAllocationProfileInlines.h */ = {isa =

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

2017-10-19 Thread sbarati

Title: [223715] trunk/Source/_javascript_Core








Revision 223715
Author sbar...@apple.com
Date 2017-10-19 15:23:58 -0700 (Thu, 19 Oct 2017)


Log Message
We should hard code the poly proto offset
https://bugs.webkit.org/show_bug.cgi?id=178531

Reviewed by Filip Pizlo.

This patch embraces that the poly proto offset is always zero. It's already
the case that we would always get the inline offset zero for poly proto just
by construction. This just hardcodes this assumption throughout the codebase.
This appears to be a 1% speedometer progression in my testing.

The downside of this patch is that it may require changing how we do
things when we implement poly proto when inheriting from builtin
types. I think we can face this problem when we decide to implement
that.

* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateWithGuard):
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
(JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
(JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_instanceof):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_instanceof):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSObject.cpp:
(JSC::JSObject::setPrototypeDirect):
* runtime/JSObject.h:
(JSC::JSObject::locationForOffset const):
(JSC::JSObject::locationForOffset):
(JSC::JSObject::getDirect const):
* runtime/PropertyOffset.h:
* runtime/Structure.cpp:
(JSC::Structure::create):
(JSC::Structure::dump const):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::storedPrototype const):
(JSC::Structure::storedPrototypeObject const):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/AccessCase.cpp
trunk/Source/_javascript_Core/dfg/DFGOperations.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
trunk/Source/_javascript_Core/jit/JITOpcodes.cpp
trunk/Source/_javascript_Core/jit/JITOpcodes32_64.cpp
trunk/Source/_javascript_Core/runtime/CommonSlowPaths.cpp
trunk/Source/_javascript_Core/runtime/JSObject.cpp
trunk/Source/_javascript_Core/runtime/JSObject.h
trunk/Source/_javascript_Core/runtime/PropertyOffset.h
trunk/Source/_javascript_Core/runtime/Structure.cpp
trunk/Source/_javascript_Core/runtime/Structure.h
trunk/Source/_javascript_Core/runtime/StructureInlines.h




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (223714 => 223715)

--- trunk/Source/_javascript_Core/ChangeLog	2017-10-19 21:58:48 UTC (rev 223714)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-10-19 22:23:58 UTC (rev 223715)
@@ -1,5 +1,52 @@
 2017-10-19  Saam Barati  
 
+We should hard code the poly proto offset
+https://bugs.webkit.org/show_bug.cgi?id=178531
+
+Reviewed by Filip Pizlo.
+
+This patch embraces that the poly proto offset is always zero. It's already
+the case that we would always get the inline offset zero for poly proto just
+by construction. This just hardcodes this assumption throughout the codebase.
+This appears to be a 1% speedometer progression in my testing.
+
+The downside of this patch is that it may require changing how we do
+things when we implement poly proto when inheriting from builtin
+types. I think we can face this problem when we decide to implement
+that.
+
+* bytecode/AccessCase.cpp:
+(JSC::AccessCase::generateWithGuard):
+* dfg/DFGOperations.cpp:
+* dfg/DFGSpeculativeJIT.cpp:
+(JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
+(JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
+* ftl/FTLLowerDFGToB3.cpp:
+(JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
+(JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
+* jit/JITOpcodes.cpp:
+(JSC::JIT::emit_op_instanceof):
+* jit/JITOpcodes32_64.cpp:
+(JSC::JIT::emit_op_instanceof):
+* runtime/CommonSlowPaths.cpp:
+(JSC::SLOW_PATH_DECL):
+* runtime/JSObject.cpp:
+(JSC::JSObject::setPrototypeDirect):
+* runtime/JSObject.h:
+(JSC::JSObject::locationForOffset const):
+(JSC::JSObject::locationForOffset):
+(JSC::JSObject::getDirect const):
+* runtime/PropertyOffset.h:
+* runtime/Structure.cpp:
+(JSC::Structure::create):
+(JSC::Structure::dump const):
+* runtime/Structure.h:
+* runtime/StructureInlines.h:
+(JSC::Structure::storedPrototype const):
+(JSC::Structure::storedPrototypeObject const):
+
+2017-10-19  Saam Barati  
+
 Turn various poly proto RELEASE_ASSERTs into ASSERTs because they're on the hot path in speedometer
 https://bugs.webkit.org/show_bug.cgi?id=178529

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

2017-10-19 Thread sbarati

Title: [223709] trunk/Source/_javascript_Core








Revision 223709
Author sbar...@apple.com
Date 2017-10-19 13:45:54 -0700 (Thu, 19 Oct 2017)


Log Message
Turn various poly proto RELEASE_ASSERTs into ASSERTs because they're on the hot path in speedometer
https://bugs.webkit.org/show_bug.cgi?id=178529

Reviewed by Mark Lam.

* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::storedPrototypeObject const):
(JSC::Structure::storedPrototypeStructure const):
(JSC::Structure::storedPrototype const):
(JSC::Structure::prototypeForLookup const):
(JSC::Structure::prototypeChain const):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/Structure.h
trunk/Source/_javascript_Core/runtime/StructureInlines.h




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (223708 => 223709)

--- trunk/Source/_javascript_Core/ChangeLog	2017-10-19 20:43:41 UTC (rev 223708)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-10-19 20:45:54 UTC (rev 223709)
@@ -1,5 +1,20 @@
 2017-10-19  Saam Barati  
 
+Turn various poly proto RELEASE_ASSERTs into ASSERTs because they're on the hot path in speedometer
+https://bugs.webkit.org/show_bug.cgi?id=178529
+
+Reviewed by Mark Lam.
+
+* runtime/Structure.h:
+* runtime/StructureInlines.h:
+(JSC::Structure::storedPrototypeObject const):
+(JSC::Structure::storedPrototypeStructure const):
+(JSC::Structure::storedPrototype const):
+(JSC::Structure::prototypeForLookup const):
+(JSC::Structure::prototypeChain const):
+
+2017-10-19  Saam Barati  
+
 Turn poly proto back on by default and remove the option
 https://bugs.webkit.org/show_bug.cgi?id=178525
 


Modified: trunk/Source/_javascript_Core/runtime/Structure.h (223708 => 223709)

--- trunk/Source/_javascript_Core/runtime/Structure.h	2017-10-19 20:43:41 UTC (rev 223708)
+++ trunk/Source/_javascript_Core/runtime/Structure.h	2017-10-19 20:45:54 UTC (rev 223709)
@@ -262,22 +262,22 @@
 // object of a structure is presumed to be immutable in a bunch of places.
 void setGlobalObject(VM& vm, JSGlobalObject* globalObject) { m_globalObject.set(vm, this, globalObject); }
 
-bool hasMonoProto() const
+ALWAYS_INLINE bool hasMonoProto() const
 {
 return !m_prototype.get().isInt32();
 }
-bool hasPolyProto() const
+ALWAYS_INLINE bool hasPolyProto() const
 {
 return !hasMonoProto();
 }
-JSValue storedPrototype() const
+ALWAYS_INLINE JSValue storedPrototype() const
 {
-RELEASE_ASSERT(hasMonoProto());
+ASSERT(hasMonoProto());
 return m_prototype.get();
 }
-PropertyOffset polyProtoOffset() const
+ALWAYS_INLINE PropertyOffset polyProtoOffset() const
 {
-RELEASE_ASSERT(hasPolyProto());
+ASSERT(hasPolyProto());
 return m_prototype.get().asInt32();
 }
 JSValue storedPrototype(const JSObject*) const;


Modified: trunk/Source/_javascript_Core/runtime/StructureInlines.h (223708 => 223709)

--- trunk/Source/_javascript_Core/runtime/StructureInlines.h	2017-10-19 20:43:41 UTC (rev 223708)
+++ trunk/Source/_javascript_Core/runtime/StructureInlines.h	2017-10-19 20:45:54 UTC (rev 223709)
@@ -61,7 +61,7 @@
 
 inline JSObject* Structure::storedPrototypeObject() const
 {
-RELEASE_ASSERT(hasMonoProto());
+ASSERT(hasMonoProto());
 JSValue value = m_prototype.get();
 if (value.isNull())
 return nullptr;
@@ -70,7 +70,7 @@
 
 inline Structure* Structure::storedPrototypeStructure() const
 {
-RELEASE_ASSERT(hasMonoProto());
+ASSERT(hasMonoProto());
 JSObject* object = storedPrototypeObject();
 if (!object)
 return nullptr;
@@ -79,10 +79,10 @@
 
 ALWAYS_INLINE JSValue Structure::storedPrototype(const JSObject* object) const
 {
-RELEASE_ASSERT(object->structure() == this);
+ASSERT(object->structure() == this);
 if (hasMonoProto())
 return storedPrototype();
-RELEASE_ASSERT(m_prototype.get().isInt32());
+ASSERT(m_prototype.get().isInt32());
 PropertyOffset offset = m_prototype.get().asInt32();
 return object->getDirect(offset);
 }
@@ -89,7 +89,7 @@
 
 ALWAYS_INLINE JSObject* Structure::storedPrototypeObject(const JSObject* object) const
 {
-RELEASE_ASSERT(object->structure() == this);
+ASSERT(object->structure() == this);
 if (hasMonoProto())
 return storedPrototypeObject();
 JSValue proto = object->getDirect(polyProtoOffset());
@@ -210,7 +210,7 @@
 
 inline JSValue Structure::prototypeForLookup(JSGlobalObject* globalObject) const
 {
-RELEASE_ASSERT(hasMonoProto());
+ASSERT(hasMonoProto());
 if (isObject())
 return storedPrototype();
 return prototypeForLookupPrimitiveImpl(globalObject, this);
@@ -218,7 +218,7 @@
 
 inline JSValue Structure::prototypeForLookup(JSGlobalObject* globalObject, JSCell* base) const
 {
-

[webkit-changes] [223703] trunk

2017-10-19 Thread sbarati

Title: [223703] trunk








Revision 223703
Author sbar...@apple.com
Date 2017-10-19 13:16:19 -0700 (Thu, 19 Oct 2017)


Log Message
Turn poly proto back on by default and remove the option
https://bugs.webkit.org/show_bug.cgi?id=178525

Reviewed by Mark Lam.

Source/_javascript_Core:

I added this option because I thought it'd speed speedometer up because the
original poly proto patch slowed speedometer down. It turns out that
allocating poly proto objects is not what slows speedometer down. It's
other code I added in the runtime that needs to be poly proto aware. I'll
be addressing these in follow up patches.

* runtime/Options.h:
* runtime/StructureInlines.h:
(JSC::Structure::shouldConvertToPolyProto):

Tools:

* Scripts/run-jsc-stress-tests:

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/Options.h
trunk/Source/_javascript_Core/runtime/StructureInlines.h
trunk/Tools/ChangeLog
trunk/Tools/Scripts/run-jsc-stress-tests




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (223702 => 223703)

--- trunk/Source/_javascript_Core/ChangeLog	2017-10-19 20:15:42 UTC (rev 223702)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-10-19 20:16:19 UTC (rev 223703)
@@ -1,3 +1,20 @@
+2017-10-19  Saam Barati  
+
+Turn poly proto back on by default and remove the option
+https://bugs.webkit.org/show_bug.cgi?id=178525
+
+Reviewed by Mark Lam.
+
+I added this option because I thought it'd speed speedometer up because the
+original poly proto patch slowed speedometer down. It turns out that
+allocating poly proto objects is not what slows speedometer down. It's
+other code I added in the runtime that needs to be poly proto aware. I'll
+be addressing these in follow up patches.
+
+* runtime/Options.h:
+* runtime/StructureInlines.h:
+(JSC::Structure::shouldConvertToPolyProto):
+
 2017-10-19  Robin Morisset  
 
 Turn recursive tail calls into loops


Modified: trunk/Source/_javascript_Core/runtime/Options.h (223702 => 223703)

--- trunk/Source/_javascript_Core/runtime/Options.h	2017-10-19 20:15:42 UTC (rev 223702)
+++ trunk/Source/_javascript_Core/runtime/Options.h	2017-10-19 20:16:19 UTC (rev 223703)
@@ -473,7 +473,6 @@
 v(bool, useCallICsForWebAssemblyToJSCalls, true, Normal, "If true, we will use CallLinkInfo to inline cache Wasm to JS calls.") \
 v(bool, useObjectRestSpread, true, Normal, "If true, we will enable Object Rest/Spread feature.") \
 v(bool, useArrayAllocationProfiling, true, Normal, "If true, we will use our normal array allocation profiling. If false, the allocation profile will always claim to be undecided.")\
-v(bool, usePolyProto, false, Normal, "If true, we may convert allocations to generate poly proto structures.") \
 v(bool, forcePolyProto, false, Normal, "If true, create_this will always create an object with a poly proto structure.")
 
 


Modified: trunk/Source/_javascript_Core/runtime/StructureInlines.h (223702 => 223703)

--- trunk/Source/_javascript_Core/runtime/StructureInlines.h	2017-10-19 20:15:42 UTC (rev 223702)
+++ trunk/Source/_javascript_Core/runtime/StructureInlines.h	2017-10-19 20:16:19 UTC (rev 223703)
@@ -447,9 +447,6 @@
 
 ALWAYS_INLINE bool Structure::shouldConvertToPolyProto(const Structure* a, const Structure* b)
 {
-if (!Options::usePolyProto())
-return false;
-
 if (!a || !b)
 return false;
 


Modified: trunk/Tools/ChangeLog (223702 => 223703)

--- trunk/Tools/ChangeLog	2017-10-19 20:15:42 UTC (rev 223702)
+++ trunk/Tools/ChangeLog	2017-10-19 20:16:19 UTC (rev 223703)
@@ -1,3 +1,12 @@
+2017-10-19  Saam Barati  
+
+Turn poly proto back on by default and remove the option
+https://bugs.webkit.org/show_bug.cgi?id=178525
+
+Reviewed by Mark Lam.
+
+* Scripts/run-jsc-stress-tests:
+
 2017-10-18  Ryosuke Niwa  
 
 Don't expose raw HTML in pasteboard to the web content


Modified: trunk/Tools/Scripts/run-jsc-stress-tests (223702 => 223703)

--- trunk/Tools/Scripts/run-jsc-stress-tests	2017-10-19 20:15:42 UTC (rev 223702)
+++ trunk/Tools/Scripts/run-jsc-stress-tests	2017-10-19 20:16:19 UTC (rev 223703)
@@ -451,13 +451,13 @@
 $numPasses = 0
 
 # We force all tests to use a smaller (1.5M) stack so that stack overflow tests can run faster.
-BASE_OPTIONS = ["--useFTLJIT=false", "--useFunctionDotArguments=true", "--validateExceptionChecks=true", "--maxPerThreadStackUsage=1572864", "--usePolyProto=true"]
-EAGER_OPTIONS = ["--thresholdForJITAfterWarmUp=10", "--thresholdForJITSoon=10", "--thresholdForOptimizeAfterWarmUp=20", "--thresholdForOptimizeAfterLongWarmUp=20", "--thresholdForOptimizeSoon=20", "--thresholdForFTLOptimizeAfterWarmUp=20", "--thresholdForFTLOptimizeSoon=20", "--maximumEvalCacheableSourceLength=15", "--useEagerCodeBlockJettisonTiming=true", "--usePolyProto=true"]

[webkit-changes] [223222] trunk

2017-10-11 Thread sbarati

Title: [223222] trunk








Revision 223222
Author sbar...@apple.com
Date 2017-10-11 17:53:45 -0700 (Wed, 11 Oct 2017)


Log Message
Runtime disable poly proto because it may be a 3-4% Speedometer regression
https://bugs.webkit.org/show_bug.cgi?id=178192

Reviewed by JF Bastien.

Source/_javascript_Core:

* runtime/Options.h:
* runtime/StructureInlines.h:
(JSC::Structure::shouldConvertToPolyProto):

Tools:

* Scripts/run-jsc-stress-tests:

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/Options.h
trunk/Source/_javascript_Core/runtime/StructureInlines.h
trunk/Tools/ChangeLog
trunk/Tools/Scripts/run-jsc-stress-tests




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (223221 => 223222)

--- trunk/Source/_javascript_Core/ChangeLog	2017-10-12 00:47:44 UTC (rev 223221)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-10-12 00:53:45 UTC (rev 223222)
@@ -1,3 +1,14 @@
+2017-10-11  Saam Barati  
+
+Runtime disable poly proto because it may be a 3-4% Speedometer regression
+https://bugs.webkit.org/show_bug.cgi?id=178192
+
+Reviewed by JF Bastien.
+
+* runtime/Options.h:
+* runtime/StructureInlines.h:
+(JSC::Structure::shouldConvertToPolyProto):
+
 2017-10-11  Commit Queue  
 
 Unreviewed, rolling out r223113 and r223121.


Modified: trunk/Source/_javascript_Core/runtime/Options.h (223221 => 223222)

--- trunk/Source/_javascript_Core/runtime/Options.h	2017-10-12 00:47:44 UTC (rev 223221)
+++ trunk/Source/_javascript_Core/runtime/Options.h	2017-10-12 00:53:45 UTC (rev 223222)
@@ -473,6 +473,7 @@
 v(bool, useCallICsForWebAssemblyToJSCalls, true, Normal, "If true, we will use CallLinkInfo to inline cache Wasm to JS calls.") \
 v(bool, useObjectRestSpread, true, Normal, "If true, we will enable Object Rest/Spread feature.") \
 v(bool, useArrayAllocationProfiling, true, Normal, "If true, we will use our normal array allocation profiling. If false, the allocation profile will always claim to be undecided.")\
+v(bool, usePolyProto, false, Normal, "If true, we may convert allocations to generate poly proto structures.") \
 v(bool, forcePolyProto, false, Normal, "If true, create_this will always create an object with a poly proto structure.")
 
 


Modified: trunk/Source/_javascript_Core/runtime/StructureInlines.h (223221 => 223222)

--- trunk/Source/_javascript_Core/runtime/StructureInlines.h	2017-10-12 00:47:44 UTC (rev 223221)
+++ trunk/Source/_javascript_Core/runtime/StructureInlines.h	2017-10-12 00:53:45 UTC (rev 223222)
@@ -447,6 +447,9 @@
 
 ALWAYS_INLINE bool Structure::shouldConvertToPolyProto(const Structure* a, const Structure* b)
 {
+if (!Options::usePolyProto())
+return false;
+
 if (!a || !b)
 return false;
 


Modified: trunk/Tools/ChangeLog (223221 => 223222)

--- trunk/Tools/ChangeLog	2017-10-12 00:47:44 UTC (rev 223221)
+++ trunk/Tools/ChangeLog	2017-10-12 00:53:45 UTC (rev 223222)
@@ -1,3 +1,12 @@
+2017-10-11  Saam Barati  
+
+Runtime disable poly proto because it may be a 3-4% Speedometer regression
+https://bugs.webkit.org/show_bug.cgi?id=178192
+
+Reviewed by JF Bastien.
+
+* Scripts/run-jsc-stress-tests:
+
 2017-10-11  Youenn Fablet  
 
 Add API to clean CacheStorage data


Modified: trunk/Tools/Scripts/run-jsc-stress-tests (223221 => 223222)

--- trunk/Tools/Scripts/run-jsc-stress-tests	2017-10-12 00:47:44 UTC (rev 223221)
+++ trunk/Tools/Scripts/run-jsc-stress-tests	2017-10-12 00:53:45 UTC (rev 223222)
@@ -451,13 +451,13 @@
 $numPasses = 0
 
 # We force all tests to use a smaller (1.5M) stack so that stack overflow tests can run faster.
-BASE_OPTIONS = ["--useFTLJIT=false", "--useFunctionDotArguments=true", "--validateExceptionChecks=true", "--maxPerThreadStackUsage=1572864"]
-EAGER_OPTIONS = ["--thresholdForJITAfterWarmUp=10", "--thresholdForJITSoon=10", "--thresholdForOptimizeAfterWarmUp=20", "--thresholdForOptimizeAfterLongWarmUp=20", "--thresholdForOptimizeSoon=20", "--thresholdForFTLOptimizeAfterWarmUp=20", "--thresholdForFTLOptimizeSoon=20", "--maximumEvalCacheableSourceLength=15", "--useEagerCodeBlockJettisonTiming=true"]
+BASE_OPTIONS = ["--useFTLJIT=false", "--useFunctionDotArguments=true", "--validateExceptionChecks=true", "--maxPerThreadStackUsage=1572864", "--usePolyProto=true"]
+EAGER_OPTIONS = ["--thresholdForJITAfterWarmUp=10", "--thresholdForJITSoon=10", "--thresholdForOptimizeAfterWarmUp=20", "--thresholdForOptimizeAfterLongWarmUp=20", "--thresholdForOptimizeSoon=20", "--thresholdForFTLOptimizeAfterWarmUp=20", "--thresholdForFTLOptimizeSoon=20", "--maximumEvalCacheableSourceLength=15", "--useEagerCodeBlockJettisonTiming=true", "--usePolyProto=true"]
 # NOTE: Tests rely on this using scribbleFreeCells.
-NO_CJIT_OPTIONS = ["--useConcurrentJIT=false", "--thresholdForJITAfterWarmUp=100",

[webkit-changes] [223214] trunk/JSTests

2017-10-11 Thread sbarati

Title: [223214] trunk/JSTests








Revision 223214
Author sbar...@apple.com
Date 2017-10-11 17:00:57 -0700 (Wed, 11 Oct 2017)


Log Message
Unreviewed. Actually skip certain type profiler tests in debug.

* typeProfiler.yaml:
* typeProfiler/deltablue-for-of.js:
* typeProfiler/getter-richards.js:

Modified Paths

trunk/JSTests/ChangeLog
trunk/JSTests/typeProfiler/deltablue-for-of.js
trunk/JSTests/typeProfiler/getter-richards.js
trunk/JSTests/typeProfiler.yaml




Diff

Modified: trunk/JSTests/ChangeLog (223213 => 223214)

--- trunk/JSTests/ChangeLog	2017-10-11 23:55:11 UTC (rev 223213)
+++ trunk/JSTests/ChangeLog	2017-10-12 00:00:57 UTC (rev 223214)
@@ -1,3 +1,11 @@
+2017-10-11  Saam Barati  
+
+Unreviewed. Actually skip certain type profiler tests in debug.
+
+* typeProfiler.yaml:
+* typeProfiler/deltablue-for-of.js:
+* typeProfiler/getter-richards.js:
+
 2017-10-11  Commit Queue  
 
 Unreviewed, rolling out r223113 and r223121.


Modified: trunk/JSTests/typeProfiler/deltablue-for-of.js (223213 => 223214)

--- trunk/JSTests/typeProfiler/deltablue-for-of.js	2017-10-11 23:55:11 UTC (rev 223213)
+++ trunk/JSTests/typeProfiler/deltablue-for-of.js	2017-10-12 00:00:57 UTC (rev 223214)
@@ -1,4 +1,4 @@
-//@ skip if $buildType == "debug"
+//@ if $buildType == "debug" then skip else runTypeProfiler end
 
 // Copyright 2008 the V8 project authors. All rights reserved.
 // Copyright 1996 John Maloney and Mario Wolczko.


Modified: trunk/JSTests/typeProfiler/getter-richards.js (223213 => 223214)

--- trunk/JSTests/typeProfiler/getter-richards.js	2017-10-11 23:55:11 UTC (rev 223213)
+++ trunk/JSTests/typeProfiler/getter-richards.js	2017-10-12 00:00:57 UTC (rev 223214)
@@ -1,4 +1,4 @@
-//@ skip if $buildType == "debug"
+//@ if $buildType == "debug" then skip else runTypeProfiler end
 
 // Copyright 2006-2008 the V8 project authors. All rights reserved.
 // Copyright 2014 Apple Inc.


Modified: trunk/JSTests/typeProfiler.yaml (223213 => 223214)

--- trunk/JSTests/typeProfiler.yaml	2017-10-11 23:55:11 UTC (rev 223213)
+++ trunk/JSTests/typeProfiler.yaml	2017-10-12 00:00:57 UTC (rev 223214)
@@ -22,4 +22,4 @@
 # THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 - path: typeProfiler
-  cmd: runTypeProfiler
+  cmd: runTypeProfiler unless parseRunCommands






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-10-10 Thread sbarati

Title: [223161] trunk/Source/_javascript_Core








Revision 223161
Author sbar...@apple.com
Date 2017-10-10 17:53:59 -0700 (Tue, 10 Oct 2017)


Log Message
Prototype structure transition should be a deferred transition
https://bugs.webkit.org/show_bug.cgi?id=177734

Reviewed by Keith Miller.

Absence ObjectPropertyConditions work by verifying both that the Structure
does not have a particular property and that its prototype has
remained constant. However, the prototype transition was firing
the transition watchpoint before setting the object's structure.
This meant that isValid for Absence would never return false because
the prototype changed. Clearly this is wrong. The reason this didn't
break OPCs in general is that we'd also check if we could still watch
the OPC. In this case, we can't still watch it because we're inspecting
a structure with an invalidated transition watchpoint. To fix
this weird quirk of the code, I'm making it so that doing a prototype
transition uses the DeferredStructureTransitionWatchpointFire machinery.

This patch also fixes some dead code that I left in regarding
poly proto in OPC.

* bytecode/PropertyCondition.cpp:
(JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
* runtime/JSObject.cpp:
(JSC::JSObject::setPrototypeDirect):
* runtime/Structure.cpp:
(JSC::Structure::changePrototypeTransition):
* runtime/Structure.h:

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/PropertyCondition.cpp
trunk/Source/_javascript_Core/runtime/JSObject.cpp
trunk/Source/_javascript_Core/runtime/Structure.cpp
trunk/Source/_javascript_Core/runtime/Structure.h




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (223160 => 223161)

--- trunk/Source/_javascript_Core/ChangeLog	2017-10-11 00:37:49 UTC (rev 223160)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-10-11 00:53:59 UTC (rev 223161)
@@ -1,3 +1,33 @@
+2017-10-10  Saam Barati  
+
+Prototype structure transition should be a deferred transition
+https://bugs.webkit.org/show_bug.cgi?id=177734
+
+Reviewed by Keith Miller.
+
+Absence ObjectPropertyConditions work by verifying both that the Structure 
+does not have a particular property and that its prototype has
+remained constant. However, the prototype transition was firing
+the transition watchpoint before setting the object's structure.
+This meant that isValid for Absence would never return false because
+the prototype changed. Clearly this is wrong. The reason this didn't
+break OPCs in general is that we'd also check if we could still watch
+the OPC. In this case, we can't still watch it because we're inspecting
+a structure with an invalidated transition watchpoint. To fix
+this weird quirk of the code, I'm making it so that doing a prototype
+transition uses the DeferredStructureTransitionWatchpointFire machinery.
+
+This patch also fixes some dead code that I left in regarding
+poly proto in OPC.
+
+* bytecode/PropertyCondition.cpp:
+(JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
+* runtime/JSObject.cpp:
+(JSC::JSObject::setPrototypeDirect):
+* runtime/Structure.cpp:
+(JSC::Structure::changePrototypeTransition):
+* runtime/Structure.h:
+
 2017-10-10  Robin Morisset  
 
 Avoid allocating useless landingBlocks in DFGByteCodeParser::handleInlining()


Modified: trunk/Source/_javascript_Core/bytecode/PropertyCondition.cpp (223160 => 223161)

--- trunk/Source/_javascript_Core/bytecode/PropertyCondition.cpp	2017-10-11 00:37:49 UTC (rev 223160)
+++ trunk/Source/_javascript_Core/bytecode/PropertyCondition.cpp	2017-10-11 00:53:59 UTC (rev 223161)
@@ -122,15 +122,7 @@
 return false;
 }
 
-JSObject* currentPrototype;
-if (structure->hasMonoProto())
-currentPrototype = structure->storedPrototypeObject();
-else {
-RELEASE_ASSERT(base);
-currentPrototype = jsDynamicCast(*structure->vm(), base->getPrototypeDirect());
-}
-
-if (currentPrototype != prototype()) {
+if (structure->storedPrototypeObject() != prototype()) {
 if (PropertyConditionInternal::verbose) {
 dataLog(
 "Invalid because the prototype is ", structure->storedPrototype(), " even though "


Modified: trunk/Source/_javascript_Core/runtime/JSObject.cpp (223160 => 223161)

--- trunk/Source/_javascript_Core/runtime/JSObject.cpp	2017-10-11 00:37:49 UTC (rev 223160)
+++ trunk/Source/_javascript_Core/runtime/JSObject.cpp	2017-10-11 00:53:59 UTC (rev 223161)
@@ -1634,7 +1634,8 @@
 prototype.asCell()->didBecomePrototype();
 
 if (structure(vm)->hasMonoProto()) {
-Structure* newStructure =

[webkit-changes] [223125] trunk

2017-10-10 Thread sbarati

Title: [223125] trunk








Revision 223125
Author sbar...@apple.com
Date 2017-10-10 00:58:27 -0700 (Tue, 10 Oct 2017)


Log Message
The prototype cache should be aware of the Executable it generates a Structure for
https://bugs.webkit.org/show_bug.cgi?id=177907

Reviewed by Filip Pizlo.

JSTests:

* microbenchmarks/dont-confuse-structures-from-different-executable-as-poly-proto.js: Added.
(assert):
(foo.C):
(foo):
(bar.C):
(bar):
(access):
(makeLongChain):
(accessY):

Source/_javascript_Core:

This patch renames PrototypeMap to StructureCache because
it is no longer a map of the prototypes in the VM. It's
only used to cache Structures during object construction.

The main change of this patch is to guarantee that Structures generated
by the create_this originating from different two different Executables'
bytecode won't hash-cons to the same thing. Previously, we could hash-cons
them depending on the JSObject* prototype pointer. This would cause the last
thing that hash-consed to overwrite the Structure's poly proto watchpoint. This
happened because when we initialize a JSFunction's ObjectAllocationProfile,
we set the resulting Structure's poly proto watchpoint. This could cause a Structure
generating from some Executable e1 to end up with the poly proto watchpoint
for another Executable e2 simply because JSFunctions backed by e1 and e2
shared the same prototype. Then, based on profiling information, we may fire the
wrong Executable's poly proto watchpoint. This patch fixes this bug by
guaranteeing that Structures generating from create_this for different
Executables are unique even if they share the same prototype by adding
the FunctionExecutable* as another field in PrototypeKey.

* _javascript_Core.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/InternalFunctionAllocationProfile.h:
(JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
* bytecode/ObjectAllocationProfile.cpp:
(JSC::ObjectAllocationProfile::initializeProfile):
* dfg/DFGOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::createSubclassStructureSlow):
* runtime/IteratorOperations.cpp:
(JSC::createIteratorResultObjectStructure):
* runtime/JSBoundFunction.cpp:
(JSC::getBoundFunctionStructure):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/ObjectConstructor.h:
(JSC::constructEmptyObject):
* runtime/PrototypeKey.h:
(JSC::PrototypeKey::PrototypeKey):
(JSC::PrototypeKey::executable const):
(JSC::PrototypeKey::operator== const):
(JSC::PrototypeKey::hash const):
* runtime/PrototypeMap.cpp: Removed.
* runtime/PrototypeMap.h: Removed.
* runtime/StructureCache.cpp: Copied from Source/_javascript_Core/runtime/PrototypeMap.cpp.
(JSC::StructureCache::createEmptyStructure):
(JSC::StructureCache::emptyStructureForPrototypeFromBaseStructure):
(JSC::StructureCache::emptyObjectStructureForPrototype):
(JSC::PrototypeMap::createEmptyStructure): Deleted.
(JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure): Deleted.
(JSC::PrototypeMap::emptyObjectStructureForPrototype): Deleted.
* runtime/StructureCache.h: Copied from Source/_javascript_Core/runtime/PrototypeMap.h.
(JSC::StructureCache::StructureCache):
(JSC::PrototypeMap::PrototypeMap): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:

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/bytecode/InternalFunctionAllocationProfile.h
trunk/Source/_javascript_Core/bytecode/ObjectAllocationProfile.cpp
trunk/Source/_javascript_Core/dfg/DFGOperations.cpp
trunk/Source/_javascript_Core/runtime/CommonSlowPaths.cpp
trunk/Source/_javascript_Core/runtime/InternalFunction.cpp
trunk/Source/_javascript_Core/runtime/IteratorOperations.cpp
trunk/Source/_javascript_Core/runtime/JSBoundFunction.cpp
trunk/Source/_javascript_Core/runtime/JSGlobalObject.cpp
trunk/Source/_javascript_Core/runtime/ObjectConstructor.h
trunk/Source/_javascript_Core/runtime/PrototypeKey.h
trunk/Source/_javascript_Core/runtime/VM.cpp
trunk/Source/_javascript_Core/runtime/VM.h


Added Paths

trunk/JSTests/microbenchmarks/dont-confuse-structures-from-different-executable-as-poly-proto.js
trunk/Source/_javascript_Core/runtime/StructureCache.cpp
trunk/Source/_javascript_Core/runtime/StructureCache.h


Removed Paths

trunk/Source/_javascript_Core/runtime/PrototypeMap.cpp
trunk/Source/_javascript_Core/runtime/PrototypeMap.h




Diff

Modified: trunk/JSTests/ChangeLog (223124 => 223125)

--- trunk/JSTests/ChangeLog	2017-10-10 05:53:12 UTC (rev 223124)
+++ trunk/JSTests/ChangeLog	2017-10-10 07:58:27 UTC (rev 223125)
@@ -1,3 +1,20 @@
+2017-10-10  Saam Barati  
+
+The prototype cache should be aware of the Executable it generates a Structure for
+https://bugs.webkit.org/show_bug.cgi?id=177907
+
+Reviewed by

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

2017-10-09 Thread sbarati

Title: [223123] trunk/Source/_javascript_Core








Revision 223123
Author sbar...@apple.com
Date 2017-10-09 22:11:27 -0700 (Mon, 09 Oct 2017)


Log Message
We don't need to clearEmptyObjectStructureForPrototype because JSGlobalObject* is part of the cache's key
https://bugs.webkit.org/show_bug.cgi?id=177987

Reviewed by Filip Pizlo.

* runtime/JSProxy.cpp:
(JSC::JSProxy::setTarget):
* runtime/PrototypeMap.cpp:
(JSC::PrototypeMap::clearEmptyObjectStructureForPrototype): Deleted.
* runtime/PrototypeMap.h:

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/JSProxy.cpp
trunk/Source/_javascript_Core/runtime/PrototypeMap.cpp
trunk/Source/_javascript_Core/runtime/PrototypeMap.h




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (223122 => 223123)

--- trunk/Source/_javascript_Core/ChangeLog	2017-10-10 04:44:51 UTC (rev 223122)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-10-10 05:11:27 UTC (rev 223123)
@@ -1,3 +1,16 @@
+2017-10-09  Saam Barati  
+
+We don't need to clearEmptyObjectStructureForPrototype because JSGlobalObject* is part of the cache's key
+https://bugs.webkit.org/show_bug.cgi?id=177987
+
+Reviewed by Filip Pizlo.
+
+* runtime/JSProxy.cpp:
+(JSC::JSProxy::setTarget):
+* runtime/PrototypeMap.cpp:
+(JSC::PrototypeMap::clearEmptyObjectStructureForPrototype): Deleted.
+* runtime/PrototypeMap.h:
+
 2017-10-09  Filip Pizlo  
 
 JSCell::didBecomePrototype is racy


Modified: trunk/Source/_javascript_Core/runtime/JSProxy.cpp (223122 => 223123)

--- trunk/Source/_javascript_Core/runtime/JSProxy.cpp	2017-10-10 04:44:51 UTC (rev 223122)
+++ trunk/Source/_javascript_Core/runtime/JSProxy.cpp	2017-10-10 05:11:27 UTC (rev 223123)
@@ -45,25 +45,8 @@
 
 void JSProxy::setTarget(VM& vm, JSGlobalObject* globalObject)
 {
-ASSERT_ARG(globalObject, globalObject);
-JSGlobalObject* previousGlobalObject = jsCast(m_target.get());
-
 m_target.set(vm, this, globalObject);
 setPrototypeDirect(vm, globalObject->getPrototypeDirect());
-
-PrototypeMap& prototypeMap = vm.prototypeMap;
-if (!mayBePrototype())
-return;
-
-// previousGlobalObject cannot be null because in order for this JSProxy to be used as a prototype
-// of an object, we must have previously called setTarget() and associated it with a JSGlobalObject.
-RELEASE_ASSERT(previousGlobalObject);
-
-// This is slow but constant time. We think it's very rare for a proxy
-// to be a prototype, and reasonably rare to retarget a proxy,
-// so slow constant time is OK.
-for (size_t i = 0; i <= JSFinalObject::maxInlineCapacity(); ++i)
-prototypeMap.clearEmptyObjectStructureForPrototype(previousGlobalObject, this, i);
 }
 
 String JSProxy::className(const JSObject* object)


Modified: trunk/Source/_javascript_Core/runtime/PrototypeMap.cpp (223122 => 223123)

--- trunk/Source/_javascript_Core/runtime/PrototypeMap.cpp	2017-10-10 04:44:51 UTC (rev 223122)
+++ trunk/Source/_javascript_Core/runtime/PrototypeMap.cpp	2017-10-10 05:11:27 UTC (rev 223123)
@@ -78,10 +78,4 @@
 return createEmptyStructure(globalObject, prototype, JSFinalObject::typeInfo(), JSFinalObject::info(), JSFinalObject::defaultIndexingType, inlineCapacity, makePolyProtoStructure);
 }
 
-void PrototypeMap::clearEmptyObjectStructureForPrototype(JSGlobalObject* globalObject, JSObject* object, unsigned inlineCapacity)
-{
-m_structures.remove(PrototypeKey(object, inlineCapacity, JSFinalObject::info(), globalObject));
-m_structures.remove(PrototypeKey(nullptr, inlineCapacity, JSFinalObject::info(), globalObject));
-}
-
 } // namespace JSC


Modified: trunk/Source/_javascript_Core/runtime/PrototypeMap.h (223122 => 223123)

--- trunk/Source/_javascript_Core/runtime/PrototypeMap.h	2017-10-10 04:44:51 UTC (rev 223122)
+++ trunk/Source/_javascript_Core/runtime/PrototypeMap.h	2017-10-10 05:11:27 UTC (rev 223123)
@@ -48,7 +48,6 @@
 
 JS_EXPORT_PRIVATE Structure* emptyObjectStructureForPrototype(JSGlobalObject*, JSObject*, unsigned inlineCapacity, bool makePolyProtoStructure = false);
 JS_EXPORT_PRIVATE Structure* emptyStructureForPrototypeFromBaseStructure(JSGlobalObject*, JSObject*, Structure*);
-void clearEmptyObjectStructureForPrototype(JSGlobalObject*, JSObject*, unsigned inlineCapacity);
 
 private:
 Structure* createEmptyStructure(JSGlobalObject*, JSObject* prototype, const TypeInfo&, const ClassInfo*, IndexingType, unsigned inlineCapacity, bool makePolyProtoStructure);






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [223056] trunk/JSTests

2017-10-09 Thread sbarati

Title: [223056] trunk/JSTests








Revision 223056
Author sbar...@apple.com
Date 2017-10-09 11:37:14 -0700 (Mon, 09 Oct 2017)


Log Message
3 poly-proto JSC tests timing out on debug after r222827
https://bugs.webkit.org/show_bug.cgi?id=177880


Unreviewed.

I'm skipping these type profiler tests on debug since they are long running.

* typeProfiler/deltablue-for-of.js:
* typeProfiler/getter-richards.js:

Modified Paths

trunk/JSTests/ChangeLog
trunk/JSTests/typeProfiler/deltablue-for-of.js
trunk/JSTests/typeProfiler/getter-richards.js




Diff

Modified: trunk/JSTests/ChangeLog (223055 => 223056)

--- trunk/JSTests/ChangeLog	2017-10-09 18:13:18 UTC (rev 223055)
+++ trunk/JSTests/ChangeLog	2017-10-09 18:37:14 UTC (rev 223056)
@@ -1,3 +1,16 @@
+2017-10-09  Saam Barati  
+
+3 poly-proto JSC tests timing out on debug after r222827
+https://bugs.webkit.org/show_bug.cgi?id=177880
+
+
+Unreviewed.
+
+I'm skipping these type profiler tests on debug since they are long running.
+
+* typeProfiler/deltablue-for-of.js:
+* typeProfiler/getter-richards.js:
+
 2017-10-09  Oleksandr Skachkov  
 
 Safari 10 /11 problem with if (!await get(something)).


Modified: trunk/JSTests/typeProfiler/deltablue-for-of.js (223055 => 223056)

--- trunk/JSTests/typeProfiler/deltablue-for-of.js	2017-10-09 18:13:18 UTC (rev 223055)
+++ trunk/JSTests/typeProfiler/deltablue-for-of.js	2017-10-09 18:37:14 UTC (rev 223056)
@@ -1,3 +1,5 @@
+//@ skip if $buildType == "debug"
+
 // Copyright 2008 the V8 project authors. All rights reserved.
 // Copyright 1996 John Maloney and Mario Wolczko.
 
@@ -866,5 +868,5 @@
   projectionTest(50);
 }
 
-for (var i = 0; i < 15; ++i)
+for (var i = 0; i < 30; ++i)
 deltaBlue();


Modified: trunk/JSTests/typeProfiler/getter-richards.js (223055 => 223056)

--- trunk/JSTests/typeProfiler/getter-richards.js	2017-10-09 18:13:18 UTC (rev 223055)
+++ trunk/JSTests/typeProfiler/getter-richards.js	2017-10-09 18:37:14 UTC (rev 223056)
@@ -1,3 +1,5 @@
+//@ skip if $buildType == "debug"
+
 // Copyright 2006-2008 the V8 project authors. All rights reserved.
 // Copyright 2014 Apple Inc.
 // Redistribution and use in source and binary forms, with or without
@@ -589,5 +591,5 @@
   return "Packet";
 };
 
-for (var i = 0; i < 60; ++i)
+for (var i = 0; i < 150; ++i)
   runRichards();






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [223037] trunk/JSTests

2017-10-08 Thread sbarati

Title: [223037] trunk/JSTests








Revision 223037
Author sbar...@apple.com
Date 2017-10-08 17:44:40 -0700 (Sun, 08 Oct 2017)


Log Message
Unreviewed. Make some type profiler tests run for less time to avoid debug timeouts.

* typeProfiler/deltablue-for-of.js:
* typeProfiler/getter-richards.js:

Modified Paths

trunk/JSTests/ChangeLog
trunk/JSTests/typeProfiler/deltablue-for-of.js
trunk/JSTests/typeProfiler/getter-richards.js




Diff

Modified: trunk/JSTests/ChangeLog (223036 => 223037)

--- trunk/JSTests/ChangeLog	2017-10-09 00:11:50 UTC (rev 223036)
+++ trunk/JSTests/ChangeLog	2017-10-09 00:44:40 UTC (rev 223037)
@@ -1,3 +1,10 @@
+2017-10-08  Saam Barati  
+
+Unreviewed. Make some type profiler tests run for less time to avoid debug timeouts.
+
+* typeProfiler/deltablue-for-of.js:
+* typeProfiler/getter-richards.js:
+
 2017-10-07  Yusuke Suzuki  
 
 `async` should be able to be used as an imported binding name


Modified: trunk/JSTests/typeProfiler/deltablue-for-of.js (223036 => 223037)

--- trunk/JSTests/typeProfiler/deltablue-for-of.js	2017-10-09 00:11:50 UTC (rev 223036)
+++ trunk/JSTests/typeProfiler/deltablue-for-of.js	2017-10-09 00:44:40 UTC (rev 223037)
@@ -866,5 +866,5 @@
   projectionTest(50);
 }
 
-for (var i = 0; i < 35; ++i)
+for (var i = 0; i < 15; ++i)
 deltaBlue();


Modified: trunk/JSTests/typeProfiler/getter-richards.js (223036 => 223037)

--- trunk/JSTests/typeProfiler/getter-richards.js	2017-10-09 00:11:50 UTC (rev 223036)
+++ trunk/JSTests/typeProfiler/getter-richards.js	2017-10-09 00:44:40 UTC (rev 223037)
@@ -589,5 +589,5 @@
   return "Packet";
 };
 
-for (var i = 0; i < 150; ++i)
+for (var i = 0; i < 60; ++i)
   runRichards();






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-10-05 Thread sbarati

Title: [222929] trunk/Source/_javascript_Core








Revision 222929
Author sbar...@apple.com
Date 2017-10-05 12:58:08 -0700 (Thu, 05 Oct 2017)


Log Message
Only add prototypes to the PrototypeMap if they're not already present
https://bugs.webkit.org/show_bug.cgi?id=177952

Reviewed by Michael Saboff and JF Bastien.

With poly proto, we need to call PrototypeMap::add more frequently since we don't
know if the prototype is already in the map or not based solely on Structure.
PrototypeMap::add was calling WeakMap::set unconditionally, which would unconditionally
allocate a Weak handle. Allocating a Weak handle is expensive. It's at least 8x more
expensive than just checking if the prototype is in the map prior to adding it. This
patch makes the change to only add the prototype if it's not already in the map. To
do this, I've added a WeakMap::add API that just forwards into HashMap's add API.
This allows us to both only do a single hash table lookup and also to allocate only
a single Weak handle when necessary.

* runtime/PrototypeMapInlines.h:
(JSC::PrototypeMap::addPrototype):
* runtime/WeakGCMap.h:
(JSC::WeakGCMap::add):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/PrototypeMapInlines.h
trunk/Source/_javascript_Core/runtime/WeakGCMap.h




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (222928 => 222929)

--- trunk/Source/_javascript_Core/ChangeLog	2017-10-05 19:12:04 UTC (rev 222928)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-10-05 19:58:08 UTC (rev 222929)
@@ -1,5 +1,27 @@
 2017-10-05  Saam Barati  
 
+Only add prototypes to the PrototypeMap if they're not already present
+https://bugs.webkit.org/show_bug.cgi?id=177952
+
+Reviewed by Michael Saboff and JF Bastien.
+
+With poly proto, we need to call PrototypeMap::add more frequently since we don't
+know if the prototype is already in the map or not based solely on Structure.
+PrototypeMap::add was calling WeakMap::set unconditionally, which would unconditionally
+allocate a Weak handle. Allocating a Weak handle is expensive. It's at least 8x more
+expensive than just checking if the prototype is in the map prior to adding it. This
+patch makes the change to only add the prototype if it's not already in the map. To
+do this, I've added a WeakMap::add API that just forwards into HashMap's add API.
+This allows us to both only do a single hash table lookup and also to allocate only
+a single Weak handle when necessary.
+
+* runtime/PrototypeMapInlines.h:
+(JSC::PrototypeMap::addPrototype):
+* runtime/WeakGCMap.h:
+(JSC::WeakGCMap::add):
+
+2017-10-05  Saam Barati  
+
 Unreviewed. Disable probe OSR exit on 32-bit until it's fixed.
 
 * runtime/Options.cpp:


Modified: trunk/Source/_javascript_Core/runtime/PrototypeMapInlines.h (222928 => 222929)

--- trunk/Source/_javascript_Core/runtime/PrototypeMapInlines.h	2017-10-05 19:12:04 UTC (rev 222928)
+++ trunk/Source/_javascript_Core/runtime/PrototypeMapInlines.h	2017-10-05 19:58:08 UTC (rev 222929)
@@ -44,7 +44,11 @@
 
 ALWAYS_INLINE void PrototypeMap::addPrototype(JSObject* object)
 {
-m_prototypes.set(object, object);
+auto addResult = m_prototypes.add(object, Weak());
+if (addResult.isNewEntry)
+addResult.iterator->value = Weak(object);
+else
+ASSERT(addResult.iterator->value.get() == object);
 
 // Note that this method makes the somewhat odd decision to not check if this
 // object currently has indexed accessors. We could do that check here, and if


Modified: trunk/Source/_javascript_Core/runtime/WeakGCMap.h (222928 => 222929)

--- trunk/Source/_javascript_Core/runtime/WeakGCMap.h	2017-10-05 19:12:04 UTC (rev 222928)
+++ trunk/Source/_javascript_Core/runtime/WeakGCMap.h	2017-10-05 19:58:08 UTC (rev 222929)
@@ -58,6 +58,11 @@
 return m_map.set(key, WTFMove(value));
 }
 
+AddResult add(const KeyType& key, ValueType value)
+{
+return m_map.add(key, WTFMove(value));
+}
+
 bool remove(const KeyType& key)
 {
 return m_map.remove(key);






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-10-05 Thread sbarati

Title: [222925] trunk/Source/_javascript_Core








Revision 222925
Author sbar...@apple.com
Date 2017-10-05 11:59:58 -0700 (Thu, 05 Oct 2017)


Log Message
Unreviewed. Disable probe OSR exit on 32-bit until it's fixed.

* runtime/Options.cpp:
(JSC::recomputeDependentOptions):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/Options.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (222924 => 222925)

--- trunk/Source/_javascript_Core/ChangeLog	2017-10-05 18:57:07 UTC (rev 222924)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-10-05 18:59:58 UTC (rev 222925)
@@ -1,5 +1,12 @@
 2017-10-05  Saam Barati  
 
+Unreviewed. Disable probe OSR exit on 32-bit until it's fixed.
+
+* runtime/Options.cpp:
+(JSC::recomputeDependentOptions):
+
+2017-10-05  Saam Barati  
+
 Make sure all prototypes under poly proto get added into the VM's prototype map
 https://bugs.webkit.org/show_bug.cgi?id=177909
 


Modified: trunk/Source/_javascript_Core/runtime/Options.cpp (222924 => 222925)

--- trunk/Source/_javascript_Core/runtime/Options.cpp	2017-10-05 18:57:07 UTC (rev 222924)
+++ trunk/Source/_javascript_Core/runtime/Options.cpp	2017-10-05 18:59:58 UTC (rev 222925)
@@ -502,6 +502,12 @@
 Options::reservedZoneSize() = minimumReservedZoneSize;
 if (Options::softReservedZoneSize() < Options::reservedZoneSize() + minimumReservedZoneSize)
 Options::softReservedZoneSize() = Options::reservedZoneSize() + minimumReservedZoneSize;
+
+#if USE(JSVALUE32_64)
+// FIXME: Make probe OSR exit work on 32-bit:
+// https://bugs.webkit.org/show_bug.cgi?id=177956
+Options::useProbeOSRExit() = false;
+#endif
 }
 
 void Options::initialize()






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [222914] trunk/Tools

2017-10-05 Thread sbarati

Title: [222914] trunk/Tools








Revision 222914
Author sbar...@apple.com
Date 2017-10-05 10:18:15 -0700 (Thu, 05 Oct 2017)


Log Message
Unreviewed. Try to make debug type profiler tests stop timing out.

* Scripts/run-jsc-stress-tests:

Modified Paths

trunk/Tools/ChangeLog
trunk/Tools/Scripts/run-jsc-stress-tests




Diff

Modified: trunk/Tools/ChangeLog (222913 => 222914)

--- trunk/Tools/ChangeLog	2017-10-05 17:11:57 UTC (rev 222913)
+++ trunk/Tools/ChangeLog	2017-10-05 17:18:15 UTC (rev 222914)
@@ -1,3 +1,9 @@
+2017-10-05  Saam Barati  
+
+Unreviewed. Try to make debug type profiler tests stop timing out.
+
+* Scripts/run-jsc-stress-tests:
+
 2017-10-03  Frederic Wang  
 
 Remove Brotli from Source/ThirdParty


Modified: trunk/Tools/Scripts/run-jsc-stress-tests (222913 => 222914)

--- trunk/Tools/Scripts/run-jsc-stress-tests	2017-10-05 17:11:57 UTC (rev 222913)
+++ trunk/Tools/Scripts/run-jsc-stress-tests	2017-10-05 17:18:15 UTC (rev 222914)
@@ -861,11 +861,12 @@
 return
 end
 
+run("ftl-type-profiler", "--useTypeProfiler=true", *(FTL_OPTIONS))
+run("ftl-no-cjit-type-profiler-force-poly-proto", "--useTypeProfiler=true", "--forcePolyProto=true", *(FTL_OPTIONS + NO_CJIT_OPTIONS))
+
 return if !$isFTLPlatform
 
-run("ftl-no-cjit-type-profiler", "--useTypeProfiler=true", *(FTL_OPTIONS + NO_CJIT_OPTIONS))
-run("ftl-type-profiler", "--useTypeProfiler=true", *(FTL_OPTIONS))
-run("ftl-type-profiler-force-poly-proto-ftl-eager", "--useTypeProfiler=true", "--forcePolyProto=true", *(FTL_OPTIONS + EAGER_OPTIONS))
+run("ftl-type-profiler-ftl-eager", "--useTypeProfiler=true", *(FTL_OPTIONS + EAGER_OPTIONS))
 end
 
 def runControlFlowProfiler






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [222901] trunk

2017-10-05 Thread sbarati

Title: [222901] trunk








Revision 222901
Author sbar...@apple.com
Date 2017-10-05 00:38:00 -0700 (Thu, 05 Oct 2017)


Log Message
Make sure all prototypes under poly proto get added into the VM's prototype map
https://bugs.webkit.org/show_bug.cgi?id=177909

Reviewed by Keith Miller.

JSTests:

* stress/poly-proto-prototype-map-having-a-bad-time.js: Added.
(assert):
(foo.C):
(foo):
(set x):

Source/_javascript_Core:

This is an invariant of prototypes that I broke when doing poly proto. This patch fixes it.

* _javascript_Core.xcodeproj/project.pbxproj:
* bytecode/BytecodeList.json:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSCInlines.h:
* runtime/PrototypeMap.cpp:
(JSC::PrototypeMap::addPrototype): Deleted.
* runtime/PrototypeMap.h:
* runtime/PrototypeMapInlines.h:
(JSC::PrototypeMap::isPrototype const):
(JSC::PrototypeMap::addPrototype):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj
trunk/Source/_javascript_Core/bytecode/BytecodeList.json
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp
trunk/Source/_javascript_Core/dfg/DFGOperations.cpp
trunk/Source/_javascript_Core/runtime/CommonSlowPaths.cpp
trunk/Source/_javascript_Core/runtime/JSCInlines.h
trunk/Source/_javascript_Core/runtime/PrototypeMap.cpp
trunk/Source/_javascript_Core/runtime/PrototypeMap.h
trunk/Source/_javascript_Core/runtime/PrototypeMapInlines.h


Added Paths

trunk/JSTests/stress/poly-proto-prototype-map-having-a-bad-time.js




Diff

Modified: trunk/JSTests/ChangeLog (222900 => 222901)

--- trunk/JSTests/ChangeLog	2017-10-05 07:05:44 UTC (rev 222900)
+++ trunk/JSTests/ChangeLog	2017-10-05 07:38:00 UTC (rev 222901)
@@ -1,3 +1,16 @@
+2017-10-05  Saam Barati  
+
+Make sure all prototypes under poly proto get added into the VM's prototype map
+https://bugs.webkit.org/show_bug.cgi?id=177909
+
+Reviewed by Keith Miller.
+
+* stress/poly-proto-prototype-map-having-a-bad-time.js: Added.
+(assert):
+(foo.C):
+(foo):
+(set x):
+
 2017-09-30  Yusuke Suzuki  
 
 [JSC] Introduce import.meta


Added: trunk/JSTests/stress/poly-proto-prototype-map-having-a-bad-time.js (0 => 222901)

--- trunk/JSTests/stress/poly-proto-prototype-map-having-a-bad-time.js	(rev 0)
+++ trunk/JSTests/stress/poly-proto-prototype-map-having-a-bad-time.js	2017-10-05 07:38:00 UTC (rev 222901)
@@ -0,0 +1,30 @@
+function assert(b) {
+if (!b)
+throw new Error("Bad assertion");
+}
+
+function foo() {
+class C {
+constructor() {
+this.x = 20;
+}
+};
+let item = new C;
+item[0] = 42;
+return [item, C.prototype];
+}
+
+for (let i = 0; i < 50; ++i)
+foo();
+
+let [item, proto] = foo();
+let called = false;
+Object.defineProperty(proto, "1", {
+set(x) {
+called = true;
+}
+});
+
+assert(!called);
+item[1] = 42;
+assert(called);


Modified: trunk/Source/_javascript_Core/ChangeLog (222900 => 222901)

--- trunk/Source/_javascript_Core/ChangeLog	2017-10-05 07:05:44 UTC (rev 222900)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-10-05 07:38:00 UTC (rev 222901)
@@ -1,3 +1,27 @@
+2017-10-05  Saam Barati  
+
+Make sure all prototypes under poly proto get added into the VM's prototype map
+https://bugs.webkit.org/show_bug.cgi?id=177909
+
+Reviewed by Keith Miller.
+
+This is an invariant of prototypes that I broke when doing poly proto. This patch fixes it.
+
+* _javascript_Core.xcodeproj/project.pbxproj:
+* bytecode/BytecodeList.json:
+* dfg/DFGByteCodeParser.cpp:
+(JSC::DFG::ByteCodeParser::parseBlock):
+* dfg/DFGOperations.cpp:
+* runtime/CommonSlowPaths.cpp:
+(JSC::SLOW_PATH_DECL):
+* runtime/JSCInlines.h:
+* runtime/PrototypeMap.cpp:
+(JSC::PrototypeMap::addPrototype): Deleted.
+* runtime/PrototypeMap.h:
+* runtime/PrototypeMapInlines.h:
+(JSC::PrototypeMap::isPrototype const):
+(JSC::PrototypeMap::addPrototype):
+
 2017-09-30  Yusuke Suzuki  
 
 [JSC] Introduce import.meta


Modified: trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj (222900 => 222901)

--- trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj	2017-10-05 07:05:44 UTC (rev 222900)
+++ trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj	2017-10-05 07:38:00 UTC (rev 222901)
@@ -447,7 +447,7 @@
 		0F9E32641B05AB0400801ED5 /* DFGStoreBarrierInsertionPhase.h in Headers */ = {isa = PBXBuildFile; fileRef = 0F9E32621B05AB0400801ED5 /* DFGStoreBarrierInsertionPhase.h */; };
 		0F9FB4F517FCB91700CB67F8 /* DFGStackLayoutPhase.h in Headers

[webkit-changes] [222891] trunk

2017-10-04 Thread sbarati

Title: [222891] trunk








Revision 222891
Author sbar...@apple.com
Date 2017-10-04 19:47:59 -0700 (Wed, 04 Oct 2017)


Log Message
Make pertinent AccessCases watch the poly proto watchpoint
https://bugs.webkit.org/show_bug.cgi?id=177765

Reviewed by Keith Miller.

JSTests:

* microbenchmarks/poly-proto-and-non-poly-proto-same-ic.js: Added.
(assert):
(foo.C):
(foo):
(validate):
* stress/poly-proto-clear-stub.js: Added.
(assert):
(foo.C):
(foo):

Source/_javascript_Core:

This patch makes it so that stubs that encounter a structure with a
valid poly proto watchpoint will watch the poly proto watchpoint. This
ensures that if the watchpoint is fired, the stub will be cleared
and have a chance to regenerate. In an ideal world, this will lead
to the stub generating better code since it may never encounter the
non-poly proto structure again.

This patch also fixes a bug in the original poly proto code where
I accidentally had a condition inverted. The bad code caused a
stub that continually cached two structures which are structurally
equivalent but with different prototype objects to always clear itself.
The code should have been written differently. It should have only
cleared if the poly proto watchpoint *was not* fired. The code
accidentally cleared only if stub *was* fired.

* bytecode/AccessCase.cpp:
(JSC::AccessCase::commit):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::addCases):
(WTF::printInternal):
* bytecode/PolymorphicAccess.h:
(JSC::AccessGenerationResult::shouldResetStubAndFireWatchpoints const):
(JSC::AccessGenerationResult::addWatchpointToFire):
(JSC::AccessGenerationResult::fireWatchpoints):
(JSC::AccessGenerationResult::shouldResetStub const): Deleted.
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::addAccessCase):
(JSC::StructureStubInfo::reset):
* bytecode/Watchpoint.h:
(JSC::InlineWatchpointSet::inflate):
* jit/Repatch.cpp:
(JSC::fireWatchpointsAndClearStubIfNeeded):
(JSC::tryCacheGetByID):
(JSC::repatchGetByID):
(JSC::tryCachePutByID):
(JSC::repatchPutByID):
(JSC::tryCacheIn):
(JSC::repatchIn):
(JSC::tryRepatchIn): Deleted.

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/AccessCase.cpp
trunk/Source/_javascript_Core/bytecode/PolymorphicAccess.cpp
trunk/Source/_javascript_Core/bytecode/PolymorphicAccess.h
trunk/Source/_javascript_Core/bytecode/StructureStubInfo.cpp
trunk/Source/_javascript_Core/bytecode/Watchpoint.h
trunk/Source/_javascript_Core/jit/Repatch.cpp


Added Paths

trunk/JSTests/microbenchmarks/poly-proto-and-non-poly-proto-same-ic.js
trunk/JSTests/stress/poly-proto-clear-stub.js




Diff

Modified: trunk/JSTests/ChangeLog (222890 => 222891)

--- trunk/JSTests/ChangeLog	2017-10-05 00:02:05 UTC (rev 222890)
+++ trunk/JSTests/ChangeLog	2017-10-05 02:47:59 UTC (rev 222891)
@@ -1,3 +1,20 @@
+2017-10-04  Saam Barati  
+
+Make pertinent AccessCases watch the poly proto watchpoint
+https://bugs.webkit.org/show_bug.cgi?id=177765
+
+Reviewed by Keith Miller.
+
+* microbenchmarks/poly-proto-and-non-poly-proto-same-ic.js: Added.
+(assert):
+(foo.C):
+(foo):
+(validate):
+* stress/poly-proto-clear-stub.js: Added.
+(assert):
+(foo.C):
+(foo):
+
 2017-10-04  Ryan Haddad  
 
 Remove failure expectation for async-func-decl-dstr-obj-id-put-unresolvable-no-strict.js.


Added: trunk/JSTests/microbenchmarks/poly-proto-and-non-poly-proto-same-ic.js (0 => 222891)

--- trunk/JSTests/microbenchmarks/poly-proto-and-non-poly-proto-same-ic.js	(rev 0)
+++ trunk/JSTests/microbenchmarks/poly-proto-and-non-poly-proto-same-ic.js	2017-10-05 02:47:59 UTC (rev 222891)
@@ -0,0 +1,111 @@
+function assert(b, m) {
+if (!b)
+throw new Error("Bad:" + m);
+}
+
+function foo() {
+class C {
+constructor() {
+this.p0 = 0
+this.p1 = 1
+this.p2 = 2
+this.p3 = 3
+this.p4 = 4
+this.p5 = 5
+this.p6 = 6
+this.p7 = 7
+this.p8 = 8
+this.p9 = 9
+this.p10 = 10
+this.p11 = 11
+this.p12 = 12
+this.p13 = 13
+this.p14 = 14
+this.p15 = 15
+this.p16 = 16
+this.p17 = 17
+this.p18 = 18
+this.p19 = 19
+this.p20 = 20
+this.p21 = 21
+this.p22 = 22
+this.p23 = 23
+this.p24 = 24
+this.p25 = 25
+this.p26 = 26
+this.p27 = 27
+this.p28 = 28
+this.p29 = 29
+this.p30 = 30
+this.p31 = 31
+this.p32 = 32
+this.p33 = 33
+this.p34 = 34
+this.p35 = 35
+this.p36 = 36
+this.p37 = 37
+this.p38 = 38
+

[webkit-changes] [222866] trunk/JSTests

2017-10-04 Thread sbarati

Title: [222866] trunk/JSTests








Revision 222866
Author sbar...@apple.com
Date 2017-10-04 11:56:32 -0700 (Wed, 04 Oct 2017)


Log Message
3 poly-proto JSC tests timing out on debug after r222827
https://bugs.webkit.org/show_bug.cgi?id=177880

Rubber stamped by Mark Lam.

* microbenchmarks/poly-proto-access.js:
* typeProfiler/deltablue-for-of.js:
* typeProfiler/getter-richards.js:

Modified Paths

trunk/JSTests/ChangeLog
trunk/JSTests/microbenchmarks/poly-proto-access.js
trunk/JSTests/typeProfiler/deltablue-for-of.js
trunk/JSTests/typeProfiler/getter-richards.js




Diff

Modified: trunk/JSTests/ChangeLog (222865 => 222866)

--- trunk/JSTests/ChangeLog	2017-10-04 18:55:19 UTC (rev 222865)
+++ trunk/JSTests/ChangeLog	2017-10-04 18:56:32 UTC (rev 222866)
@@ -1,3 +1,14 @@
+2017-10-04  Saam Barati  
+
+3 poly-proto JSC tests timing out on debug after r222827
+https://bugs.webkit.org/show_bug.cgi?id=177880
+
+Rubber stamped by Mark Lam.
+
+* microbenchmarks/poly-proto-access.js:
+* typeProfiler/deltablue-for-of.js:
+* typeProfiler/getter-richards.js:
+
 2017-10-04  Joseph Pecoraro  
 
 Unreviewed, marking tco-catch.js as a failure after test262 update


Modified: trunk/JSTests/microbenchmarks/poly-proto-access.js (222865 => 222866)

--- trunk/JSTests/microbenchmarks/poly-proto-access.js	2017-10-04 18:55:19 UTC (rev 222865)
+++ trunk/JSTests/microbenchmarks/poly-proto-access.js	2017-10-04 18:56:32 UTC (rev 222866)
@@ -30,7 +30,7 @@
 noInline(bar);
 
 let start = Date.now();
-for (let i = 0; i < 100; ++i) {
+for (let i = 0; i < 10; ++i) {
 if (i === 5000) {
 for (let arr of a)
 arr.__proto__.foo = 42;


Modified: trunk/JSTests/typeProfiler/deltablue-for-of.js (222865 => 222866)

--- trunk/JSTests/typeProfiler/deltablue-for-of.js	2017-10-04 18:55:19 UTC (rev 222865)
+++ trunk/JSTests/typeProfiler/deltablue-for-of.js	2017-10-04 18:56:32 UTC (rev 222866)
@@ -866,5 +866,5 @@
   projectionTest(50);
 }
 
-for (var i = 0; i < 100; ++i)
+for (var i = 0; i < 35; ++i)
 deltaBlue();


Modified: trunk/JSTests/typeProfiler/getter-richards.js (222865 => 222866)

--- trunk/JSTests/typeProfiler/getter-richards.js	2017-10-04 18:55:19 UTC (rev 222865)
+++ trunk/JSTests/typeProfiler/getter-richards.js	2017-10-04 18:56:32 UTC (rev 222866)
@@ -589,5 +589,5 @@
   return "Packet";
 };
 
-for (var i = 0; i < 350; ++i)
+for (var i = 0; i < 150; ++i)
   runRichards();






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-10-02 Thread sbarati

Title: [222744] trunk/Source/_javascript_Core








Revision 222744
Author sbar...@apple.com
Date 2017-10-02 14:40:19 -0700 (Mon, 02 Oct 2017)


Log Message
Unreviewed. Add missing exception check for the custom-get-set-inline-caching-one-level-up-proto-chain.js
test that I added. It uncovered a pre-existing missing exception check.

* runtime/JSObject.cpp:
(JSC::JSObject::putInlineSlow):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/JSObject.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (222743 => 222744)

--- trunk/Source/_javascript_Core/ChangeLog	2017-10-02 21:31:46 UTC (rev 222743)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-10-02 21:40:19 UTC (rev 222744)
@@ -1,3 +1,11 @@
+2017-10-02  Saam Barati  
+
+Unreviewed. Add missing exception check for the custom-get-set-inline-caching-one-level-up-proto-chain.js
+test that I added. It uncovered a pre-existing missing exception check.
+
+* runtime/JSObject.cpp:
+(JSC::JSObject::putInlineSlow):
+
 2017-10-02  Joseph Pecoraro  
 
 Web Inspector: Include Beacon and Ping requests in Network tab


Modified: trunk/Source/_javascript_Core/runtime/JSObject.cpp (222743 => 222744)

--- trunk/Source/_javascript_Core/runtime/JSObject.cpp	2017-10-02 21:31:46 UTC (rev 222743)
+++ trunk/Source/_javascript_Core/runtime/JSObject.cpp	2017-10-02 21:40:19 UTC (rev 222744)
@@ -784,6 +784,7 @@
 }
 if (gs.isCustomGetterSetter()) {
 bool result = callCustomSetter(exec, gs, attributes & PropertyAttribute::CustomAccessor, obj, slot.thisValue(), value);
+RETURN_IF_EXCEPTION(scope, false);
 if (attributes & PropertyAttribute::CustomAccessor)
 slot.setCustomAccessor(obj, jsCast(gs.asCell())->setter());
 else






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-10-02 Thread sbarati

Title: [222713] trunk/Source/_javascript_Core








Revision 222713
Author sbar...@apple.com
Date 2017-10-02 10:09:08 -0700 (Mon, 02 Oct 2017)


Log Message
Unreviewed. Fix debug assertion after r222671. 

JSTestCustomGetterSetter::finishCreation needs to call its base's finishCreation implementation.

* jsc.cpp:
(JSTestCustomGetterSetter::finishCreation):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/jsc.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (222712 => 222713)

--- trunk/Source/_javascript_Core/ChangeLog	2017-10-02 16:54:12 UTC (rev 222712)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-10-02 17:09:08 UTC (rev 222713)
@@ -1,3 +1,12 @@
+2017-10-02  Saam Barati  
+
+Unreviewed. Fix debug assertion after r222671. 
+
+JSTestCustomGetterSetter::finishCreation needs to call its base's finishCreation implementation.
+
+* jsc.cpp:
+(JSTestCustomGetterSetter::finishCreation):
+
 2017-10-01  Commit Queue  
 
 Unreviewed, rolling out r222564.


Modified: trunk/Source/_javascript_Core/jsc.cpp (222712 => 222713)

--- trunk/Source/_javascript_Core/jsc.cpp	2017-10-02 16:54:12 UTC (rev 222712)
+++ trunk/Source/_javascript_Core/jsc.cpp	2017-10-02 17:09:08 UTC (rev 222713)
@@ -1127,6 +1127,8 @@
 
 void JSTestCustomGetterSetter::finishCreation(VM& vm)
 {
+Base::finishCreation(vm);
+
 putDirectCustomAccessor(vm, Identifier::fromString(, "customValue"),
 CustomGetterSetter::create(vm, customGetValue, customSetValue), 0);
 putDirectCustomAccessor(vm, Identifier::fromString(, "customAccessor"),






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [222671] trunk

2017-09-29 Thread sbarati

Title: [222671] trunk








Revision 222671
Author sbar...@apple.com
Date 2017-09-29 16:48:10 -0700 (Fri, 29 Sep 2017)


Log Message
Custom GetterSetterAccessCase does not use the correct slotBase when making call
https://bugs.webkit.org/show_bug.cgi?id=177639

Reviewed by Geoffrey Garen.

JSTests:

* stress/custom-get-set-inline-caching-one-level-up-proto-chain.js: Added.
(assert):
(Class):
(items.forEach):
(set get for):

Source/_javascript_Core:

The bug occurred when you had a custom set value. Custom set/get
values are passed the property holder, not the base of the access.
If we had an object chain like this:
o = {__proto__: thingWithCustomSetValue}

We would end up not providing thingWithCustomSetValue as the argument
to the PutValueFunc. The reason is, we would use generateConditionsForPrototypePropertyHitCustom
for custom sets. This would return to us an empty ConditionSet, because
the property holder was only one level up the prototype chain. The reason
is, it didn't generate a condition for the slot holder, because the
protocol for custom set/get is that if an object responds to a custom
setter/getter, it will continue to respond to that getter/setter for
the lifetime of that object. Therefore, it's not strictly necessary to
generate an OPC for the slot base for custom accesses. However, AccessCase
uses !m_conditionSet.isEmtpy() to indicate that the IC is doing a prototype
access. With the above object "o", we were doing a prototype access, but we
had an empty condition set. This lead us to passing the base instead of
the property holder to the custom set value function, which is incorrect.

With custom getters, we never called to into the generateConditionsForPrototypePropertyHitCustom
API. Gets would always call into generateConditionsForPrototypePropertyHit, which
will generate an OPC on the slot base, even if it isn't strictly necessary for custom accessors.
This patch simply removes generateConditionsForPrototypePropertyHitCustom
and aligns the set case with the get case. It makes us properly detect
when we're doing a prototype access with the above object "o". If we find
that generateConditionsForPrototypePropertyHitCustom was a worthwhile
optimization to have, we can re-introduce it. We'll just need to pipe through
a new notion of when we're doing prototype accesses that doesn't rely solely
on !m_conditionSet.isEmpty().

* bytecode/ObjectPropertyConditionSet.cpp:
(JSC::generateConditionsForPrototypePropertyHitCustom): Deleted.
* bytecode/ObjectPropertyConditionSet.h:
* jit/Repatch.cpp:
(JSC::tryCachePutByID):
* jsc.cpp:
(JSTestCustomGetterSetter::JSTestCustomGetterSetter):
(JSTestCustomGetterSetter::create):
(JSTestCustomGetterSetter::createStructure):
(customGetAccessor):
(customGetValue):
(customSetAccessor):
(customSetValue):
(JSTestCustomGetterSetter::finishCreation):
(GlobalObject::finishCreation):
(functionLoadGetterFromGetterSetter):
(functionCreateCustomTestGetterSetter):
* runtime/PropertySlot.h:
(JSC::PropertySlot::setCustomGetterSetter):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/ObjectPropertyConditionSet.cpp
trunk/Source/_javascript_Core/bytecode/ObjectPropertyConditionSet.h
trunk/Source/_javascript_Core/jit/Repatch.cpp
trunk/Source/_javascript_Core/jsc.cpp
trunk/Source/_javascript_Core/runtime/PropertySlot.h


Added Paths

trunk/JSTests/stress/custom-get-set-inline-caching-one-level-up-proto-chain.js




Diff

Modified: trunk/JSTests/ChangeLog (222670 => 222671)

--- trunk/JSTests/ChangeLog	2017-09-29 23:42:03 UTC (rev 222670)
+++ trunk/JSTests/ChangeLog	2017-09-29 23:48:10 UTC (rev 222671)
@@ -1,3 +1,16 @@
+2017-09-29  Saam Barati  
+
+Custom GetterSetterAccessCase does not use the correct slotBase when making call
+https://bugs.webkit.org/show_bug.cgi?id=177639
+
+Reviewed by Geoffrey Garen.
+
+* stress/custom-get-set-inline-caching-one-level-up-proto-chain.js: Added.
+(assert):
+(Class):
+(items.forEach):
+(set get for):
+
 2017-09-29  Commit Queue  
 
 Unreviewed, rolling out r222563, r222565, and r222581.


Added: trunk/JSTests/stress/custom-get-set-inline-caching-one-level-up-proto-chain.js (0 => 222671)

--- trunk/JSTests/stress/custom-get-set-inline-caching-one-level-up-proto-chain.js	(rev 0)
+++ trunk/JSTests/stress/custom-get-set-inline-caching-one-level-up-proto-chain.js	2017-09-29 23:48:10 UTC (rev 222671)
@@ -0,0 +1,67 @@
+function assert(b, m) {
+if (!b)
+throw new Error("Bad:" + m);
+}
+
+class Class { };
+
+let items = [
+new Class,
+new Class,
+new Class,
+new Class,
+];
+
+let customGetterSetter = createCustomTestGetterSetter();
+items.forEach((x) => {
+x.__proto__ = customGetterSetter;
+assert(x.__proto__ === customGetterSetter);
+});
+
+function validate(x, valueResult, accessorResult) {
+

[webkit-changes] [222590] trunk

2017-09-27 Thread sbarati

Title: [222590] trunk








Revision 222590
Author sbar...@apple.com
Date 2017-09-27 17:44:28 -0700 (Wed, 27 Sep 2017)


Log Message
Propagate hasBeenFlattenedBefore in Structure's transition constructor and fix our for-in caching to fail when the prototype chain has an object with a dictionary structure
https://bugs.webkit.org/show_bug.cgi?id=177523

Reviewed by Mark Lam.

JSTests:

* stress/prototype-chain-has-dictionary-structure-for-in-caching.js: Added.
(assert):
(Test):
(addMethods.Test.prototype.string_appeared_here.i.methodNumber):
(addMethods):
(i.Test.prototype.propName):

Source/_javascript_Core:

There was a bug in Structure's transition constructor where it didn't
propagate forward the hasBeenFlattenedBefore bit. In practice, this meant
that every time we asked a dictionary structure if it has been flattened
before, it would return false. This patch fixes this bug. It also fixes
a bug that this uncovers in our for-in implementation. Our implementation
would cache the property name enumerator even when the prototype chain
included a structure that is as dictionary. This is wrong because that
prototype object may add properties without transitioning, and the for-in
loop would vend a stale set of prototype properties.

* jit/JITOperations.cpp:
* runtime/JSPropertyNameEnumerator.h:
(JSC::propertyNameEnumerator):
* runtime/Structure.cpp:
(JSC::Structure::Structure):
(JSC::Structure::canCachePropertyNameEnumerator const):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/jit/JITOperations.cpp
trunk/Source/_javascript_Core/runtime/JSPropertyNameEnumerator.h
trunk/Source/_javascript_Core/runtime/Structure.cpp


Added Paths

trunk/JSTests/stress/prototype-chain-has-dictionary-structure-for-in-caching.js




Diff

Modified: trunk/JSTests/ChangeLog (222589 => 222590)

--- trunk/JSTests/ChangeLog	2017-09-28 00:27:09 UTC (rev 222589)
+++ trunk/JSTests/ChangeLog	2017-09-28 00:44:28 UTC (rev 222590)
@@ -1,3 +1,17 @@
+2017-09-27  Saam Barati  
+
+Propagate hasBeenFlattenedBefore in Structure's transition constructor and fix our for-in caching to fail when the prototype chain has an object with a dictionary structure
+https://bugs.webkit.org/show_bug.cgi?id=177523
+
+Reviewed by Mark Lam.
+
+* stress/prototype-chain-has-dictionary-structure-for-in-caching.js: Added.
+(assert):
+(Test):
+(addMethods.Test.prototype.string_appeared_here.i.methodNumber):
+(addMethods):
+(i.Test.prototype.propName):
+
 2017-09-27  Mark Lam  
 
 Yarr::Parser::tryConsumeGroupName() should check for the end of the pattern.


Added: trunk/JSTests/stress/prototype-chain-has-dictionary-structure-for-in-caching.js (0 => 222590)

--- trunk/JSTests/stress/prototype-chain-has-dictionary-structure-for-in-caching.js	(rev 0)
+++ trunk/JSTests/stress/prototype-chain-has-dictionary-structure-for-in-caching.js	2017-09-28 00:44:28 UTC (rev 222590)
@@ -0,0 +1,36 @@
+
+function assert(b) {
+if (!b)
+throw new Error("Bad")
+}
+
+var Test = function(){};
+
+let methodNumber = 0;
+function addMethods() {
+const methodCount = 65;
+for (var i = 0; i < methodCount; i++){
+Test.prototype['myMethod' + i + methodNumber] = function(){};
+++methodNumber;
+}
+}
+
+addMethods();
+
+var test1 = new Test();
+
+for (var k in test1) { }
+
+let test2 = new Test();
+
+for (let i = 0; i < 100; ++i ) {
+let propName = 'myAdditionalMethod' + i;
+Test.prototype[propName] = function(){};
+let foundNewPrototypeProperty = false;
+for (let k in test2) {
+if (propName === k)
+foundNewPrototypeProperty = true;
+}
+assert(foundNewPrototypeProperty);
+addMethods();
+}


Modified: trunk/Source/_javascript_Core/ChangeLog (222589 => 222590)

--- trunk/Source/_javascript_Core/ChangeLog	2017-09-28 00:27:09 UTC (rev 222589)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-09-28 00:44:28 UTC (rev 222590)
@@ -1,3 +1,27 @@
+2017-09-27  Saam Barati  
+
+Propagate hasBeenFlattenedBefore in Structure's transition constructor and fix our for-in caching to fail when the prototype chain has an object with a dictionary structure
+https://bugs.webkit.org/show_bug.cgi?id=177523
+
+Reviewed by Mark Lam.
+
+There was a bug in Structure's transition constructor where it didn't
+propagate forward the hasBeenFlattenedBefore bit. In practice, this meant
+that every time we asked a dictionary structure if it has been flattened
+before, it would return false. This patch fixes this bug. It also fixes
+a bug that this uncovers in our for-in implementation. Our implementation
+would cache the property name enumerator even when the prototype chain
+included a structure that is as dictionary. This is wrong because that
+

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

2017-09-22 Thread sbarati

Title: [222398] trunk/Source/_javascript_Core








Revision 222398
Author sbar...@apple.com
Date 2017-09-22 12:18:33 -0700 (Fri, 22 Sep 2017)


Log Message
Usage of ErrorInstance::m_stackTrace on the mutator is racy with the collector
https://bugs.webkit.org/show_bug.cgi?id=177368

Reviewed by Keith Miller.

* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::finishCreation):
(JSC::ErrorInstance::materializeErrorInfoIfNeeded):
(JSC::ErrorInstance::visitChildren):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/ErrorInstance.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (222397 => 222398)

--- trunk/Source/_javascript_Core/ChangeLog	2017-09-22 19:01:25 UTC (rev 222397)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-09-22 19:18:33 UTC (rev 222398)
@@ -1,3 +1,15 @@
+2017-09-22  Saam Barati  
+
+Usage of ErrorInstance::m_stackTrace on the mutator is racy with the collector
+https://bugs.webkit.org/show_bug.cgi?id=177368
+
+Reviewed by Keith Miller.
+
+* runtime/ErrorInstance.cpp:
+(JSC::ErrorInstance::finishCreation):
+(JSC::ErrorInstance::materializeErrorInfoIfNeeded):
+(JSC::ErrorInstance::visitChildren):
+
 2017-09-22  Yusuke Suzuki  
 
 [DFG][FTL] Profile array vector length for array allocation


Modified: trunk/Source/_javascript_Core/runtime/ErrorInstance.cpp (222397 => 222398)

--- trunk/Source/_javascript_Core/runtime/ErrorInstance.cpp	2017-09-22 19:01:25 UTC (rev 222397)
+++ trunk/Source/_javascript_Core/runtime/ErrorInstance.cpp	2017-09-22 19:18:33 UTC (rev 222398)
@@ -115,7 +115,13 @@
 if (!message.isNull())
 putDirect(vm, vm.propertyNames->message, jsString(, message), DontEnum);
 
-m_stackTrace = getStackTrace(exec, vm, this, useCurrentFrame);
+std::unique_ptr stackTrace = getStackTrace(exec, vm, this, useCurrentFrame);
+{
+auto locker = holdLock(*this);
+m_stackTrace = WTFMove(stackTrace);
+}
+vm.heap.writeBarrier(this);
+
 if (m_stackTrace && !m_stackTrace->isEmpty() && hasSourceAppender()) {
 unsigned bytecodeOffset;
 CallFrame* callFrame;
@@ -202,7 +208,10 @@
 return;
 
 addErrorInfo(vm, m_stackTrace.get(), this);
-m_stackTrace = nullptr;
+{
+auto locker = holdLock(*this);
+m_stackTrace = nullptr;
+}
 
 m_errorInfoMaterialized = true;
 }
@@ -222,9 +231,12 @@
 ASSERT_GC_OBJECT_INHERITS(thisObject, info());
 Base::visitChildren(thisObject, visitor);
 
-if (thisObject->m_stackTrace) {
-for (StackFrame& frame : *thisObject->m_stackTrace)
-frame.visitChildren(visitor);
+{
+auto locker = holdLock(*thisObject);
+if (thisObject->m_stackTrace) {
+for (StackFrame& frame : *thisObject->m_stackTrace)
+frame.visitChildren(visitor);
+}
 }
 }
 






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [222115] trunk

2017-09-15 Thread sbarati

Title: [222115] trunk








Revision 222115
Author sbar...@apple.com
Date 2017-09-15 16:27:56 -0700 (Fri, 15 Sep 2017)


Log Message
Arity fixup during inlining should do a 2 phase commit so it properly recovers the frame in case of exit
https://bugs.webkit.org/show_bug.cgi?id=176981

Reviewed by Yusuke Suzuki.

JSTests:

* stress/exit-during-inlined-arity-fixup-recover-proper-frame.js: Added.
(assert):
(verify):
(func):
(const.bar.createBuiltin):

Source/_javascript_Core:

This patch makes inline arity fixup happen in two phases:
1. We get all the values we need and MovHint them to the expected locals.
2. We SetLocal them inside the callee's CodeOrigin. This way, if we exit, the callee's
   frame is already set up. If any SetLocal exits, we have a valid exit state.
   This is required because if we didn't do this in two phases, we may exit in
   the middle of arity fixup from the caller's CodeOrigin. This is unsound because if
   we did the SetLocals in the caller's frame, the memcpy may clobber needed parts
   of the frame right before exiting. For example, consider if we need to pad two args:
   [arg3][arg2][arg1][arg0]
   [fix ][fix ][arg3][arg2][arg1][arg0]
   We memcpy starting from arg0 in the direction of arg3. If we were to exit at a type check
   for arg3's SetLocal in the caller's CodeOrigin, we'd exit with a frame like so:
   [arg3][arg2][arg1][arg2][arg1][arg0]
   And the caller would then just end up thinking its argument are:
   [arg3][arg2][arg1][arg2]
   which is incorrect.

This patch also fixes a couple of bugs in IdentitiyWithProfile:
1. The bytecode generator for this bytecode intrinsic was written incorrectly.
   It needed to store the result of evaluating its argument in a temporary that
   it creates. Otherwise, it might try to simply overwrite a constant
   or a register that it didn't own.
2. We weren't eliminating this node in CSE inside the DFG.

* bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emit_intrinsic_idWithProfile):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::inlineCall):
* dfg/DFGCSEPhase.cpp:

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecompiler/NodesCodegen.cpp
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp
trunk/Source/_javascript_Core/dfg/DFGCSEPhase.cpp


Added Paths

trunk/JSTests/stress/exit-during-inlined-arity-fixup-recover-proper-frame.js




Diff

Modified: trunk/JSTests/ChangeLog (222114 => 222115)

--- trunk/JSTests/ChangeLog	2017-09-15 22:18:51 UTC (rev 222114)
+++ trunk/JSTests/ChangeLog	2017-09-15 23:27:56 UTC (rev 222115)
@@ -1,3 +1,16 @@
+2017-09-15  Saam Barati  
+
+Arity fixup during inlining should do a 2 phase commit so it properly recovers the frame in case of exit
+https://bugs.webkit.org/show_bug.cgi?id=176981
+
+Reviewed by Yusuke Suzuki.
+
+* stress/exit-during-inlined-arity-fixup-recover-proper-frame.js: Added.
+(assert):
+(verify):
+(func):
+(const.bar.createBuiltin):
+
 2017-09-14  Saam Barati  
 
 It should be valid to exit before each set when doing arity fixup when inlining


Added: trunk/JSTests/stress/exit-during-inlined-arity-fixup-recover-proper-frame.js (0 => 222115)

--- trunk/JSTests/stress/exit-during-inlined-arity-fixup-recover-proper-frame.js	(rev 0)
+++ trunk/JSTests/stress/exit-during-inlined-arity-fixup-recover-proper-frame.js	2017-09-15 23:27:56 UTC (rev 222115)
@@ -0,0 +1,31 @@
+let i;
+function verify(a, b, c, d, e, f) {
+function assert(b, m) {
+if (!b)
+throw new Error(m);
+}
+assert(a === i);
+assert(b === i+1);
+assert(c === i+2);
+assert(d === null);
+assert(e === undefined);
+assert(f === undefined);
+}
+noInline(verify);
+
+function func(a, b, c, d, e, f)
+{
+verify(a, b, c, d, e, f);
+return !!(a%2) ? a + b + c + d : a + b + c + d;
+}
+
+const bar = createBuiltin(`(function (f, a, b, c, d) {
+let y = @idWithProfile(null, "SpecInt32Only");
+return f(a, b, c, y);
+})`);
+
+noInline(bar);
+
+for (i = 0; i < 1000; ++i) {
+bar(func, i, i+1, i+2, i+3);
+}


Modified: trunk/Source/_javascript_Core/ChangeLog (222114 => 222115)

--- trunk/Source/_javascript_Core/ChangeLog	2017-09-15 22:18:51 UTC (rev 222114)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-09-15 23:27:56 UTC (rev 222115)
@@ -1,3 +1,41 @@
+2017-09-15  Saam Barati  
+
+Arity fixup during inlining should do a 2 phase commit so it properly recovers the frame in case of exit
+https://bugs.webkit.org/show_bug.cgi?id=176981
+
+Reviewed by Yusuke Suzuki.
+
+This patch makes inline arity fixup happen in two phases:
+1. We get all the values we need and MovHint them to the expected locals.
+2. We SetLocal them inside the callee's CodeOrigin. This way, if we exit, the callee's
+

[webkit-changes] [222071] trunk/Source

2017-09-14 Thread sbarati

Title: [222071] trunk/Source








Revision 222071
Author sbar...@apple.com
Date 2017-09-14 19:23:59 -0700 (Thu, 14 Sep 2017)


Log Message
We should have a way of preventing a caller from making a tail call and we should use it for ProxyObject instead of using build flags
https://bugs.webkit.org/show_bug.cgi?id=176863

Reviewed by Keith Miller.

Source/_javascript_Core:

* CMakeLists.txt:
* _javascript_Core.xcodeproj/project.pbxproj:
* runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::performHasProperty):
(JSC::ProxyObject::getOwnPropertySlotCommon):
(JSC::ProxyObject::performPut):
(JSC::performProxyCall):
(JSC::performProxyConstruct):
(JSC::ProxyObject::performDelete):
(JSC::ProxyObject::performPreventExtensions):
(JSC::ProxyObject::performIsExtensible):
(JSC::ProxyObject::performDefineOwnProperty):
(JSC::ProxyObject::performGetOwnPropertyNames):
(JSC::ProxyObject::performSetPrototype):
(JSC::ProxyObject::performGetPrototype):

Source/WTF:

This patch adds a way for a particular function to mark
that none of its calls should be tail calls.

It's useful in the following example if you don't want foo
to do a tail call to bar or baz:

int foo(bool b)
{
NO_TAIL_CALLS();
if (b)
return baz();
return bar();
}

Note that we're not saying that bar/baz should not be tail callable. bar/baz
may have other callers that are allowed to tail call it. This macro just says
that foo itself will not perform any tail calls.

* WTF.xcodeproj/project.pbxproj:
* wtf/NoTailCalls.h: Added.
(WTF::NoTailCalls::~NoTailCalls):

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/runtime/ProxyObject.cpp
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/WTF.xcodeproj/project.pbxproj


Added Paths

trunk/Source/WTF/wtf/NoTailCalls.h




Diff

Modified: trunk/Source/_javascript_Core/CMakeLists.txt (222070 => 222071)

--- trunk/Source/_javascript_Core/CMakeLists.txt	2017-09-15 01:42:52 UTC (rev 222070)
+++ trunk/Source/_javascript_Core/CMakeLists.txt	2017-09-15 02:23:59 UTC (rev 222071)
@@ -879,6 +879,7 @@
 runtime/PropertyTable.cpp
 runtime/PrototypeMap.cpp
 runtime/ProxyConstructor.cpp
+runtime/ProxyObject.cpp
 runtime/ProxyRevoke.cpp
 runtime/ReflectObject.cpp
 runtime/RegExp.cpp
@@ -1035,18 +1036,6 @@
 
 list(APPEND _javascript_Core_SOURCES ${generateUnifiedSourcesOutput})
 
-# These are special files that we can't or don't want to unified source compile
-list(APPEND _javascript_Core_SOURCES
-runtime/ProxyObject.cpp
-)
-
-# Extra flags for compile sources can go here.
-if (NOT MSVC)
-set_source_files_properties(runtime/ProxyObject.cpp PROPERTIES COMPILE_FLAGS -fno-optimize-sibling-calls)
-else ()
-# FIXME: Investigate if we need to set a similar flag on Windows.
-endif ()
-
 set(_javascript_Core_OBJECT_LUT_SOURCES
 runtime/ArrayConstructor.cpp
 runtime/ArrayIteratorPrototype.cpp


Modified: trunk/Source/_javascript_Core/ChangeLog (222070 => 222071)

--- trunk/Source/_javascript_Core/ChangeLog	2017-09-15 01:42:52 UTC (rev 222070)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-09-15 02:23:59 UTC (rev 222071)
@@ -1,5 +1,30 @@
 2017-09-14  Saam Barati  
 
+We should have a way of preventing a caller from making a tail call and we should use it for ProxyObject instead of using build flags
+https://bugs.webkit.org/show_bug.cgi?id=176863
+
+Reviewed by Keith Miller.
+
+* CMakeLists.txt:
+* _javascript_Core.xcodeproj/project.pbxproj:
+* runtime/ProxyObject.cpp:
+(JSC::performProxyGet):
+(JSC::ProxyObject::performInternalMethodGetOwnProperty):
+(JSC::ProxyObject::performHasProperty):
+(JSC::ProxyObject::getOwnPropertySlotCommon):
+(JSC::ProxyObject::performPut):
+(JSC::performProxyCall):
+(JSC::performProxyConstruct):
+(JSC::ProxyObject::performDelete):
+(JSC::ProxyObject::performPreventExtensions):
+(JSC::ProxyObject::performIsExtensible):
+(JSC::ProxyObject::performDefineOwnProperty):
+(JSC::ProxyObject::performGetOwnPropertyNames):
+(JSC::ProxyObject::performSetPrototype):
+(JSC::ProxyObject::performGetPrototype):
+
+2017-09-14  Saam Barati  
+
 Make dumping the graph print when both when exitOK and !exitOK
 https://bugs.webkit.org/show_bug.cgi?id=176954
 


Modified: trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj (222070 => 222071)

--- trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj	2017-09-15 01:42:52 UTC (rev 222070)
+++ trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj	2017-09-15 02:23:59 UTC (rev 222071)
@@ -1556,7 +1556,7 @@
 		79AF0BE41D3EFD4C00E95FA5 /*

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

2017-09-14 Thread sbarati

Title: [222066] trunk/Source/_javascript_Core








Revision 222066
Author sbar...@apple.com
Date 2017-09-14 17:04:47 -0700 (Thu, 14 Sep 2017)


Log Message
Make dumping the graph print when both when exitOK and !exitOK
https://bugs.webkit.org/show_bug.cgi?id=176954

Reviewed by Keith Miller.

* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGGraph.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (222065 => 222066)

--- trunk/Source/_javascript_Core/ChangeLog	2017-09-14 23:52:31 UTC (rev 222065)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-09-15 00:04:47 UTC (rev 222066)
@@ -1,5 +1,15 @@
 2017-09-14  Saam Barati  
 
+Make dumping the graph print when both when exitOK and !exitOK
+https://bugs.webkit.org/show_bug.cgi?id=176954
+
+Reviewed by Keith Miller.
+
+* dfg/DFGGraph.cpp:
+(JSC::DFG::Graph::dump):
+
+2017-09-14  Saam Barati  
+
 It should be valid to exit before each set when doing arity fixup when inlining
 https://bugs.webkit.org/show_bug.cgi?id=176948
 


Modified: trunk/Source/_javascript_Core/dfg/DFGGraph.cpp (222065 => 222066)

--- trunk/Source/_javascript_Core/dfg/DFGGraph.cpp	2017-09-14 23:52:31 UTC (rev 222065)
+++ trunk/Source/_javascript_Core/dfg/DFGGraph.cpp	2017-09-15 00:04:47 UTC (rev 222066)
@@ -390,8 +390,7 @@
 if (node->origin.semantic != node->origin.forExit && node->origin.forExit.isSet())
 out.print(comma, "exit: ", node->origin.forExit);
 }
-if (!node->origin.exitOK)
-out.print(comma, "ExitInvalid");
+out.print(comma, node->origin.exitOK ? "ExitValid" : "ExitInvalid");
 if (node->origin.wasHoisted)
 out.print(comma, "WasHoisted");
 out.print(")");






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [222060] trunk

2017-09-14 Thread sbarati

Title: [222060] trunk








Revision 222060
Author sbar...@apple.com
Date 2017-09-14 16:39:27 -0700 (Thu, 14 Sep 2017)


Log Message
It should be valid to exit before each set when doing arity fixup when inlining
https://bugs.webkit.org/show_bug.cgi?id=176948

Reviewed by Keith Miller.

JSTests:

* stress/arity-fixup-inlining-dont-generate-invalid-use.js: Added.
(baz):
(bar):
(foo):

Source/_javascript_Core:

This patch makes it so that we can exit before each SetLocal when doing arity
fixup during inlining. This is OK because if we exit at any of these SetLocals,
we will simply exit to the beginning of the call instruction.

Not doing this led to a bug where FixupPhase would insert a ValueRep of
a node before the actual node. This is obviously invalid IR. I've added
a new validation rule to catch this malformed IR.

* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::inliningCost):
(JSC::DFG::ByteCodeParser::inlineCall):
* dfg/DFGValidate.cpp:
* runtime/Options.h:

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp
trunk/Source/_javascript_Core/dfg/DFGValidate.cpp
trunk/Source/_javascript_Core/runtime/Options.h


Added Paths

trunk/JSTests/stress/arity-fixup-inlining-dont-generate-invalid-use.js




Diff

Modified: trunk/JSTests/ChangeLog (222059 => 222060)

--- trunk/JSTests/ChangeLog	2017-09-14 23:37:32 UTC (rev 222059)
+++ trunk/JSTests/ChangeLog	2017-09-14 23:39:27 UTC (rev 222060)
@@ -1,3 +1,15 @@
+2017-09-14  Saam Barati  
+
+It should be valid to exit before each set when doing arity fixup when inlining
+https://bugs.webkit.org/show_bug.cgi?id=176948
+
+Reviewed by Keith Miller.
+
+* stress/arity-fixup-inlining-dont-generate-invalid-use.js: Added.
+(baz):
+(bar):
+(foo):
+
 2017-09-14  Yusuke Suzuki  
 
 [JSC] Add PrivateSymbolMode::{Include,Exclude} for PropertyNameArray


Added: trunk/JSTests/stress/arity-fixup-inlining-dont-generate-invalid-use.js (0 => 222060)

--- trunk/JSTests/stress/arity-fixup-inlining-dont-generate-invalid-use.js	(rev 0)
+++ trunk/JSTests/stress/arity-fixup-inlining-dont-generate-invalid-use.js	2017-09-14 23:39:27 UTC (rev 222060)
@@ -0,0 +1,26 @@
+function baz() { }
+noInline(baz);
+
+function bar(x, y, z) {
+baz(z);
+return x + y + 20.2;
+}
+function foo(x, b) {
+let y = x + 10.54;
+let z = y;
+if (b) {
+y += 1.23;
+z += 2.199;
+} else {
+y += 2.27;
+z += 2.18;
+}
+
+let r = bar(b ? y : z, !b ? y : z);
+
+return r;
+}
+noInline(foo);
+
+for (let i = 0; i < 1000; ++i)
+foo(i+0.5, !!(i%2));


Modified: trunk/Source/_javascript_Core/ChangeLog (222059 => 222060)

--- trunk/Source/_javascript_Core/ChangeLog	2017-09-14 23:37:32 UTC (rev 222059)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-09-14 23:39:27 UTC (rev 222060)
@@ -1,3 +1,24 @@
+2017-09-14  Saam Barati  
+
+It should be valid to exit before each set when doing arity fixup when inlining
+https://bugs.webkit.org/show_bug.cgi?id=176948
+
+Reviewed by Keith Miller.
+
+This patch makes it so that we can exit before each SetLocal when doing arity
+fixup during inlining. This is OK because if we exit at any of these SetLocals,
+we will simply exit to the beginning of the call instruction.
+
+Not doing this led to a bug where FixupPhase would insert a ValueRep of
+a node before the actual node. This is obviously invalid IR. I've added
+a new validation rule to catch this malformed IR.
+
+* dfg/DFGByteCodeParser.cpp:
+(JSC::DFG::ByteCodeParser::inliningCost):
+(JSC::DFG::ByteCodeParser::inlineCall):
+* dfg/DFGValidate.cpp:
+* runtime/Options.h:
+
 2017-09-14  Mark Lam  
 
 AddressSanitizer: stack-buffer-underflow in JSC::Probe::Page::Page


Modified: trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp (222059 => 222060)

--- trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp	2017-09-14 23:37:32 UTC (rev 222059)
+++ trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp	2017-09-14 23:39:27 UTC (rev 222060)
@@ -1456,7 +1456,6 @@
 return UINT_MAX;
 }
 
-
 if (!Options::useArityFixupInlining()) {
 if (codeBlock->numParameters() > argumentCountIncludingThis) {
 if (DFGByteCodeParserInternal::verbose)
@@ -1582,8 +1581,12 @@
 if (arityFixupCount) {
 Node* undefined = addToGraph(JSConstant, OpInfo(m_constantUndefined));
 auto fill = [&] (VirtualRegister reg, Node* value) {
-Node* result = set(reg, value, ImmediateNakedSet);
-result->variableAccessData()->mergeShouldNeverUnbox(true); // We cannot exit after starting arity fixup.
+// It's valid to exit here since we'll exit to the

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

2017-09-06 Thread sbarati

Title: [221703] trunk/Source/_javascript_Core








Revision 221703
Author sbar...@apple.com
Date 2017-09-06 14:04:25 -0700 (Wed, 06 Sep 2017)


Log Message
Air should have a Vector of prologue generators instead of a HashMap representing an optional prologue generator
https://bugs.webkit.org/show_bug.cgi?id=176346

Reviewed by Mark Lam.

* b3/B3Procedure.cpp:
(JSC::B3::Procedure::Procedure):
(JSC::B3::Procedure::setNumEntrypoints):
* b3/B3Procedure.h:
(JSC::B3::Procedure::setNumEntrypoints): Deleted.
* b3/air/AirCode.cpp:
(JSC::B3::Air::defaultPrologueGenerator):
(JSC::B3::Air::Code::Code):
(JSC::B3::Air::Code::setNumEntrypoints):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::setPrologueForEntrypoint):
(JSC::B3::Air::Code::prologueGeneratorForEntrypoint):
(JSC::B3::Air::Code::setEntrypoints):
(JSC::B3::Air::Code::setEntrypointLabels):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/b3/B3Procedure.cpp
trunk/Source/_javascript_Core/b3/B3Procedure.h
trunk/Source/_javascript_Core/b3/air/AirCode.cpp
trunk/Source/_javascript_Core/b3/air/AirCode.h
trunk/Source/_javascript_Core/b3/air/AirGenerate.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (221702 => 221703)

--- trunk/Source/_javascript_Core/ChangeLog	2017-09-06 20:54:36 UTC (rev 221702)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-09-06 21:04:25 UTC (rev 221703)
@@ -1,5 +1,31 @@
 2017-09-06  Saam Barati  
 
+Air should have a Vector of prologue generators instead of a HashMap representing an optional prologue generator
+https://bugs.webkit.org/show_bug.cgi?id=176346
+
+Reviewed by Mark Lam.
+
+* b3/B3Procedure.cpp:
+(JSC::B3::Procedure::Procedure):
+(JSC::B3::Procedure::setNumEntrypoints):
+* b3/B3Procedure.h:
+(JSC::B3::Procedure::setNumEntrypoints): Deleted.
+* b3/air/AirCode.cpp:
+(JSC::B3::Air::defaultPrologueGenerator):
+(JSC::B3::Air::Code::Code):
+(JSC::B3::Air::Code::setNumEntrypoints):
+* b3/air/AirCode.h:
+(JSC::B3::Air::Code::setPrologueForEntrypoint):
+(JSC::B3::Air::Code::prologueGeneratorForEntrypoint):
+(JSC::B3::Air::Code::setEntrypoints):
+(JSC::B3::Air::Code::setEntrypointLabels):
+* b3/air/AirGenerate.cpp:
+(JSC::B3::Air::generate):
+* ftl/FTLLowerDFGToB3.cpp:
+(JSC::FTL::DFG::LowerDFGToB3::lower):
+
+2017-09-06  Saam Barati  
+
 ASSERTION FAILED: op() == CheckStructure in Source/_javascript_Core/dfg/DFGNode.h(443)
 https://bugs.webkit.org/show_bug.cgi?id=176470
 


Modified: trunk/Source/_javascript_Core/b3/B3Procedure.cpp (221702 => 221703)

--- trunk/Source/_javascript_Core/b3/B3Procedure.cpp	2017-09-06 20:54:36 UTC (rev 221702)
+++ trunk/Source/_javascript_Core/b3/B3Procedure.cpp	2017-09-06 21:04:25 UTC (rev 221703)
@@ -52,6 +52,7 @@
 , m_byproducts(std::make_unique())
 , m_code(new Air::Code(*this))
 {
+m_code->setNumEntrypoints(m_numEntrypoints);
 }
 
 Procedure::~Procedure()
@@ -420,6 +421,12 @@
 return code().mutableFPRs();
 }
 
+void Procedure::setNumEntrypoints(unsigned numEntrypoints)
+{
+m_numEntrypoints = numEntrypoints;
+m_code->setNumEntrypoints(numEntrypoints);
+}
+
 } } // namespace JSC::B3
 
 #endif // ENABLE(B3_JIT)


Modified: trunk/Source/_javascript_Core/b3/B3Procedure.h (221702 => 221703)

--- trunk/Source/_javascript_Core/b3/B3Procedure.h	2017-09-06 20:54:36 UTC (rev 221702)
+++ trunk/Source/_javascript_Core/b3/B3Procedure.h	2017-09-06 21:04:25 UTC (rev 221703)
@@ -186,8 +186,8 @@
 bool isFastConstant(const ValueKey&);
 
 unsigned numEntrypoints() const { return m_numEntrypoints; }
-void setNumEntrypoints(unsigned numEntrypoints) { m_numEntrypoints = numEntrypoints; }
-
+JS_EXPORT_PRIVATE void setNumEntrypoints(unsigned);
+
 // Only call this after code generation is complete. Note that the label for the 0th entrypoint
 // should point to exactly where the code generation cursor was before you started generating
 // code.


Modified: trunk/Source/_javascript_Core/b3/air/AirCode.cpp (221702 => 221703)

--- trunk/Source/_javascript_Core/b3/air/AirCode.cpp	2017-09-06 20:54:36 UTC (rev 221702)
+++ trunk/Source/_javascript_Core/b3/air/AirCode.cpp	2017-09-06 21:04:25 UTC (rev 221703)
@@ -30,6 +30,7 @@
 
 #include "AirCCallSpecial.h"
 #include "AirCFG.h"
+#include "AllowMacroScratchRegisterUsageIf.h"
 #include "B3BasicBlockUtils.h"
 #include "B3Procedure.h"
 #include "B3StackSlot.h"
@@ -37,10 +38,22 @@
 
 namespace JSC { namespace B3 { namespace Air {
 
+static void defaultPrologueGenerator(CCallHelpers& jit, Code& code)
+{
+jit.emitFunctionPrologue();
+if (code.frameSize()) {
+

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

2017-09-06 Thread sbarati

Title: [221701] trunk/Source/_javascript_Core








Revision 221701
Author sbar...@apple.com
Date 2017-09-06 13:51:02 -0700 (Wed, 06 Sep 2017)


Log Message
ASSERTION FAILED: op() == CheckStructure in Source/_javascript_Core/dfg/DFGNode.h(443)
https://bugs.webkit.org/show_bug.cgi?id=176470

Reviewed by Mark Lam.

Update Node::convertToCheckStructureImmediate's assertion to allow
the node to either be a CheckStructure or CheckStructureOrEmpty.

* dfg/DFGNode.h:
(JSC::DFG::Node::convertToCheckStructureImmediate):

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGNode.h




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (221700 => 221701)

--- trunk/Source/_javascript_Core/ChangeLog	2017-09-06 20:48:01 UTC (rev 221700)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-09-06 20:51:02 UTC (rev 221701)
@@ -1,3 +1,16 @@
+2017-09-06  Saam Barati  
+
+ASSERTION FAILED: op() == CheckStructure in Source/_javascript_Core/dfg/DFGNode.h(443)
+https://bugs.webkit.org/show_bug.cgi?id=176470
+
+Reviewed by Mark Lam.
+
+Update Node::convertToCheckStructureImmediate's assertion to allow
+the node to either be a CheckStructure or CheckStructureOrEmpty.
+
+* dfg/DFGNode.h:
+(JSC::DFG::Node::convertToCheckStructureImmediate):
+
 2017-09-05  Saam Barati  
 
 isNotCellSpeculation is wrong with respect to SpecEmpty


Modified: trunk/Source/_javascript_Core/dfg/DFGNode.h (221700 => 221701)

--- trunk/Source/_javascript_Core/dfg/DFGNode.h	2017-09-06 20:48:01 UTC (rev 221700)
+++ trunk/Source/_javascript_Core/dfg/DFGNode.h	2017-09-06 20:51:02 UTC (rev 221701)
@@ -440,7 +440,7 @@
 
 void convertToCheckStructureImmediate(Node* structure)
 {
-ASSERT(op() == CheckStructure);
+ASSERT(op() == CheckStructure || op() == CheckStructureOrEmpty);
 m_op = CheckStructureImmediate;
 children.setChild1(Edge(structure, CellUse));
 }






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[webkit-changes] [221657] trunk

2017-09-05 Thread sbarati

Title: [221657] trunk








Revision 221657
Author sbar...@apple.com
Date 2017-09-05 18:18:15 -0700 (Tue, 05 Sep 2017)


Log Message
isNotCellSpeculation is wrong with respect to SpecEmpty
https://bugs.webkit.org/show_bug.cgi?id=176429

Reviewed by Michael Saboff.

JSTests:

* microbenchmarks/is-not-cell-speculation-for-empty-value.js: Added.
(Foo):

Source/_javascript_Core:

The isNotCellSpeculation(SpeculatedType t) function was not taking into account
SpecEmpty in the set for t. It should return false when SpecEmpty is present, since
the empty value will fail a NotCell check. This bug would cause us to erroneously
generate NotCellUse UseKinds for inputs that are the empty value, causing repeated OSR exits.

* bytecode/SpeculatedType.h:
(JSC::isNotCellSpeculation):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/SpeculatedType.h


Added Paths

trunk/JSTests/microbenchmarks/is-not-cell-speculation-for-empty-value.js




Diff

Modified: trunk/JSTests/ChangeLog (221656 => 221657)

--- trunk/JSTests/ChangeLog	2017-09-06 01:01:36 UTC (rev 221656)
+++ trunk/JSTests/ChangeLog	2017-09-06 01:18:15 UTC (rev 221657)
@@ -1,3 +1,13 @@
+2017-09-05  Saam Barati  
+
+isNotCellSpeculation is wrong with respect to SpecEmpty
+https://bugs.webkit.org/show_bug.cgi?id=176429
+
+Reviewed by Michael Saboff.
+
+* microbenchmarks/is-not-cell-speculation-for-empty-value.js: Added.
+(Foo):
+
 2017-09-05  Joseph Pecoraro  
 
 test262: Completion values for control flow do not match the spec


Added: trunk/JSTests/microbenchmarks/is-not-cell-speculation-for-empty-value.js (0 => 221657)

--- trunk/JSTests/microbenchmarks/is-not-cell-speculation-for-empty-value.js	(rev 0)
+++ trunk/JSTests/microbenchmarks/is-not-cell-speculation-for-empty-value.js	2017-09-06 01:18:15 UTC (rev 221657)
@@ -0,0 +1,13 @@
+class Foo extends Object {
+constructor() {
+super();
+let arrow = () => {
+this.foo = 20;
+};
+this.arrow = arrow;
+}
+}
+noInline(Foo);
+
+for (let i = 0; i < 40; ++i)
+new Foo();


Modified: trunk/Source/_javascript_Core/ChangeLog (221656 => 221657)

--- trunk/Source/_javascript_Core/ChangeLog	2017-09-06 01:01:36 UTC (rev 221656)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-09-06 01:18:15 UTC (rev 221657)
@@ -1,5 +1,20 @@
 2017-09-05  Saam Barati  
 
+isNotCellSpeculation is wrong with respect to SpecEmpty
+https://bugs.webkit.org/show_bug.cgi?id=176429
+
+Reviewed by Michael Saboff.
+
+The isNotCellSpeculation(SpeculatedType t) function was not taking into account
+SpecEmpty in the set for t. It should return false when SpecEmpty is present, since
+the empty value will fail a NotCell check. This bug would cause us to erroneously
+generate NotCellUse UseKinds for inputs that are the empty value, causing repeated OSR exits.
+
+* bytecode/SpeculatedType.h:
+(JSC::isNotCellSpeculation):
+
+2017-09-05  Saam Barati  
+
 Make the distinction between entrypoints and CFG roots more clear by naming things better
 https://bugs.webkit.org/show_bug.cgi?id=176336
 


Modified: trunk/Source/_javascript_Core/bytecode/SpeculatedType.h (221656 => 221657)

--- trunk/Source/_javascript_Core/bytecode/SpeculatedType.h	2017-09-06 01:01:36 UTC (rev 221656)
+++ trunk/Source/_javascript_Core/bytecode/SpeculatedType.h	2017-09-06 01:18:15 UTC (rev 221657)
@@ -119,7 +119,7 @@
 
 inline bool isNotCellSpeculation(SpeculatedType value)
 {
-return !(value & SpecCell) && value;
+return !(value & SpecCellCheck) && value;
 }
 
 inline bool isObjectSpeculation(SpeculatedType value)






___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

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

2017-09-05 Thread sbarati

Title: [221637] trunk/Source/_javascript_Core








Revision 221637
Author sbar...@apple.com
Date 2017-09-05 14:30:05 -0700 (Tue, 05 Sep 2017)


Log Message
Make the distinction between entrypoints and CFG roots more clear by naming things better
https://bugs.webkit.org/show_bug.cgi?id=176336

Reviewed by Mark Lam and Keith Miller and Michael Saboff.

This patch does renaming to make the distinction between Graph::m_entrypoints
and Graph::m_numberOfEntrypoints more clear. The source of confusion is that
Graph::m_entrypoints.size() is not equivalent to Graph::m_numberOfEntrypoints.
Graph::m_entrypoints is really just the CFG roots. In CPS, this vector has
size >= 1. In SSA, the size is always 1. This patch renames Graph::m_entrypoints
to Graph::m_roots. To be consistent, this patch also renames Graph's m_entrypointToArguments
field to m_rootToArguments.

Graph::m_numberOfEntrypoints retains its name. This field is only used in SSA
when compiling with EntrySwitch. It represents the logical number of entrypoints
the compilation will end up with. Each EntrySwitch has m_numberOfEntrypoints
cases.

* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGCFG.h:
(JSC::DFG::CFG::roots):
(JSC::DFG::CPSCFG::CPSCFG):
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
* dfg/DFGDCEPhase.cpp:
(JSC::DFG::DCEPhase::run):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::determineReachability):
(JSC::DFG::Graph::blocksInPreOrder):
(JSC::DFG::Graph::blocksInPostOrder):
(JSC::DFG::Graph::methodOfGettingAValueProfileFor):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::isRoot):
(JSC::DFG::Graph::isEntrypoint): Deleted.
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::initialize):
* dfg/DFGLoopPreHeaderCreationPhase.cpp:
(JSC::DFG::createPreHeader):
* dfg/DFGMaximalFlushInsertionPhase.cpp:
(JSC::DFG::MaximalFlushInsertionPhase::run):
(JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
* dfg/DFGOSREntrypointCreationPhase.cpp:
(JSC::DFG::OSREntrypointCreationPhase::run):
* dfg/DFGPredictionInjectionPhase.cpp:
(JSC::DFG::PredictionInjectionPhase::run):
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArgumentTypes):
(JSC::DFG::SpeculativeJIT::linkOSREntries):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::run):
* dfg/DFGValidate.cpp:

Modified Paths

trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp
trunk/Source/_javascript_Core/dfg/DFGCFG.h
trunk/Source/_javascript_Core/dfg/DFGCPSRethreadingPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGDCEPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGGraph.cpp
trunk/Source/_javascript_Core/dfg/DFGGraph.h
trunk/Source/_javascript_Core/dfg/DFGInPlaceAbstractState.cpp
trunk/Source/_javascript_Core/dfg/DFGLoopPreHeaderCreationPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGMaximalFlushInsertionPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGOSREntrypointCreationPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGPredictionInjectionPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGSSAConversionPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
trunk/Source/_javascript_Core/dfg/DFGTypeCheckHoistingPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGValidate.cpp




Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (221636 => 221637)

--- trunk/Source/_javascript_Core/ChangeLog	2017-09-05 21:18:24 UTC (rev 221636)
+++ trunk/Source/_javascript_Core/ChangeLog	2017-09-05 21:30:05 UTC (rev 221637)
@@ -1,3 +1,62 @@
+2017-09-05  Saam Barati  
+
+Make the distinction between entrypoints and CFG roots more clear by naming things better
+https://bugs.webkit.org/show_bug.cgi?id=176336
+
+Reviewed by Mark Lam and Keith Miller and Michael Saboff.
+
+This patch does renaming to make the distinction between Graph::m_entrypoints
+and Graph::m_numberOfEntrypoints more clear. The source of confusion is that
+Graph::m_entrypoints.size() is not equivalent to Graph::m_numberOfEntrypoints.
+Graph::m_entrypoints is really just the CFG roots. In CPS, this vector has
+size >= 1. In SSA, the size is always 1. This patch renames Graph::m_entrypoints
+to Graph::m_roots. To be consistent, this patch also renames Graph's m_entrypointToArguments
+field to m_rootToArguments.
+
+Graph::m_numberOfEntrypoints retains its name. This field is only used in SSA
+when compiling with EntrySwitch. It represents the logical number of entrypoints
+the compilation will end up with. Each EntrySwitch has m_numberOfEntrypoints
+cases.
+
+* dfg/DFGByteCodeParser.cpp:
+(JSC::DFG::ByteCodeParser::parseBlock):
+(JSC::DFG::ByteCodeParser::parseCodeBlock):
+* dfg/DFGCFG.h:
+

[webkit-changes] [221607] trunk

2017-09-04 Thread sbarati

Title: [221607] trunk








Revision 221607
Author sbar...@apple.com
Date 2017-09-04 21:10:53 -0700 (Mon, 04 Sep 2017)


Log Message
typeCheckHoistingPhase may emit a CheckStructure on the empty value which leads to a dereference of zero on 64 bit platforms
https://bugs.webkit.org/show_bug.cgi?id=176317

Reviewed by Keith Miller.

JSTests:

* stress/dont-crash-when-hoist-check-structure-on-tdz.js: Added.
(Foo):

Source/_javascript_Core:

It turns out that TypeCheckHoistingPhase may hoist a CheckStructure up to
the SetLocal of a particular value where the value is the empty JSValue.
On 64-bit platforms, the empty value is zero. This means that the empty value
passes a cell check. This will lead to a crash when we dereference null to load
the value's structure. This patch teaches TypeCheckHoistingPhase to be conservative
in the structure checks it hoists. On 64-bit platforms, instead of emitting a
CheckStructure node, we now emit a CheckStructureOrEmpty node. This node allows
the empty value to flow through. If the value isn't empty, it'll perform the normal
structure check that CheckStructure performs. For now, we only emit CheckStructureOrEmpty
on 64-bit platforms since a cell check on 32-bit platforms does not allow the empty
value to flow through.

* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* 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/DFGNode.h:
(JSC::DFG::Node::convertCheckStructureOrEmptyToCheckStructure):
(JSC::DFG::Node::hasStructureSet):
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::SafeToExecuteEdge):
(JSC::DFG::SafeToExecuteEdge::operator()):
(JSC::DFG::SafeToExecuteEdge::maySeeEmptyChild):
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitStructureCheck):
(JSC::DFG::SpeculativeJIT::compileCheckStructure):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::run):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckStructureOrEmpty):

Modified Paths

trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h
trunk/Source/_javascript_Core/dfg/DFGArgumentsEliminationPhase.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/DFGNode.h
trunk/Source/_javascript_Core/dfg/DFGNodeType.h
trunk/Source/_javascript_Core/dfg/DFGObjectAllocationSinkingPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGPredictionPropagationPhase.cpp
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/DFGSpeculativeJIT32_64.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp
trunk/Source/_javascript_Core/dfg/DFGTypeCheckHoistingPhase.cpp
trunk/Source/_javascript_Core/dfg/DFGValidate.cpp
trunk/Source/_javascript_Core/ftl/FTLCapabilities.cpp
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp


Added Paths

trunk/JSTests/stress/dont-crash-when-hoist-check-structure-on-tdz.js




Diff

Modified: trunk/JSTests/ChangeLog (221606 => 221607)

--- trunk/JSTests/ChangeLog	2017-09-05 03:44:05 UTC (rev 221606)
+++ trunk/JSTests/ChangeLog	2017-09-05 04:10:53 UTC (rev 221607)
@@ -1,3 +1,13 @@
+2017-09-04  Saam Barati  
+
+typeCheckHoistingPhase may emit a CheckStructure on the empty value which leads to a dereference of zero on 64 bit platforms
+https://bugs.webkit.org/show_bug.cgi?id=176317
+
+Reviewed by Keith Miller.
+
+* stress/dont-crash-when-hoist-check-structure-on-tdz.js: Added.
+(Foo):
+
 2017-09-03  Yusuke Suzuki  
 
 [DFG][FTL] Efficiently execute number#toString()


Added: trunk/JSTests/stress/dont-crash-when-hoist-check-structure-on-tdz.js (0 => 221607)

--- trunk/JSTests/stress/dont-crash-when-hoist-check-structure-on-tdz.js	(rev 0)
+++ trunk/JSTests/stress/dont-crash-when-hoist-check-structure-on-tdz.js	2017-09-05 04:10:53 UTC (rev 221607)
@@ -0,0 +1,28 @@
+class Foo extends Object {
+constructor(c1, c2) {
+if (c1)
+super();
+let

< 2 3 4 5 6 7 8 9 10 11 >

601 - 700 of 1147 matches

Mail list logo