Port hotspot/os/bsd/os_perf_bsd.cpp to BSD by snake66 · Pull Request #9 · openjdk/bsd-port

snake66 · 2026-05-05T10:48:25Z

Implements CPUPerformanceInterface::CPUPerformance for FreeBSD, OpenBSD and NetBSD. This is essentially a parallel implementation to the macOS implementation in this source file.

This work is sponsored by The FreeBSD Foundation

I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

Progress

Change must not contain extraneous whitespace
Change must be properly reviewed (1 review required, with at least 1 Committer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/bsd-port.git pull/9/head:pull/9
$ git checkout pull/9

Update a local copy of the PR:
$ git checkout pull/9
$ git pull https://git.openjdk.org/bsd-port.git pull/9/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 9

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/bsd-port/pull/9.diff

Using Webrev

Link to Webrev Comment

Implements CPUPerformanceInterface::CPUPerformance for FreeBSD, OpenBSD and NetBSD. This is essentially a parallel implementation to the macOS implementation in this source file. This work is sponsored by The FreeBSD Foundation Co-authored-by: Kurt Miller <kurt@openjdk.org> Co-authored-by: Greg Lewis <glewis@openjdk.org>

bridgekeeper · 2026-05-05T10:49:04Z

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

openjdk · 2026-05-05T10:49:42Z

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

mlbridge · 2026-05-05T10:57:54Z

Webrevs

dean-long · 2026-05-07T21:36:41Z

Is it really necessary to have a full parallel implementation? I would expect a large part to be sharable between bsd variants.

snake66 · 2026-05-08T11:15:04Z

@dean-long I don't see much overlap between the macOS and *BSD implementations. The macOS code seems to be targeted for the Mach kernel, which is not used by any of the others. To be fair, there's enough differences even among the traditional *BSD's that this code will be quite hairy regardless of how we approach it.

dholmes-ora

This is certainly complex with all the conditionals. I can't help wonder if we wouldn't better off splitting some things out into separate per-BSD files.

dholmes-ora · 2026-05-29T02:21:09Z

+  #define NET_RT_IFLIST2 NET_RT_IFLIST
+  #define RTM_IFINFO2    RTM_IFINFO
+#endif
+#ifdef __NetBSD__


Why a simple ifdef here but a if !defined above? Can we use one style please.

Probably to align with the #ifdef __APPLE__ above, but I've cleaned up this section in the new version of the patch so it's hopefully better now.

dholmes-ora · 2026-05-29T02:26:49Z

+#if !defined(KERN_PROC_PATHNAME)
+#define KERN_PROC_PATHNAME 5
 #endif


Can this be handled where we do the #include?

Ack, moved it up in the new version of the patch.

dholmes-ora · 2026-05-29T02:31:31Z

-static const double NANOS_PER_SEC = 1000000000.0;
+static const time_t NANOS_PER_SEC = 1000000000LL;


I don't understand this change when most use-sites cast back to double anyway - and the one that doesn't should have been casting to an integral type in the first place.

It's used once as each, but I agree, there's no reason to change this. I've reverted this and added the cast to uint64_t where it's being used as such.

- Clean up #include section - Revert NANOS_PER_SEC back to a double - Move NetBSD def of KERN_PROC_PATHNAME to #include section This work is sponsored by The FreeBSD Foundation

snake66 · 2026-05-29T13:51:12Z

This is certainly complex with all the conditionals. I can't help wonder if we wouldn't better off splitting some things out into separate per-BSD files.

I would actually really like it if we could split this up instead. We have just tried to adapt to the structure that was already there, but if it's ok with you I'll be happy to work out a suggestion for a patch where we split it up instead.

If it's ok, I would also like to split the different interface implementations (CPUPerformance, SystemProcess and NetworkPerformance) into separate source files as well. Will be many files then :)

dholmes-ora · 2026-05-30T20:46:08Z

Will be many files then :)

Lets try to not to go overboard with too fine-grained an approach. We also need to allow sharing where possible.

Just in terms of the bigger picture, I am a bit concerned about all the different kinds of BSD being supported here. From a "supported port" perspective there needs to be a maintainer willing to take on all aspects of this.

snake66 · 2026-06-01T08:14:34Z

Lets try to not to go overboard with too fine-grained an approach. We also need to allow sharing where possible.

That makes sense. I'll try to split the BSD and macOS implementations, and then we can see from there.

Just in terms of the bigger picture, I am a bit concerned about all the different kinds of BSD being supported here. From a "supported port" perspective there needs to be a maintainer willing to take on all aspects of this.

I'm aware. As my work is supported by the FreeBSD Foundation, I can only commit to support for FreeBSD. @bsdkurt and @battleblow may be able to say more about OpenBSD and NetBSD.

bsdkurt · 2026-06-01T12:02:43Z

Just in terms of the bigger picture, I am a bit concerned about all the different kinds of BSD being supported here. From a "supported port" perspective there needs to be a maintainer willing to take on all aspects of this.

I'm aware. As my work is supported by the FreeBSD Foundation, I can only commit to support for FreeBSD. @bsdkurt and @battleblow may be able to say more about OpenBSD and NetBSD.

I'm happy to continue to maintain OpenBSD's portion of the bsd-port. I've been doing that for around 25 years now on a volunteer basis (except for some consulting work I did for the FreeBSD foundation's prior work at certification). NetBSD has not had a consistent developer engaged with the project over those years, but we've (Greg and myself) always tried to maintain support for it along the way.

mlbridge · 2026-06-01T16:21:21Z

Mailing list message from Christos Zoulas on bsd-port-dev:

On Jun 1, 2026, at 8:05 AM, Kurt Miller <kurt@openjdk.org> wrote:

On Mon, 1 Jun 2026 08:14:34 GMT, Harald Eilertsen <haraldei@openjdk.org> wrote:

Just in terms of the bigger picture, I am a bit concerned about all the different kinds of BSD being supported here. From a "supported port" perspective there needs to be a maintainer willing to take on all aspects of this.

I'm aware. As my work is supported by the FreeBSD Foundation, I can only commit to support for FreeBSD. @bsdkurt and @battleblow may be able to say more about OpenBSD and NetBSD.

I'm happy to continue to maintain OpenBSD's portion of the bsd-port. I've been doing that for around 25 years now on a volunteer basis (except for some consulting work I did for the FreeBSD foundation's prior work at certification). NetBSD has not had a consistent developer engaged with the project over those years, but we've (Greg and myself) always tried to maintain support for it along the way.

Thanks Kurt, I am around and I can try to help if needed for NetBSD.

christos

mlbridge · 2026-06-01T16:21:24Z

Mailing list message from Stephanie Bergmann on bsd-port-dev:

OptOut!

Stephanie Bergmann

Christos Zoulas <christos@zoulas.com> schrieb am Mo., 1. Juni 2026, 15:37:

On Jun 1, 2026, at 8:05 AM, Kurt Miller <kurt@openjdk.org> wrote:

On Mon, 1 Jun 2026 08:14:34 GMT, Harald Eilertsen <haraldei@openjdk.org>
wrote:

Just in terms of the bigger picture, I am a bit concerned about all
the different kinds of BSD being supported here. From a "supported port"
perspective there needs to be a maintainer willing to take on all aspects
of this.

I'm aware. As my work is supported by the FreeBSD Foundation, I can
only commit to support for FreeBSD. @bsdkurt and @battleblow may be able to
say more about OpenBSD and NetBSD.

I'm happy to continue to maintain OpenBSD's portion of the bsd-port.
I've been doing that for around 25 years now on a volunteer basis (except
for some consulting work I did for the FreeBSD foundation's prior work at
certification). NetBSD has not had a consistent developer engaged with the
project over those years, but we've (Greg and myself) always tried to
maintain support for it along the way.

Thanks Kurt, I am around and I can try to help if needed for NetBSD.

christos

bridgekeeper · 2026-06-29T23:14:04Z

@snake66 This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

Split implementation into separate source files for macOS and BSD where necessary, and consolidate the code that's common between them into a common source. - Split CPUPerformanceInterface impl for BSD and macOS, but keep the common PIMPL wrapper class. - Move SystemProcessInterface::SystemProcess to common code, implement functions to imitate relevant macOS proc.h function for the BSD's. - Drop retreiving process args for FreeBSD and NetBSD for now, this was not implemented for macOS or OpenBSD in any case. Can add it back later if it has value. - Move NetworkPerformanceInterface::NetworkPerformance to common code. Only minor adjustments via conditional sections between macOS and BSD implementation. This work is sponsored by The FreeBSD Foundation Co-authored-by: Kurt Miller <bsdkurt@gmail.com> Co-authored-by: Greg Lewis <glewis@eyesbeyond.com>

bridgekeeper · 2026-08-07T16:59:20Z

@snake66 This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

openjdk Bot added the rfr Pull request is ready for review label May 5, 2026

dholmes-ora reviewed May 29, 2026

View reviewed changes

Address review comments

c86680f

- Clean up #include section - Revert NANOS_PER_SEC back to a double - Move NetBSD def of KERN_PROC_PATHNAME to #include section This work is sponsored by The FreeBSD Foundation

		static const double NANOS_PER_SEC = 1000000000.0;
		static const time_t NANOS_PER_SEC = 1000000000LL;

Uh oh!

Conversation

snake66 commented May 5, 2026 • edited by openjdk Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Reviewing

Uh oh!

bridgekeeper Bot commented May 5, 2026

Uh oh!

openjdk Bot commented May 5, 2026

Uh oh!

mlbridge Bot commented May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

dean-long commented May 7, 2026

Uh oh!

snake66 commented May 8, 2026

Uh oh!

dholmes-ora left a comment

Choose a reason for hiding this comment

Uh oh!

dholmes-ora May 29, 2026

Choose a reason for hiding this comment

Uh oh!

snake66 May 29, 2026

Choose a reason for hiding this comment

Uh oh!

dholmes-ora May 29, 2026

Choose a reason for hiding this comment

Uh oh!

snake66 May 29, 2026

Choose a reason for hiding this comment

Uh oh!

dholmes-ora May 29, 2026

Choose a reason for hiding this comment

Uh oh!

snake66 May 29, 2026

Choose a reason for hiding this comment

Uh oh!

snake66 commented May 29, 2026

Uh oh!

dholmes-ora commented May 30, 2026

Uh oh!

snake66 commented Jun 1, 2026

Uh oh!

bsdkurt commented Jun 1, 2026

Uh oh!

mlbridge Bot commented Jun 1, 2026

Uh oh!

mlbridge Bot commented Jun 1, 2026

Uh oh!

bridgekeeper Bot commented Jun 29, 2026

Uh oh!

bridgekeeper Bot commented Aug 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants

snake66 commented May 5, 2026 •

edited by openjdk Bot

Loading

mlbridge Bot commented May 5, 2026 •

edited

Loading