Java 8 introduced String Deduplication that can be enabled by launching JVM with -XX:+UseStringDeduplication option allowing to save some memory by referencing similar String objects instead of keeping duplicates. Of course it's effectiveness varies from program to program depending on utilisation of Strings but I think it is safe to say that in general it can be considered beneficial for most applications (if not all) making me wonder about few things:
Why is it not enabled by default? Is it because of costs associated with dedeuplication or simply because G1GC is still considered new?
Are there (or could there be) any edge cases where you would not want to use deduplication?
(Hypothetical) cases where String de-duplication could be harmful include:
There are lots of strings but a very low probability of duplicates: the time overhead of looking for duplicates and the space overhead of the de-duping data structure would not be repaid.
There is a reasonable probability of duplicates, but most strings die in within a couple of GC cycles1 anyway. The de-duplication is less beneficial if the de-duped strings were going to be GC'ed soon anyway.
(This is not about strings that don't survive the first GC cycle. It would make no sense for the GC to even try to de-dup strings that it knows to be garbage.)
We can only speculate as to why the Java team didn't turn on de-duping by default, but they are in a much better position to make rational (i.e. evidence based) decisions on this that you and I. My understanding is that they have access to many large real-world applications for benchmarking / trying out the effects of optimizations. They may also have contacts in partner or customer organizations with similarly large code-bases and concerns about efficiency ... who they can ask for feedback on whether optimizations in an early access release work as expected.
1 - This depends on the value of the StringDeduplicationAgeThreshold
JVM setting. This defaults to 3 meaning that (roughly) a string has to survive 3 minor collections or a major collection to be considered for de-duping. But anyhow, if a string is de-duped and then found to be unreachable shortly afterwards, the de-duping overheads will not be repaid for that string.
If you are asking when you should consider enabling de-duping, my advice would be to try it and see if it helps on a per-application basis. But you need to do some application-level benchmarking (which takes effort!) to be sure that the de-duping is beneficial ...
A careful read of JEP 192 would also help you understand the issues, and make a judgment on how they might apply for your Java application.