On Mon, 3 Feb 2025 17:04:33 GMT, Shaojin Wen <s...@openjdk.org> wrote:
>> Jaikiran Pai has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. The pull request contains two >> new commits since the last revision: >> >> - Revert "8333893: Optimization for StringBuilder append boolean & null" >> >> This reverts commit 5890d9438bbde88b89070052926a2eafe13d7b42. >> - Revert "8343650: Reuse StringLatin1::putCharsAt and >> StringUTF16::putCharsAt" >> >> This reverts commit 74ae3c688b37e693e20eb4e17c631897c5464400. > > This concurrency problem also exists in the UTF16 scenario, so why only > change to Latin1 here? @wenshao this re-instates the `checkBoundsBeginEnd(i, end, value);` in the UTF16 case that was removed by the issue being backed out, so we get back to a state where we have appropriate bounds checks on all array accesses. An alternative to this backout would be to add `checkBoundsBeginEnd(i, end, value);` to all the `putCharsAt` methods, though it's unclear if that would undo the performance advantage. Better then to backout and - if possible - redo with a closer examination of the performance with a safer construct. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23420#issuecomment-2631644364
