Currently, most (if not all) literals in Scarpet code will be their own String instance, given those are generated by reading a file, not in Java source code. Suggestion for those literal strings to be interned into Java's constant pool (by replacing them with the result of String.intern()) during app load.
Motivation for this is not really memory usage, given the GC (at least G1) can deduplicate the backing array of equal strings at runtime, and the String instance itself doesn't use that much extra memory.
However string equality checks have a short path for reference equality. Given a lot of functions in Scarpet are ran by checking equality on String parameters, this could give a performance boost where those are specified in literals in Scarpet code with a (small?) cost on app load time.
Strings interned in the constant pool are regularly garbage collected btw, it wouldn't cause a memory leak with app unload.
Currently, most (if not all) literals in Scarpet code will be their own
String
instance, given those are generated by reading a file, not in Java source code. Suggestion for those literal strings to be interned into Java's constant pool (by replacing them with the result ofString.intern()
) during app load.Motivation for this is not really memory usage, given the GC (at least G1) can deduplicate the backing array of equal strings at runtime, and the
String
instance itself doesn't use that much extra memory.However string equality checks have a short path for reference equality. Given a lot of functions in Scarpet are ran by checking equality on
String
parameters, this could give a performance boost where those are specified in literals in Scarpet code with a (small?) cost on app load time.Strings interned in the constant pool are regularly garbage collected btw, it wouldn't cause a memory leak with app unload.