Github user mridulm commented on a diff in the pull request:

    https://github.com/apache/spark/pull/16196#discussion_r91271510
  
    --- Diff: core/src/main/scala/org/apache/spark/util/SizeEstimator.scala ---
    @@ -316,62 +338,40 @@ object SizeEstimator extends Logging {
        */
       private def getClassInfo(cls: Class[_]): ClassInfo = {
         // Check whether we've already cached a ClassInfo for this class
    -    val info = classInfos.get(cls)
    +    val info = classInfos.get().get(cls)
         if (info != null) {
           return info
         }
     
         val parent = getClassInfo(cls.getSuperclass)
    +    val fields = cls.getDeclaredFields
    +    val fieldCount = fields.length
         var shellSize = parent.shellSize
    -    var pointerFields = parent.pointerFields
    -    val sizeCount = Array.fill(fieldSizes.max + 1)(0)
    +    var fieldOffsets = parent.fieldOffsets.toList
    +
    +    var index = 0
     
    -    // iterate through the fields of this class and gather information.
    -    for (field <- cls.getDeclaredFields) {
    +    while (index < fieldCount) {
    +      val field = fields(index)
           if (!Modifier.isStatic(field.getModifiers)) {
             val fieldClass = field.getType
             if (fieldClass.isPrimitive) {
    -          sizeCount(primitiveSize(fieldClass)) += 1
    +          if (cls == classOf[Double] || cls == classOf[Long]) {
    +            shellSize += 8
    +          } else {
    +            shellSize += 4
    +          }
             } else {
    -          field.setAccessible(true) // Enable future get()'s on this field
    -          sizeCount(pointerSize) += 1
    -          pointerFields = field :: pointerFields
    +          shellSize += pointerSize
    +          fieldOffsets = Unsafe.instance.objectFieldOffset(field).toInt :: 
fieldOffsets
             }
           }
    +      index += 1
         }
     
    -    // Based on the simulated field layout code in Aleksey Shipilev's 
report:
    -    // 
http://cr.openjdk.java.net/~shade/papers/2013-shipilev-fieldlayout-latest.pdf
    -    // The code is in Figure 9.
    -    // The simplified idea of field layout consists of 4 parts (see more 
details in the report):
    -    //
    -    // 1. field alignment: HotSpot lays out the fields aligned by their 
size.
    -    // 2. object alignment: HotSpot rounds instance size up to 8 bytes
    -    // 3. consistent fields layouts throughout the hierarchy: This means 
we should layout
    -    // superclass first. And we can use superclass's shellSize as a 
starting point to layout the
    -    // other fields in this class.
    -    // 4. class alignment: HotSpot rounds field blocks up to to 
HeapOopSize not 4 bytes, confirmed
    -    // with Aleksey. see 
https://bugs.openjdk.java.net/browse/CODETOOLS-7901322
    -    //
    -    // The real world field layout is much more complicated. There are 
three kinds of fields
    -    // order in Java 8. And we don't consider the @contended annotation 
introduced by Java 8.
    -    // see the HotSpot classloader code, layout_fields method for more 
details.
    -    // 
hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/share/vm/classfile/classFileParser.cpp
    -    var alignedSize = shellSize
    -    for (size <- fieldSizes if sizeCount(size) > 0) {
    -      val count = sizeCount(size).toLong
    -      // If there are internal gaps, smaller field can fit in.
    -      alignedSize = math.max(alignedSize, alignSizeUp(shellSize, size) + 
size * count)
    -      shellSize += size * count
    -    }
    -
    -    // Should choose a larger size to be new shellSize and clearly 
alignedSize >= shellSize, and
    -    // round up the instance filed blocks
    -    shellSize = alignSizeUp(alignedSize, pointerSize)
    -
         // Create and cache a new ClassInfo
    -    val newInfo = new ClassInfo(shellSize, pointerFields)
    -    classInfos.put(cls, newInfo)
    +    val newInfo = new ClassInfo(shellSize, fieldOffsets.toArray)
    --- End diff --
    
    We are loosing out on padding due to allignment here which the earlier code 
was computing. No ?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org

Reply via email to