<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Philippe!</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thanks for your interest and efforts in modernizing the JDK to use the FFM API to replace older code. As mentioned before, we are running an effort called "Panamization" within the JDK community to push in this direction. </div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Here is an example of a PR that might be helpful when writing such code: <a href="https://github.com/openjdk/jdk/pull/25546" id="LPlnk724303">
https://github.com/openjdk/jdk/pull/25546</a></div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview _EReadonly_1" style="width: 100%; display: inline-block;">
<div id="LPBorder_GTaHR0cHM6Ly9naXRodWIuY29tL29wZW5qZGsvamRrL3B1bGwvMjU1NDY." class="LPBorder701270" style="width: 100%; margin-top: 16px; margin-bottom: 16px; position: relative; max-width: 800px; min-width: 424px;">
<table id="LPContainer701270" role="presentation" style="padding: 12px 36px 12px 12px; width: 100%; border-width: 1px; border-style: solid; border-color: rgb(200, 200, 200); border-radius: 2px;">
<tbody>
<tr valign="top" style="border-spacing: 0px;">
<td>
<div id="LPImageContainer701270" style="position: relative; margin-right: 12px; height: 120px; overflow: hidden; width: 240px;">
<a target="_blank" id="LPImageAnchor701270" href="https://github.com/openjdk/jdk/pull/25546"><img id="LPThumbnailImageId701270" alt="" height="120" style="display: block;" width="240" src="https://opengraph.githubassets.com/072f4c9fd78eedb780c9b704f4f6470ace3a8c466871641aa051ad542f972791/openjdk/jdk/pull/25546"></a></div>
</td>
<td style="width: 100%;">
<div id="LPTitle701270" style="font-size: 21px; font-weight: 300; margin-right: 8px; font-family: wf_segoe-ui_light, "Segoe UI Light", "Segoe WP Light", "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif; margin-bottom: 12px;">
<a target="_blank" id="LPUrlAnchor701270" href="https://github.com/openjdk/jdk/pull/25546" style="text-decoration: none; color: var(--themePrimary);">WIP: Panamize KQueue selector implementation by DarraghClarke · Pull Request #25546 · openjdk/jdk</a></div>
<div id="LPDescription701270" style="font-size: 14px; max-height: 100px; color: rgb(102, 102, 102); font-family: wf_segoe-ui_normal, "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif; margin-bottom: 12px; margin-right: 8px; overflow: hidden;">
This is a draft to hopefully facilitate some discussions and feedback about the panamization of Kqueue This is based on the work that was previously shared in #22307 , The main change since then is...</div>
<div id="LPMetadata701270" style="font-size: 14px; font-weight: 400; color: rgb(166, 166, 166); font-family: wf_segoe-ui_normal, "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif;">
github.com</div>
</td>
</tr>
</tbody>
</table>
</div>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I am willing to help/sponsor your efforts. Maybe we could start with 3. kill, which seems to be a low-hanging fruit. Making this consistent with the above PR would be a good first step.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I will contact you directly via the above email.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Best, Per Minborg</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> core-libs-dev <core-libs-dev-retn@openjdk.org> on behalf of Philippe Marschall <kustos@gmx.net><br>
<b>Sent:</b> Tuesday, June 24, 2025 4:30 PM<br>
<b>To:</b> Magnus Ihse Bursie <magnus.ihse.bursie@oracle.com>; serviceability-dev@openjdk.java.net <serviceability-dev@openjdk.java.net>; core-libs-dev <core-libs-dev@openjdk.org><br>
<b>Subject:</b> Re: Interest in Java based attach provider implementation?</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hello<br>
<br>
Since the audience has been expanded let me summarize what would be <br>
needed to make jdk.attach free of JNI on Unix (AIX, Linux, macOS). <br>
jdk.attach currently uses JNI for four different things.<br>
<br>
1. reading and writing unix domain sockets<br>
2. accessing uid, guid and permissions of a file<br>
3. sending SIGQUIT to an arbitrary PID, including self in the case of <br>
self attach<br>
4. sysctl({CTL_KERN, KERN_PROC, KERN_PROC_PID, pid}) on macOS<br>
<br>
For 1. and 2. there are already supported Java based APIs and I have <br>
patches in case somebody is willing to sponsor this work / open a JIRA.<br>
<br>
3. kill(SIGQUIT)<br>
<br>
This can be done quite easily using FFM as the signature of kill() is <br>
quite simple. The signature and values are the same an Linux and macOS <br>
and I assume AIX as well, but I don't have access to a machine to <br>
verify. Overlap with existing code is with ProcessHandleImpl.destroy0 <br>
which sends SIGKILL or SIGTERM to a PID but performs additional checks. <br>
So an API to send a signal to a PID would be needed. It is my <br>
understanding that jdk.internal.misc.Signal only supports sending signal <br>
to self.<br>
<br>
4. sysctl({CTL_KERN, KERN_PROC, KERN_PROC_PID, pid})<br>
<br>
This is more complicated as the kinfo_proc and extern_proc structs are <br>
quite large. jextract is the easiest way to come up with the <br>
definitions. However the amount of generated code is quite large even <br>
after filtering. The generated code can be further cut down using manual <br>
editing. I have not yet looked into replacing not needed struct fields <br>
with padding. To the best of my knowledge jextract hasn't the been <br>
included into the JDK build.<br>
Overlap here is in ProcessHandleImpl_macosx.c with the functions <br>
os_getParentPidAndTimings and getUID but they access different fields of <br>
extern_proc.<br>
Honestly here I'm not sure why this check is needed at all. The <br>
reasoning given for the check in VirtualMachineImpl.c would in my option <br>
apply to Linux and AIX as well but this check is not performed there. <br>
Removing this check from the macOS implementation would obviously be the <br>
easiest.<br>
<br>
I can't speak for Windows as I'm not familiar enough with Windows APIs.<br>
<br>
Cheers<br>
Philippe<br>
<br>
<br>
On 19.06.25 14:40, Magnus Ihse Bursie wrote:<br>
> Hi Philippe,<br>
> <br>
> There is an ongoing effort about "Panamization" (that is, adapting it to <br>
> use FFM instead of JNI) of native code in the JDK in general. This is <br>
> discussed on the core-libs-dev mailing list. I've cc:ed them. I think it <br>
> would be beneficial if you coordinate your efforts with the Panamization <br>
> effort.<br>
> <br>
> /Magnus<br>
> <br>
> <br>
> On 2025-06-15 17:43, Philippe Marschall wrote:<br>
>> Hello<br>
>><br>
>> I further pursued the approach<br>
>><br>
>> - Rebased the Linux implementation [1], implemented the permission <br>
>> check using JSR 203 and the Unix domain sockets using JEP 380.<br>
>> - Applied the same changes to the AIX implementation [2].<br>
>> - Switched Linux to an FFM based kill implementation [3], completely <br>
>> getting rid of JNI.<br>
>> - Updated the macOS implementation [4], implemented the permission <br>
>> check using JSR 203 and the Unix domain sockets using JEP 380.<br>
>> - Switched macOS to an FFM based kill and sysctl implementation [5], <br>
>> completely getting rid of JNI.<br>
>><br>
>> I ran the serviceability test suite on Linux and macOS and it passes. <br>
>> I manually verified that I can attach to JVMs using local builds.<br>
>><br>
>> I could not test on AIX.<br>
>><br>
>> [1] <a href="https://github.com/marschall/jdk/">https://github.com/marschall/jdk/</a>
<br>
>> commit/3a7796daadad7c9d2d85e9e4623f170baecc0e41<br>
>> [2] <a href="https://github.com/marschall/jdk/">https://github.com/marschall/jdk/</a>
<br>
>> commit/962729e0bfb6b7d86af303f25c6670d407d1d2d9<br>
>> [3] <a href="https://github.com/marschall/jdk/">https://github.com/marschall/jdk/</a>
<br>
>> commit/7b5f1bf6f55458a7f69f50b8fdf4986e22202559<br>
>> [4] <a href="https://github.com/marschall/jdk/">https://github.com/marschall/jdk/</a>
<br>
>> commit/93372a124eca6078fde5597c2498b381a4ef5dfa<br>
>> [5] <a href="https://github.com/marschall/jdk/commit/">https://github.com/marschall/jdk/commit/</a>
<br>
>> c5faf9655bbb85cc3ed9b2a7ef15b08ab83d1d8b<br>
>><br>
>> Cheers<br>
>> Philippe<br>
>><br>
>> On 20.04.22 22:13, Philippe Marschall wrote:<br>
>>> Hello<br>
>>><br>
>>> I hope this is the right mailing list. I recently had a look at the<br>
>>> Linux attach provider implementation and could not help but noticing<br>
>>> that a large part, if not all of it, could be replaced with Java.<br>
>>> Besides getting rid of the C code this should allow us to unify the AIX,<br>
>>> Linux and macOS implementations under a single Unix implementation.<br>
>>><br>
>>> The permission check can be implemented using JSR 203 [1] to access uid,<br>
>>> gid and file mode and using jdk.internal.misc.VM to get the euid and <br>
>>> egid.<br>
>>><br>
>>> Reading and writing to Unix domain sockets can be done through JEP <br>
>>> 380 [2].<br>
>>><br>
>>> Sending SIGQUIT to a process could in theory done through JEP 102 [3]<br>
>>> however sending SIGQUIT to self is currently blocked. This is required<br>
>>> for the self attach mechanism. There a very small C function is still<br>
>>> needed for now, this is hopefully portable.<br>
>>><br>
>>> I did a small prototype [4]. The tier1 suite runs and I can attach to a<br>
>>> local JVM.<br>
>>><br>
>>> The overhead will likely be a bit higher as we go through more JDK<br>
>>> abstractions.<br>
>>><br>
>>> [1] <a href="https://jcp.org/en/jsr/detail?id=203">https://jcp.org/en/jsr/detail?id=203</a><br>
>>> [2] <a href="https://openjdk.java.net/jeps/380">https://openjdk.java.net/jeps/380</a><br>
>>> [3] <a href="https://openjdk.java.net/jeps/102">https://openjdk.java.net/jeps/102</a><br>
>>> [4]<br>
>>> <a href="https://github.com/marschall/jdk/">https://github.com/marschall/jdk/</a>
<br>
>>> commit/207dac7e4d1bd65450bbd2c9e14d33fc34b7cebc<br>
>>><br>
>>> Cheers<br>
>>> Philippe<br>
>><br>
<br>
</div>
</span></font></div>
</body>
</html>