From magnus.ihse.bursie at oracle.com Tue Sep 23 14:39:05 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 23 Sep 2025 16:39:05 +0200 Subject: bsd-port repo organization In-Reply-To: References: Message-ID: I would recommend, given the circumstances, that you create two new branches on that repo, named e.g. bsd-port and battleblow. The master branch should not be touched -- it should just be left alone to automatically keep in sync with master on mainline. The core idea -- and this is a method shared by other projects -- is to integrate multiple PRs into the "bsd-port" branch. That way, each individual PR would be small and easy to review. If all individual PRs going into "bsd-port" has been reviewed by reviewers X, Y, Z then these persons will feel fairly confident that when the bsd-port will be integrated into mainline -- as a single PR targeting the master branch in the jdk repo -- that the code in that PR will be okay, since it just consists of individually checked pieces, and can easily vouch for this by giving their review. So what about the battleblow branch? Well, as you say, the port exists but have lived out-of-tree for a long time, so somehow you will have to balance the needs of clean PRs for the bsd-port branch with the real-world proven code from the battleblow repo. My suggestion is that you create this special branch where you start by integrating individual patches from the battleblow repo. Then, as you go along and integrate PRs into bsd-port, you will slowly make bsd-port look more alike battleblow. If it turns out that the PR into bsd-port needs to solve a problem differently than in battleblow, my suggestion is that you push an "adaptation PR" into battleblow, to change that patch into whatever was pushed into bsd-port. That way, you have a clear definition of done: Once the battleblow and bsd-port branches look identical, you're done. (Unless you find issues that is not fixed in battleblow etc). And the bsd-port will consists of a series of reviewed PRs, which means that this is the best possible situation for creating a PR for mainline. And the master branch in the bsd-repo? Well, from time to time, I recommend you merge it into bsd-port and battleblow, to not have them diverge too much from mainline. If you do that once a day or once a month, I don't know. It depends on how fast you plan to move or how likely it is that your changes will conflict with upcoming mainline changes, and if you want to take the pain upfront or delay it until the end. But you should never push anything into the master branch itself. You will need to write a JEP before integrating into mainline, but this strategy gives you a lot of time to work on that. You can still start straight away with pushing PRs into the bsd-port. /Magnus On 2025-08-27 12:01, Harald Eilertsen wrote: > Hi, > > As we now have a bsd-port repo under the OpenJDK organization on Github, > I thought it would be a good time to discuss further progress on the BSD > port, and how to organize how we work and use the repo. > > https://github.com/openjdk/bsd-port > > The repo is set up so that the master branch automatically track the > openjdk/jdk repo master branch, and from what I gather, the normal > openjdk workflow for integrating merge requests into the master branch > apply. I.e. merge requests in the bsd-repo will be integrated into the > mainline jdk branch. > > https://openjdk.org/guide/#contributing-to-an-openjdk-project > > As the BSD ports have lived for such a long time as out-of-tree ports, > integrating the old patches as they were originally committed to the > battleblow repos is not really feasible. Also trying to integrate the > full port as one huge merge request will probably (and understandably) > be rejected. > > In other words we need to find a way to break the current set of patches > down to sensible changes that we can get integrated with relative ease. > > I've been adviced that we should also author a JEP that covers the > integration of the BSD port into mainline. This will make it easier to > get our changes accepted, and also help the upstream project to plan for > the changes. > > https://openjdk.org/jeps/0 > > I'm not sure how important the JEP is if we add changes gradually, but > I'm thinking it won't hurt. > > Finally I think we should update the bsd-port wiki, but I don't seem > to have edit rights for that yet. > > https://wiki.openjdk.org/display/BSDPort/Main > > I'd really like to get your feedback and thoughts on this. > > Take Care! > Harald From stephaniebergmann29 at gmail.com Sun Sep 28 16:00:50 2025 From: stephaniebergmann29 at gmail.com (Stephanie Bergmann) Date: Sun, 28 Sep 2025 18:00:50 +0200 Subject: Support for -XX:AllocateHeapAt on ZFS? In-Reply-To: References: Message-ID: OPT OUT Am Mo., 30. Juni 2025 um 16:19 Uhr schrieb Harald Eilertsen : > > Hi everyone, > > I tried asking this on the freebsd-java list too, but did not get a > response, so trying here instead: > > The code backing the `-XX:AllocateHeapAt=path` option to java calls the > function posix_fallocate on most systems to reserve the space for the > file in the file system. This will fail and return `EINVAL` if the > underlying file system does not support the operation. > > On FreeBSD this is particularly relevant because the commonly used ZFS > file system does not support this operation. > > For rationale see: > https://freebsd-current.freebsd.narkive.com/5pbDPeIT/heads-up-posix-fallocate-support-removed-from-zfs-lld-affected > https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068447.html > > On OpenBSD the ftruncate function is used instead, and MacOSX will > attempt to set the size via fcntl, but falls back to ftruncate if that > does not work. > > To make things even more interesting, the glibc implementation of > posix_fallocate used on most Linux based systems deviates from the posix > standard by 'emulating' the feature if not supported by the underlying > file system. > https://www.man7.org/linux/man-pages/man3/posix_fallocate.3.html#CAVEATS > > My question is: Do we want to keep the strict posix compliance on > FreeBSD, which in practice means this feature is not supported on ZFS, > or do we want to be less strict like the other platforms mentioned > above? > > Also, if someone can comment on the rationale for OpenBSD > implementation, that would also be helpful. > > Thanks in advance, > Harald Eilertsen