[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