On Thu, 1 Jun 2023 08:50:33 GMT, Severin Gehwolf <sgehw...@openjdk.org> wrote:
>> The current code for cgroup support in the JDK has large and expensive
>> dependencies: it uses NIO, streams, and regular expressions. This leads to
>> unnecessary class loading and slows down startup, especially when the code
>> is executed early during an application startup. This is especially a
>> problem for GraalVM, which executes this code during VM startup.
>>
>> This PR reduces the dependencies:
>> - NIO is replaced with regular `java.io` for file access.
>> - Streams are replaced with loops (a side effect of this is that files are
>> read in full whereas previously they could be read up to a certain point,
>> e.g., until a match is found).
>> - Regular expressions are replaced with manual tokenization (and for usages
>> of `String.split`, the "regex" is changed to single characters for which
>> `String.split` has a fast-path implementation that avoids the regular
>> expression engine).
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupInfo.java line 110:
>
>> 108: */
>> 109: static CgroupInfo fromCgroupsLine(String line) {
>> 110: String[] tokens = line.split("\t");
>
> With this change, we now hard-code the expected delimiter and, thus, depend
> on what the kernel does. Do we have sufficient evidence this hasn't
> changed/won't change in the future?
As far as I can tell, the delimiter hasn't changed since the file was
introduced, and judging by the kernel mailing list (e.g., see [the
following](https://lore.kernel.org/all/yr5jvhhsucrbt...@mtj.duckdns.org/)), I
don't think it will change any time soon.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14216#discussion_r1217759178
