RFR: 8302744: Refactor Hotspot container detection code [v3]

[Severin Gehwolf]

On Mon, 27 May 2024 10:08:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
>> 
>>  - Add proper comments for parsing utility functions
>>  - Add a test for a large string read
>>  - Add convenience function for 'max' handling
>>    
>>    This now makes limit_from_str a private method
>>  - Fix general read string cases.
>>  - Get rid of the templated function
>>  - Use enum class for TupleValue
>>  - Merge branch 'master' into jdk-8302744-cleanup-getcontainer-info
>>  - Fix TestMemoryAwareness for cgroup v2
>>    
>>    It only reads the swap value, thus doesn't print:
>>    "Memory and Swap Limit is" but rather prints:
>>    "Swap Limit is". This is fine, since for cg v2
>>    the memory limit and the swap limits are in different
>>    files.
>>  - Fix whitespace
>>  - Handle cpu quota for cgroups v1 specially
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/ffdd6a68...c41d3183
>
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp line 142:
> 
>> 140:      * up to the first new line character ('\n') whichever comes first.
>> 141:      */
>> 142:     bool read_string(const char* filename, char* buf);
> 
> Nice comments.
> 
> I think the common convention is: either specify both output buffer and output buffer size, or - if you always expect a certain output buffer size - specify argument as `char buf[1024]`. Thinking this through, the former may be a bit cleaner since it allows you to scrap all the literal 1024 inside read_string for the bufsize argument.

OK. Went with the former (specifying the buffer size as well as the buffer).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19060#discussion_r1616351612