3 ms·
Can someone add 2012 in the title, Most of the OpenJDK collections have been rewritten during the Java 8 timeframe, so the values are out of date :(
by dr_rust 10y ago
Can someone add 2012 in the title,
Most of the OpenJDK collections have been rewritten during the Java 8 timeframe, so the values are out of date :(
- geodel 10y agoI think the object layout is not changed. I just ran jol tool for HashMap and size looks similar to what is mentioned in the article.
- dr_rust 10y agoYou may be right, i don't know. Tracking a cause of OutOfMemoryError recently (we maintain several applications written in Java at my day job), i've observed that most data-structures have a size very different if empty or not.
- hyperpape 10y agoYes, because many of them allocate a zero size array when you call their constructor and then lazily add to it. But that isn't really about object layout as I think of it, so much as what the fields of a particular object are.
- jcdavis 10y agoString is one that has changed pretty significantly - count and offset have been removed, only fields are hash and value now. This means String.substring is no longer an O(1) method, but it saves 8 bytes per string which is huge, and also avoids some of the wierd corner case GC/memory issues that substring/StringBuilder caused by hanging on to the reference
- geodel 10y agoRight. Java 9 will move from char[] to byte[] for String.value which will lead to further savings.
- needusername 10y agoActually it's worse. You're more likely to have hash collisions and if you have enough of them you'll overflow into a red-black tree which has an even higher memory footprint. If you care about memory footprint use Eclipse Collections.
- the8472 10y ago> You're more likely to have hash collisions You are? I know they introduced the tree nodes as fallback if you have a bad hashing algorithm or malicious inputs, but that doesn't mean the hash collision rate got worse by default.
- needusername 10y agoYes you are because HashMap.hash(Object) was changed.
- the8472 10y agoThat is only matters if your keys had badly distributed hashes in the first place.
- needusername 10y agoUhm no. The hash code of my keys may be perfectly distributed but then HashMap#getNode comes along and masks most of my bits away. HashMap#hash(Object) is supposed to make the impact of the masking less bad.
- the8472 10y agoIf your hashes are perfectly distributed, as in each bit having a 50% probability of being 1, independent of all other bits, then the low order bits will be just as random as the high order bits, no "making the impact less bad" required.
- dang 10y agoAdded.