1

I have a hash set of 1000 strings. Each string is having a size of 10.

Can you tell me the exact number of bytes required to store this in memory? Both for 32bit and 64bit VMs.

Can you explain the way to calculate this?

Ani
  • 722
  • 9
  • 27
  • @SotiriosDelimanolis Shouldn't it not matter because `String` uses `char[]` internally and `size()` returns the length of that array? – awksp Jun 16 '14 at 23:36
  • 1
    If you want to find this out yourself you can use [`getObjectSize()`](http://docs.oracle.com/javase/8/docs/api/java/lang/instrument/Instrumentation.html#getObjectSize-java.lang.Object-) from the `Instrumentation` interface – awksp Jun 16 '14 at 23:37
  • 1
    @user3580294 Yeah, good point. (Please set your name. I keep confusing you with other users that just created their accounts.) – Sotirios Delimanolis Jun 16 '14 at 23:40
  • 1
    To be honest, I'm not sure if you can feasibly calculate this by hand... Object attributes are aligned on 8-byte borders, and some rearranging is done to save memory, and all in all it's a ton of work that I'm not sure too many people would want to do... – awksp Jun 17 '14 at 00:05
  • possible duplicate of [How to find Object's size (including contained objects)](http://stackoverflow.com/questions/16882277/how-to-find-objects-size-including-contained-objects) – The Guy with The Hat Jun 17 '14 at 00:38
  • @SotiriosDelimanolis Sorry about that, I'll get around to it when I come up with something not terrible... – awksp Jun 17 '14 at 01:07

1 Answers1

8

Because I have no life, I present the results of boredom. Note that this is pretty much guaranteed to be inaccurate, due stupid mistakes and such. Used this for help, but I'm not too sure on accuracy. I could read the JVM specifications, but I don't have that much free time on my hands.

This calculation gets pretty complicated due to the multitude of fields that exist inside the objects of concern, plus some uncertainty on my part about how much overhead there is for objects and where padding goes. If memory serves, objects have 8 bytes reserved for the header. This is all for a 64-bit VM, by the way. Only difference between that and a 32-bit VM is the size of references, I think.

Summary of how to do this: Obtain source code, and recursively add up space needed for all fields. Need knowledge of how VM works and how implementations work.

Starting from a String. String defines:

  1. Object header - 8 bytes
  2. long serialVersionUID - 8 bytes
  3. int hash - 4 bytes + 4 bytes padding
  4. char[] value (set to a char[10] in your case) - 8 bytes for reference
  5. ObjectStreamField[] serialPersistentFields = new ObjectStreamField[0] - 8 bytes for reference

char[10] defines:

  1. Object header - 8 bytes
  2. int length - 4 bytes
  3. char x10 - 2 bytes * 10 = 20 bytes

ObjectStreamField[0] defines:

  1. Object header - 8 bytes
  2. int length - 4 bytes + 4 bytes padding

Total for a single String with length 10: 88 bytes

Total for 1000 Strings with length 10: 88000 bytes.

HashSet defines:

  1. Object header - 8 bytes
  2. long serialVersionUID - 8 bytes
  3. Object PRESENT - 8 bytes
  4. HashMap<E, Object> map - 8 bytes

HashMap defines (in Java 8) (ignoring things that are created on demand, like EntrySet):

  1. Object header - 8 bytes
  2. long serialVersionUID - 8 bytes
  3. int DEFAULT_INITIAL_CAPACITY - 4 bytes
  4. int MAXIMUM_CAPACITY - 4 bytes
  5. int TREEIFY_THRESHOLD - 4 bytes
  6. int UNTREEIFY_THRESHOLD - 4 bytes
  7. int MIN_TREEIFY_CAPACITY - 4 bytes
  8. int size - 4 bytes
  9. int modcount - 4 bytes
  10. int threshold - 4 bytes
  11. float DEFAULT_LOAD_FACTOR - 4 bytes
  12. float loadFactor - 4 bytes
  13. Node<K, V>[] table - 8 bytes

Node defines:

  1. Object header - 8 bytes
  2. int hash - 4 bytes + 4 bytes padding
  3. K key - 8 bytes
  4. V value - 8 bytes
  5. Node<K, V> next - 8 bytes

Node<K, V>[] should have a size of 2048, if I remember how HashMap works. So it defines:

  1. Object header - 8 bytes
  2. int length - 4 bytes + 4 bytes padding
  3. Node<K, V> reference * 2048 - 8 bytes * 2048 = 16384 bytes.

So the HashSet should be:

  1. 32 bytes for just HashSet
  2. 64 bytes for just HashMap
  3. 40 bytes per Node<K, V> inside Node<K, V>[] * 1000 nodes = 40000 bytes
  4. 16400 bytes for Node<K, V>[] inside the HashMap

Total: 56496 bytes for the HashSet, without taking into account the String contents

So at least by my calculations, the total space taken should be somewhere around 144496 bytes -- about 141 kilobytes (kibibytes for the pedantic). To be honest, this seems like it's more than a bit on the small side, but it's a start.

I can't get the Instrumentation interface working at the moment, so I can't double-check. But if someone knows what he/she is doing a comment pointing out my mistakes would be welcome.

awksp
  • 11,764
  • 4
  • 37
  • 44
  • If the Strings are not unique, they might be pooled and therefore use less space. This is up to the JVM implementation though. – Ole Jan 31 '18 at 10:12