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

Laurence Cable larry.cable at oracle.com
Wed Jun 18 21:46:07 UTC 2025



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 <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 
>>



More information about the serviceability-dev mailing list