<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Larry,</p>
    <p>Thanks for this note! If I understand correctly, "zz" corresponds
      to the first 10 bits of the encoded UUID attribute of LDAP user
      record, where all bits are set. Such records have UUIDs that start
      with FFFFEEEE-. They are special purpose user accounts, apart from
      `root`, that have their temp directories in zz bucket. <span
        class="HwtZe" lang="en"><span class="jCAhz ChMk0b"><span
            class="ryNqvb">If it's ignored, it will not be possible to
            attach/list JVMs running under special purpose accounts
            (which is theoretically possible).</span></span></span></p>
    <p><span class="pl-en">Thanks,<br>
        Sergey<br>
      </span></p>
    <div class="moz-cite-prefix">Am 18.06.25 um 23:51 schrieb Laurence
      Cable:<br>
    </div>
    <blockquote type="cite"
      cite="mid:9f2b0a55-4a12-4033-8a7c-48129352e330@oracle.com">I
      believe you can ignore bucket "zz" <br>
      <br>
      - Larry <br>
      <br>
      On 6/18/25 2:46 PM, Laurence Cable wrote: <br>
      <blockquote type="cite"> <br>
        <br>
        On 6/18/25 12:44 PM, Sergey Chernyshev wrote: <br>
        <blockquote type="cite">Hi Larry, <br>
          <br>
          Thank you for your comments! Yes, it's probably more like base
          32 / 5 bits per symbol. The function is actually
          __user_local_dirname, it's exported by CoreServices
          (libsystem_coreservices.dylib). One can dlopen()
/System/Library/Frameworks/CoreServices.framework/Versions/Current/CoreServices
          and then lookup the __user_local_dirname (still works in 15.5
          Sequoia). The problem is that the function is undocumented, it
          is not exposed in any platform SDK headers and it is not
          reachable from any documented api except for the confstr(), at
          least what i am aware of. With the introduction of dyld shared
          cache in Big Sur the approach became even less attractive. </blockquote>
        <br>
        Its probably not worth it, I followed a similar (fruitless)
        trail to the same conclusion a couple of years ago ... :( <br>
        <br>
        <blockquote type="cite">I might need to look deeper into it. <br>
          <br>
          Thanks, <br>
          Sergey <br>
          <br>
          <br>
          Am 18.06.25 um 19:23 schrieb Laurence Cable: <br>
          <blockquote type="cite">I believe that somewhere in the bowels
            of MacOS libc there is a (hopefully public) function that
            will map a UID to the UUID used to construct <br>
            the per-user directory path from a base 36(?) encoded string
            thereof, the leading 2 characters of which form the
            "buckets" in /var/folders <br>
            and the remainder of the encoded string forms the per user
            directory with the appropriate bucket... <br>
            <br>
            if might make sense to perform a serious investigation to
            locate this function and then simply make a native call to
            map the target JVM euid <br>
            to the uuid and encode it, from which the actual
            /var/folders/... path can be constructed avoiding a costly
            traversal of the /var/folders <br>
            structure in the search for hsperfdata_user files? <br>
            <br>
            Rgds <br>
            <br>
            - Larry <br>
            <br>
            On 6/18/25 9:40 AM, Sergey Chernyshev wrote: <br>
            <blockquote type="cite">On Tue, 17 Jun 2025 04:51:58 GMT,
              David Holmes <a class="moz-txt-link-rfc2396E"
                href="mailto:dholmes@openjdk.org"><dholmes@openjdk.org></a>
              wrote: <br>
              <br>
              <blockquote type="cite">
                <blockquote type="cite">Sergey Chernyshev has updated
                  the pull request incrementally with two additional
                  commits since the last revision: <br>
                  <br>
                    - Update
                  src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
                  <br>
                          Co-authored-by: Andrey Turbanov <a
                    class="moz-txt-link-rfc2396E"
                    href="mailto:turbanoff@gmail.com"><turbanoff@gmail.com></a>
                  <br>
                    - addressed review comments <br>
                </blockquote>
                src/hotspot/os/posix/perfMemory_posix.cpp line 133: <br>
                <br>
                <blockquote type="cite">131: // <br>
                  132: <br>
                  133: #ifdef __APPLE__ <br>
                </blockquote>
                This is a bit too much non-posix code in the posix file
                IMO. I'd rather see a `MACOS_ONLY` call later on to
                something defined in `os_bsd.cpp` for macOS. <br>
              </blockquote>
              Thanks @dholmes-ora , I moved the function to `os_bsd.cpp`
              <br>
              <br>
              ------------- <br>
              <br>
              PR Review Comment: <a class="moz-txt-link-freetext"
href="https://git.openjdk.org/jdk/pull/25824#discussion_r2155061182">https://git.openjdk.org/jdk/pull/25824#discussion_r2155061182</a>
            </blockquote>
            <br>
          </blockquote>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
  </body>
</html>