[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:51:35 UTC 2025


I believe you can ignore bucket "zz"

- Larry

On 6/18/25 2:46 PM, Laurence Cable wrote:
>
>
> 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