Remove JsObject lazy vals

[htmldoug]

Purpose

Reduce memory footprint by removing the (now unnecessary) lazy vals from JsObject.

Background Context

Many of our production OOME heap dumps show JsValue consuming the majority of memory. I've seen scenarios where there are either too many objects (batching, parallelism), unexpectedly large objects (services returning unwanted data), or both. Regardless of other possible mitigations, it would be nice to reduce the memory footprint of JsValue.

In my previous PRs, I migrated most remaining internal usage off of the two lazy vals in JsObject.

• lazy val value: Map[String, JsValue] is now completely avoided, and JsObject provides an immutable underlying Map by default.
  • Better handle String hashCode collisions in JsLookup #674
  • Change jsObject.value to ImmutableLinkedHashMap to mitigate hash collisions #675
• lazy val fields: Seq[(String, JsValue)] - is no longer used for hashCode/equals, and the last remaining uses don't seem to benefit from having an additional memoized Seq floating around.
  • Optimize JsObject.equals()/hashCode() #692

Caveats

The only drawbacks I can think of are in situations:

• if users explicitly stuff a truly mutable.Map into JsObject, in which case, they can restore the memoization of value (which isn't used internally anyway) by wrapping it in an immutable/unmodifiable wrapper.
• if users are reading fields (no longer used internally) more than once, but it's difficult to think of use cases for this. If desired, override val fields = super.fields.

While these (rare?) situations can be mitigated, the memory footprint of JsObject cannot be fixed in user space.

Benefits

• Memory footprint of JsObject: 32 bytes => 16 bytes
  • better OOME tolerance
  • reduced GC pressure
• lazy val initialization check on value is gone which usually results in a ~5% improvement on access

ClassLayout

ClassLayout.parseClass(classOf[JsObject]).toPrintable

Before:

play.api.libs.json.JsObject object internals:
OFF  SZ                   TYPE DESCRIPTION               VALUE
  0   8                        (object header: mark)     N/A
  8   4                        (object header: class)    N/A
 12   1                   byte JsObject.bitmap$0         N/A
 13   3                        (alignment/padding gap)   
 16   4   scala.collection.Seq JsObject.fields           N/A
 20   4   scala.collection.Map JsObject.value            N/A
 24   4   scala.collection.Map JsObject.underlying       N/A
 28   4                        (object alignment gap)    
Instance size: 32 bytes
Space losses: 3 bytes internal + 4 bytes external = 7 bytes total

After:

play.api.libs.json.JsObject object internals:
OFF  SZ                   TYPE DESCRIPTION               VALUE
  0   8                        (object header: mark)     N/A
  8   4                        (object header: class)    N/A
 12   4   scala.collection.Map JsObject.underlying       N/A
Instance size: 16 bytes
Space losses: 0 bytes internal + 0 bytes external = 0 bytes total

[htmldoug]

Note that our underlying LinkedHashMap correctly preserves order on + for existing keys.

scala> lhm
val res3: java.util.LinkedHashMap[String, Int] = {1=1, 2=2, 3=3}

scala> lhm.put("2", 2222222)
val res4: Int = 2

scala> lhm
val res5: java.util.LinkedHashMap[String, Int] = {1=1, 2=2222222, 3=3}

[htmldoug]

@gmethvin, WDYT?

[gmethvin]

Yes, I think given the optimizations you've done, it's probably not worth having these lazy vals anymore.