4 ms·
> After a defensive copy of the byte-array is made, just before returning the newly constructed string object, verify once again that the chosen coder matches t
by cempaka 3y ago
> After a defensive copy of the byte-array is made, just before returning the newly constructed string object, verify once again that the chosen coder matches the string contents.
Allocating new String objects might very well be the most frequent memory allocation operation in the JVM. IMO it would be a mistake to do anything to slow this down to protect against this weird instantiation behavior, unless it implies a security vulnerability which can't be fixed by guards at the interning step.
- whack 3y agoThe language maintainers have already decided to slow down string-construction by calling StringUTF16.compress(value) which checks if the input can be converted into LATIN1 and if so, creating a LATIN1 byte-array representation from the ground up. Compared to this, I wager that the incremental cost is small to verify that the coder matches the content. Also, depending on the implementation of string-interning and StringUTF16.compress, it's possible that the verification step is only needed for non-LATIN1 strings. Which according to the JEP is only a small minority of strings seen. If there is a cheaper solution, I'm certainly all for it. I'm just spitballing ideas here. But I don't think it is acceptable to allow "hello world".startsWith("hello") to return false.
- Genbox 3y agoMaking the 99% case faster at the cost of making the 1% case slower, is a speedup.
- masklinn 3y agoI don’t think you need any defensive copy, just to have compress switch to utf16 mode when it encounters a non-latin1 char and go on from there. It would likely be faster since currently the implementation restarts the entire conversion from 0 in utf16 mode.