8374372: Move OSX Serviceability Agent to macosx namespace

[snake66]

The Mac OSX implementation of the Serviceability Agent and related code is quite different from what's needed from the BSD implementation. Still we have tried to keep the coexisting in one codebase in the out-of-tree BSD port, as that's where the OSX code has been living.

This sometimes cause problems when updates to the Mac OSX port breaks the BSD implementation.

As we are working on getting the BSD port into a state for future upstreaming to the mainline repo, this patch clears the path by moving the Mac OSX implementation of the Servicability Agent to a more fitting namespace.

This should allow us to proceed with the BSD implementation undisturbed, but also without risking breaking the OSX port.

This work was sponsored by The FreeBSD Foundation

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8374372: Move OSX Serviceability Agent to macosx namespace (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/29003/head:pull/29003
$ git checkout pull/29003

Update a local copy of the PR:
$ git checkout pull/29003
$ git pull https://git.openjdk.org/jdk.git pull/29003/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 29003

View PR using the GUI difftool:
$ git pr show -t 29003

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/29003.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back haraldei! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@snake66 The following label will be automatically applied to this pull request:

• serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (aca5ff9f)

[dholmes-ora]

I'm not sure about the approach here. My understanding was that "bsd" covered both macOS and potentially other BSD derivatives, while "darwin" provided macOS specific code. You seem to be indicating that the existing "bsd" code only works for macOS and so have renamed it all. If so that is fine (though a little surprising), but then having "macos" and "darwin" as alternatives really makes no sense to me. ??

Also while we have become stuck with using "macosx" in many places in the code, if we can we should use macos/macOS here.

[snake66]

My understanding was that "bsd" covered both macOS and potentially other BSD derivatives, while "darwin" provided macOS specific code.

Yes, traditionally it seems the OS X port was grown from the BSD port, but have since diverged significantly. In the BSD port maintained out of tree, a lot of the code under the bsd directories are essentially split by #ifdef's where the OS X and BSD code are almost entirely separate, and the BSD code is synced with, and more closely resembles the Linux code.

You seem to be indicating that the existing "bsd" code only works for macOS and so have renamed it all.

The BSD code was broken in commit d3083ac, and in trying to figure out how to fix it again it seemed easier to split the two implementations than to try to force them to coexist. This way the platforms would have less risk of breaking each others implementations.

If so that is fine (though a little surprising), but then having "macos" and "darwin" as alternatives really makes no sense to me. ??

I can rename it to darwin instead, if you feel that is better. It seemed like "macosx" was more established when I looked around the source tree, but I'm happy to adapt.

[plummercj]

• The JDK libraries have macosx directories, although within java.base/macosx we also see files with Bsd in the name.
• Hotspot has the os/bsd directory. I assume this is for both bsd and macosx. I don't see a macosx directory under src/hotspot.
• SA has a macosx directory, although it is only for the native libsaproc.
• SA also has a bsd directory, and a number files with bsd in the name, some of which are in the bsd directory and some that are not.
• I don't see any files with "darwin" in the path or name, but maybe it is a more appropriate name in some cases.

My conclusion is that this is all rather poorly thought out and very inconsistent. I don't yet have a suggestion on how to proceed. I just wanted to better describe where things are at now.

[dholmes-ora]

"darwin" seems to be mainly used within the SA code and it seems to be an alias for macOS/macosx - though why it was done that way I'm unsure. May be uname has "darwin" in it and so it is exposed via a system property? (Theoretically you could have a different OS built upon the XNU - aka Darwin - kernel, but we are not trying to support that in any way.

I also see this in java_props_md.c

ifdef MACOSX
    /* darwin has a per-user temp dir */
    static char tmp_path[PATH_MAX];
    int pathSize = confstr(_CS_DARWIN_USER_TEMP_DIR, tmp_path, PATH_MAX);
    if (pathSize > 0 && pathSize <= PATH_MAX) {
        sprops.tmp_dir = tmp_path;
    }
#endif /* MACOSX */

Regardless it makes no sense to have macOS and Darwin supported by SA so some major renaming would also be needed there.

The macosx naming is legacy from the days of the mac port when it was known as OS X. For a long time now it is just macOS but we didn't do a major renaming as that would be too disruptive. But if we are creating new files here then we can use the most appropriate naming scheme and not be caught up in legacy issues.

[dholmes-ora]

The BSD code was broken in commit d3083ac

Okay that is very recent - and very unfortunate. But as we don't know if/when the out-of-tree BSD port will come back into mainline, I would not want to see the existing BSD support effectively gone in JDK 27+. To that end we may need to look at specifically fixing what broke in that commit. Though the BSD specific changes there look innocuous to me.