On Tue, 27 Jan 2026 14:26:45 GMT, Chen Liang <liach@openjdk.org> wrote:
I don't think this is worth it - most user programs will refer to UTF_8 as StandardCharsets.UTF_8, so this doesn't really optimize anything. Also in the ArrayDeque to ArrayList case, ArrayList has other allocation benefits in addition to avoiding ArrayDeque class load. So I personally recommend withdrawing this patch, especially that AOT preimage should be able to capture the linked or even initialized state of StandardCharsets class.
Some context: I spotted this because I've gotten review feedback in the past (from @cl4es IIRC) about avoiding `StandardCharsets` in this class. The current version of the class has three occurrences of `UTF_8.INSTANCE` besides this one recently introduced `StandardCharsets.UTF_8` instance. So there is a consistency issue here as well, besides any (valid or invalid) performance concerns. See also the following note from `StandardCharsets`: // To avoid accidental eager initialization of often unused Charsets // from happening while the VM is booting up, which may delay // initialization of VM components, we should generally avoid depending // on this class from elsewhere in java.base. @cl4es may have opinions about the present validity of this note. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29443#issuecomment-3805613881