Uploaded image for project: 'Lucene - Core'
  1. Lucene - Core
  2. LUCENE-3867

RamUsageEstimator.NUM_BYTES_ARRAY_HEADER and other constants are incorrect

Details

    • Bug
    • Status: Closed
    • Trivial
    • Resolution: Fixed
    • None
    • 3.6, 4.0-ALPHA
    • core/index
    • None
    • New, Patch Available

    Description

      RamUsageEstimator.NUM_BYTES_ARRAY_HEADER is computed like that: NUM_BYTES_OBJECT_HEADER + NUM_BYTES_INT + NUM_BYTES_OBJECT_REF. The NUM_BYTES_OBJECT_REF part should not be included, at least not according to this page: http://www.javamex.com/tutorials/memory/array_memory_usage.shtml

      A single-dimension array is a single object. As expected, the array has the usual object header. However, this object head is 12 bytes to accommodate a four-byte array length. Then comes the actual array data which, as you might expect, consists of the number of elements multiplied by the number of bytes required for one element, depending on its type. The memory usage for one element is 4 bytes for an object reference ...

      While on it, I wrote a sizeOf(String) impl, and I wonder how do people feel about including such helper methods in RUE, as static, stateless, methods? It's not perfect, there's some room for improvement I'm sure, here it is:

      	/**
      	 * Computes the approximate size of a String object. Note that if this object
      	 * is also referenced by another object, you should add
      	 * {@link RamUsageEstimator#NUM_BYTES_OBJECT_REF} to the result of this
      	 * method.
      	 */
      	public static int sizeOf(String str) {
      		return 2 * str.length() + 6 // chars + additional safeness for arrays alignment
      				+ 3 * RamUsageEstimator.NUM_BYTES_INT // String maintains 3 integers
      				+ RamUsageEstimator.NUM_BYTES_ARRAY_HEADER // char[] array
      				+ RamUsageEstimator.NUM_BYTES_OBJECT_HEADER; // String object
      	}
      

      If people are not against it, I'd like to also add sizeOf(int[] / byte[] / long[] / double[] ... and String[]).

      Attachments

        1. LUCENE-3867.patch
          39 kB
          Dawid Weiss
        2. LUCENE-3867.patch
          314 kB
          Dawid Weiss
        3. LUCENE-3867.patch
          49 kB
          Uwe Schindler
        4. LUCENE-3867.patch
          49 kB
          Uwe Schindler
        5. LUCENE-3867.patch
          49 kB
          Uwe Schindler
        6. LUCENE-3867.patch
          49 kB
          Dawid Weiss
        7. LUCENE-3867.patch
          35 kB
          Uwe Schindler
        8. LUCENE-3867.patch
          35 kB
          Uwe Schindler
        9. LUCENE-3867.patch
          32 kB
          Uwe Schindler
        10. LUCENE-3867.patch
          32 kB
          Uwe Schindler
        11. LUCENE-3867.patch
          27 kB
          Uwe Schindler
        12. LUCENE-3867.patch
          25 kB
          Uwe Schindler
        13. LUCENE-3867.patch
          17 kB
          Uwe Schindler
        14. LUCENE-3867.patch
          13 kB
          Uwe Schindler
        15. LUCENE-3867.patch
          10 kB
          Shai Erera
        16. LUCENE-3867.patch
          10 kB
          Shai Erera
        17. LUCENE-3867.patch
          7 kB
          Uwe Schindler
        18. LUCENE-3867.patch
          7 kB
          Uwe Schindler
        19. LUCENE-3867.patch
          6 kB
          Shai Erera
        20. LUCENE-3867-3.x.patch
          53 kB
          Uwe Schindler
        21. LUCENE-3867-compressedOops.patch
          4 kB
          Uwe Schindler

        Activity

          People

            uschindler Uwe Schindler
            shaie Shai Erera
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: