RFR: 8356165: System.in in jshell replace supplementary characters with ?? [v3]
Jan Lahoda
jlahoda at openjdk.org
Mon May 19 13:12:55 UTC 2025
On Mon, 19 May 2025 12:52:51 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:
>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java line 980:
>>
>>> 978: if (pendingBytes == null || pendingBytes.length <= pendingBytesPointer) {
>>> 979: char userChar = readUserInputChar();
>>> 980: StringBuilder dataToConvert = new StringBuilder();
>>
>> FWIW I think we can avoid using StringBuilder (and make the code more RAM-friendly):
>>
>>
>> char[] dataToConvert = { useChar, '\0' };
>> // if (...) {
>> // ...
>> // if (...) {
>> // ...
>> dataToConvert[1] = lowSurrogate;
>> // }
>> // ...
>> // }
>> // low-surrogate code unit never be null char
>> pendingBytes = dataToConvert[1] != '\0' ? String.valueOf(dataToConvert) : String.valueOf(dataToConvert[0]);
>>
>>
>> The next version of .NET is said to be able to allocate such a tiny array to the stack, instead of the heap, but I don't know whether JVM can do the same optimization.
>
> We could do something like that, although I wrote it as I wrote it mostly because that's more clearly correct. Although the current tests probably cover all the cases, so with a bit of work, we probably could eliminate the (explicit) array completely.
>
> Overall, on most places, it is usually not necessary to be too clever - the VM can optimize and eliminate allocations if needed.
>
> I'll leave it up to Adam and/or Christian whether they would prefer a slightly more complex code with less (explicit/visible) allocation.
FWIW, we could do this:
https://github.com/lahodaj/jdk/commit/6a07648829ee8df263cf3fc1c55055fe45d4eb17
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25079#discussion_r2095681607
More information about the kulla-dev
mailing list