RFR: 8324683: Unify AttachListener code for Posix platforms
Thomas Stuefe
stuefe at openjdk.org
Thu Mar 21 17:50:21 UTC 2024
On Wed, 13 Mar 2024 17:50:05 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:
> Hi folks,
>
> This PR aims to unify a lot of the shared code between ```attachListener_linux.cpp``` and ```attachListener_bsd.cpp```.
>
> Some key points:
>
> 1. AIX:
>
> ```attachListener_aix.cpp``` has some key differences from linux/bsd, so I have reduced the scope of the issue to linux and bsd only. As a result, there's an ifndef AIX statement wrapping the whole file. Unifying AIX could be a separate issue.
>
> 2. Peer credentials:
>
> In ```AttachListener::dequeue```, bsd and linux use different APIs to obtain peer credentials. Linux uses ```getsockopt```, while bsd uses ```getpeerid```.
>
> Bsd doesn't have [SO_PEERCRED ](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/getsockopt.2.html). While Linux has ```getpeerid``` implemented on top of ```getsockopt```, it comes in the [bsd compat lib](https://cgit.freedesktop.org/libbsd/tree/src/getpeereid.c).
>
> To avoid adding further dependencies, I have kept both API calls separated by an ifdef macro.
>
> Additionally, there are some slight differences in the logging messages in this area for bsd and linux. It's possible to coalesce them should this make more sense.
>
> 3. ```AttachListener::is_init_trigger()```
>
> Please refer to [mailing list discussion](https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2024-March/068413.html) for details.
>
> Per the discussion, I tried removing the check for ".attach_pid" in the current working directory (more closely resembling what the bsd code does). However, I noted this caused many failure across linux hotspot tests. See GHA job with failures [here](https://github.com/SoniaZaldana/jdk/actions/runs/8349574000).
>
> Therefore, I opted for the Linux approach in this PR. This means we do the check in the current working directory across bsd and linux, although this has been removed from bsd before. This seemingly doesn't break any bsd tests.
>
> 5. Minimal JVM Variant:
>
> I came across an error in the minimal JVM build:
> ` error: invalid use of incomplete type ‘class AttachOperation’
> 80 | class PosixAttachOperation : public AttachOperation {`
>
> After a bit of digging, I found that we only get complete definition of AttachOperation inside the directive ```#IF INCLUDE_SERVICES``` [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/services/attachListener.hpp#L138 ).
>
> I added the same directive for the ```attachListener_posix.cpp``` file but I’m not entirely sure why this wasn't an issue before. The JVM minimal build compiles now...
Hi Sonia,
good job. This is a nice simplification. I hate a quick glance at the latest version. Remarks inline.
> Hi folks,
>
> This PR aims to unify a lot of the shared code between `attachListener_linux.cpp` and `attachListener_bsd.cpp`.
>
> Some key points:
>
> 1. AIX:
>
> `attachListener_aix.cpp` has some key differences from linux/bsd, so I have reduced the scope of the issue to linux and bsd only. As a result, there's an ifndef AIX statement wrapping the whole file. Unifying AIX could be a separate issue.
>
I think that is fine.
Answering @ptribble:
I think `#ifndef AIX` is semantically more correct than `#if defined(BSD) || defined(LINUX)`, since this should be the default implementation used by anyone apart from AIX. A hypothetical new port should be POSIX compliant, hopefully, and use this default implementation. Or do you see any problems with this code not working on Solaris?
...
> 5. Minimal JVM Variant:
>
> I came across an error in the minimal JVM build: ` error: invalid use of incomplete type ‘class AttachOperation’ 80 | class PosixAttachOperation : public AttachOperation {`
>
> After a bit of digging, I found that we only get complete definition of AttachOperation inside the directive `#IF INCLUDE_SERVICES` [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/services/attachListener.hpp#L138).
>
> I added the same directive for the `attachListener_posix.cpp` file but I’m not entirely sure why this wasn't an issue before. The JVM minimal build compiles now, but I'd appreciate any feedback on this change.
Adding the define feels wrong to me. The logic should be like this: We define INCLUDE_xxxx for features depending on the set of features we build in. If INCLUDE_xxx is missing, code should still build, but with the corresponding features disabled.
Look at utilities/macros.hpp, and how the various INCLUDE_xxx macros are used. The solution is probably to conditionally compile the attach listener code with `#if INCLUDE_SERVICES`
Cheers, Thomas
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18283#issuecomment-2013162650
More information about the hotspot-runtime-dev
mailing list