[turbofan] Bump the fast literal properties budget for JSCreateLowering.

We have a weird performance cliff, where using an object literal for
allocation is way slower than using a constructor function, or starting
from the empty object literal and using transitioning stores. The reason
is that we limit the inlining of JSCreateLiteralObject nodes in TurboFan
to max. 8 fast properties. So as soon as you get above 8, you'll get a
runtime function call to %CreateObjectLiteral, which is a lot slower
than the inlined allocation and initialization. Still not ideal, but
less unpredictable (hopefully).

R=jarin@chromium.org
BUG=v8:6211

Review-Url: https://codereview.chromium.org/2805613002
Cr-Commit-Position: refs/heads/master@{#44424}

src/compiler/js-create-lowering.cc

@@ -198,9 +198,13 @@ bool IsFastLiteral(Handle<JSObject> boilerplate, int max_depth,
 }
 
 // Maximum depth and total number of elements and properties for literal
-// graphs to be considered for fast deep-copying.
+// graphs to be considered for fast deep-copying. The limit is chosen to
+// match the maximum number of inobject properties, to ensure that the
+// performance of using object literals is not worse than using constructor
+// functions, see crbug.com/v8/6211 for details.
 const int kMaxFastLiteralDepth = 3;
-const int kMaxFastLiteralProperties = 8;
+const int kMaxFastLiteralProperties =
+    (JSObject::kMaxInstanceSize - JSObject::kHeaderSize) >> kPointerSizeLog2;
 
 }  // namespace