Bugzilla

Getting back on topic, the possibility of a compiler bug is cropping up again. It's not the stack protector; building the entire browser without the stack protector didn't fix it. However, while stumbling around with printfs, this did:

diff -r 7ab4a0c9980f js/xpconnect/src/XPCWrappedNative.cpp
--- a/js/xpconnect/src/XPCWrappedNative.cpp     Sat Feb 16 11:36:46 2019 +0200
+++ b/js/xpconnect/src/XPCWrappedNative.cpp     Tue Feb 26 21:30:14 2019 -0800
@@ -1630,16 +1630,20 @@
 
   return true;
 }
 
 nsresult CallMethodHelper::Invoke() {
   uint32_t argc = mDispatchParams.Length();
   nsXPTCVariant* argv = mDispatchParams.Elements();
 
+if (mVTableIndex == 8 && argv[0].type == 15 && argv[1].type == 8) {
+  fprintf(stderr, "HIT!!!\n");
+}
+
   return NS_InvokeByIndex(mCallee, mVTableIndex, argc, argv);
 }
 
 static void TraceParam(JSTracer* aTrc, void* aVal, const nsXPTType& aType,
                        uint32_t aArrayLen = 0) {
   if (aType.Tag() == nsXPTType::T_JSVAL) {
     JS::UnsafeTraceRoot(aTrc, (JS::Value*)aVal,
                         "XPCWrappedNative::CallMethod param");

Dan, confirm, but your deoptimization from comment 35 also seems to fix the glitch, so we're back to suspecting the compiler.

I'm trying to see if a more targetted deoptimization in the call stack will still yield good performance. Either way, I'm just going to yank my stack protector patch at the same time since all it did was probably tickle the compiler somewhere else.

Getting back on topic, the possibility of a compiler bug is cropping up again. It's not the stack protector; building the entire browser without the stack protector didn't fix it. However, while stumbling around with printfs, this did:

```
diff -r 7ab4a0c9980f js/xpconnect/src/XPCWrappedNative.cpp
--- a/js/xpconnect/src/XPCWrappedNative.cpp     Sat Feb 16 11:36:46 2019 +0200
+++ b/js/xpconnect/src/XPCWrappedNative.cpp     Tue Feb 26 21:30:14 2019 -0800
@@ -1630,16 +1630,20 @@
 
   return true;
 }
 
 nsresult CallMethodHelper::Invoke() {
   uint32_t argc = mDispatchParams.Length();
   nsXPTCVariant* argv = mDispatchParams.Elements();
 
+if (mVTableIndex == 8 && argv[0].type == 15 && argv[1].type == 8) {
+  fprintf(stderr, "HIT!!!\n");
+}
+
   return NS_InvokeByIndex(mCallee, mVTableIndex, argc, argv);
 }
 
 static void TraceParam(JSTracer* aTrc, void* aVal, const nsXPTType& aType,
                        uint32_t aArrayLen = 0) {
   if (aType.Tag() == nsXPTType::T_JSVAL) {
     JS::UnsafeTraceRoot(aTrc, (JS::Value*)aVal,
                         "XPCWrappedNative::CallMethod param");
```

Dan, confirm, but your deoptimization from comment 35 also seems to fix the glitch, so we're back to suspecting the compiler.

I'm trying to see if a more targetted deoptimization in the call stack will still yield good performance. Either way, I'm just going to yank my stack protector patch at the same time since all it did was probably tickle the compiler somewhere else.