Related is the use of a string constant to get runtime initialization cost of nothing – the string constant is stored directly in the class file. So your string might look something like “0100111101010” and you’d just mask off the low-order bit. This ought to have an initialization cost near 0.
Matthew Wozniczkasays:
private final byte[] FTW
Matthew Wozniczkasays:
Actually, I was thinking boolean[], lol.
Jean-Marie Gaillourdetsays:
Java is probably smart enough not to store multiple times in memory the string “Found”. It might store it just once.
The Java language spec does guarantee that two strings that are identical and originate from literals in the source, are represented by the same object at runtime. That is called interning in Java, see the documentation of java.lang.String.intern() and https://docs.oracle.com/javase/specs/jls/se16/jls16.pdf Chapter 12.5, first bullet point). If the same string is read from a file, that string may be a different object instance.
The newer garbage collectors of the JVM even try to find identical strings to merge them into one object.
anonsays:
The newer garbage collectors of the JVM even try to find identical strings to merge them into one object.
Unfortunately not. They try to merge the underlying storage (morally char[]). They don’t try to merge the objects. This is not as good, because in many cases strings are short and the object overhead (14-20 bytes) dominates the size.
Afaiu the jvm cannot merge the objects: The somewhat ill-considered java semantics allow to distinguish whether two strings have equal contents (.equals / .hashCode) or are identical (== / System.identityHashCode), also in context of synchronization.
So there would need to be some change in java semantics in order to permit the JVM to dedup objects. And java never breaks old promises from simpler times 🙁
Related is the use of a string constant to get runtime initialization cost of nothing – the string constant is stored directly in the class file. So your string might look something like “0100111101010” and you’d just mask off the low-order bit. This ought to have an initialization cost near 0.
private final byte[] FTW
Actually, I was thinking boolean[], lol.
The Java language spec does guarantee that two strings that are identical and originate from literals in the source, are represented by the same object at runtime. That is called interning in Java, see the documentation of java.lang.String.intern() and https://docs.oracle.com/javase/specs/jls/se16/jls16.pdf Chapter 12.5, first bullet point). If the same string is read from a file, that string may be a different object instance.
The newer garbage collectors of the JVM even try to find identical strings to merge them into one object.
Unfortunately not. They try to merge the underlying storage (morally
char[]). They don’t try to merge the objects. This is not as good, because in many cases strings are short and the object overhead (14-20 bytes) dominates the size.Afaiu the jvm cannot merge the objects: The somewhat ill-considered java semantics allow to distinguish whether two strings have equal contents (.equals / .hashCode) or are identical (== / System.identityHashCode), also in context of synchronization.
So there would need to be some change in java semantics in order to permit the JVM to dedup objects. And java never breaks old promises from simpler times 🙁