Introduction Measuring an object’s size in Java is not straightforward. The platform encourages you to consider references and abstractions rather than raw memory usage. Still, understanding how objects fit into memory can yield significant benefits, especially for high-performance, low-latency systems. Over time, the JVM has introduced optimisations like Compressed Ordinary Object Pointers (Compressed Oops) and, more recently, Compact Object Headers. Each of these can influence how large or small your objects appear. Understanding these factors helps you reason about memory usage more concretely. Measuring Object Sizes In principle, you can estimate an object’s size by creating instances and observing changes in the JVM’s free memory. However, you must neutralise certain factors to get consistent results. For example, turning off TLAB allocation ( -XX:-UseTLAB ) makes memory usage more directly observable. Repeated measurements and median calculations can reduce the im...
Thank you for the puzzle!
ReplyDeleteUnfortunately, I couldn't clearly understand the source of such behaviour. I suppose the the reason is in a way how String Constant Pool selects constants on a base of hashCode() execution. But I'm not sure.
So will wait for your solution :)
P.S. could you, please, allow comments and RSS subscription on your GitHub blog?
I read that internally String Constant Pool uses Hashtable for storing strings. So looks like equal hashCode() values isn't enough for getting puzzle effect. Also, at the first sight, external synchs on "bb" and "cC" really work on String instance wrappers not on internally char[] arrays...
DeleteSo the puzzle is really puzzle :)