RFR: 8319589: Attach from root to a user java process not supported in Mac [v2]

[Sergey Chernyshev]

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. 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 <dholmes at 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 <turbanoff at 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
>