On Thu, 12 May 2022 18:09:40 GMT, Severin Gehwolf <sgehw...@openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more 
>> resilient on some of the stranger systems. Unfortunately, I wasn't able to 
>> re-create a similar system as the reporter. The idea of using the longest 
>> substring match for the cgroupv1 file paths was based on the fact that on 
>> systemd systems processes run in separate scopes and the maven forked test 
>> runner might exhibit this property. For that it makes sense to use the 
>> common ancestor path. Nothing changes in the common cases where the 
>> `cgroup_path` matches `_root` and when the `_root` is `/` (container the 
>> former, host system the latter).
>> In addition, the code paths which are susceptible to throw NPE have been 
>> hardened to catch those situations. Should it happen in the future it makes 
>> more sense (to me) to not have accurate container detection in favor of 
>> continuing to keep running.
>> Finally, with the added unit-tests a bug was uncovered on the "substring" 
>> match case of cgroup paths in hotspot. `p` returned from `strstr` can never 
>> point to `_root` as it's used as the "needle" to find in "haystack" 
>> `cgroup_path` (not the other way round).
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
> Severin Gehwolf has updated the pull request incrementally with one 
> additional commit since the last revision:
>   Use stringStream to simplify controller path assembly

test/hotspot/gtest/runtime/test_os_linux_cgroups.cpp line 63:

> 61:     ASSERT_STREQ(expected_cg_paths[i], ctrl->subsystem_path());
> 62:   }
> 63: }

I found it hard to relate the different paths. Could you create a new struct 
like this?

struct TestCase {
    char* mount_path;
    char* root_paths;
    char* cgroup_path;
    char* expected_cg_paths;
} = {
  {  "/sys/fs/cgroup/memory",     // mount
       "/",                       // root,


PR: https://git.openjdk.java.net/jdk/pull/8629

Reply via email to