On 6/18/25 12:44 PM, Sergey Chernyshev wrote:
Hi Larry,
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.
Its probably not worth it, I followed a similar (fruitless) trail to the
same conclusion a couple of years ago ... :(
I might need to look deeper into it.
Thanks,
Sergey
Am 18.06.25 um 19:23 schrieb Laurence Cable:
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
the per-user directory path from a base 36(?) encoded string thereof,
the leading 2 characters of which form the "buckets" in /var/folders
and the remainder of the encoded string forms the per user directory
with the appropriate bucket...
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
to the uuid and encode it, from which the actual /var/folders/...
path can be constructed avoiding a costly traversal of the /var/folders
structure in the search for hsperfdata_user files?
Rgds
- Larry
On 6/18/25 9:40 AM, Sergey Chernyshev wrote:
On Tue, 17 Jun 2025 04:51:58 GMT, David Holmes <dhol...@openjdk.org>
wrote:
Sergey Chernyshev has updated the pull request incrementally with
two additional commits since the last revision:
- Update
src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
Co-authored-by: Andrey Turbanov <turban...@gmail.com>
- addressed review comments
src/hotspot/os/posix/perfMemory_posix.cpp line 133:
131: //
132:
133: #ifdef __APPLE__
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.
Thanks @dholmes-ora , I moved the function to `os_bsd.cpp`
-------------
PR Review Comment:
https://git.openjdk.org/jdk/pull/25824#discussion_r2155061182
