In the checker, check that the pager does not contain pages.

In D53891#1231852, @markj wrote:

In D53891#1231400, @kib wrote:

In D53891#1231399, @alc wrote:

Can you elaborate on what you saw when debugging this problem? In particular, whether the map entries had OBJ_ONEMAPPING set? In principle, the ref_count and size shouldn't be a concern if the object has OBJ_ONEMAPPING set. For example, suppose there is an anonymous mapping (with OBJ_ONEMAPPING set) for the range [A, D). Further, suppose we punch a hole in the middle of that mapping, by calling munmap() on the range [B, C) where A < B < C < D. Now, we have two mappings, [A, B) and [C, D), that both reference the original object, and that object should still have OBJ_ONEMAPPING set. Because OBJ_ONEMAPPING is set, the munmap() should have freed any physical pages and swap space from the object that fell within the range [B, C). So, if a new anonymous mapping is created starting at either B or D, we should be able to safely coalesce it.

I did not have access to the object state there (all debugging was done remotely).

The situation you described is one of the cases that concerned me. I am not sure that we have a guarantee that doing the coalesce on the object with OBJ_ONEMAPPING flag but ref_count > 1 would not corrupt some other mapping. We need to do vm_object_page_remove(), and in principle that could remove pages which belong to other fragment.

I believe OBJ_ONEMAPPING means, "each page in the object is mapped at most once", so in the case you describe, OBJ_ONEMAPPING should not be set to begin with.

Now also required for ports-mgmt/packagekits tests.

None of the libraries listed as required here are bundled, so it has done the right thing and the bootstrap now do not provide lib anymore so it will never be proposed instead of a regular openjdk

pkg_cleanup_shlibs_required(pkg, &internal_provided);

Seems it is supposed to just work, hm.

@bapt I'm not sure this did what I expected.
It added the annotation but it still marked all of the libs as required.

# pkg info -F bootstrap-openjdk17-17.0.1.12.1_2.pkg
bootstrap-openjdk17-17.0.1.12.1_2
Name           : bootstrap-openjdk17
Version        : 17.0.1.12.1_2
Origin         : java/bootstrap-openjdk17
Architecture   : FreeBSD:14:amd64
Prefix         : /usr/local
Categories     : devel java
Licenses       : GPLv2
Maintainer     : java@FreeBSD.org
WWW            : https://openjdk.java.net/
Comment        : Java Development Kit 17
Shared Libs required:
        libX11.so.6
        libXext.so.6
        libXi.so.6
        libXrender.so.1
        libXtst.so.6
        libasound.so.2
        libc++.so.1
        libc.so.7
        libcxxrt.so.1
        libdl.so.1
        libfontconfig.so.1
        libfreetype.so.6
        libgcc_s.so.1
        libgif.so.7
        libharfbuzz.so.0
        libjpeg.so.8
        liblcms2.so.2
        libm.so.5
        libpng16.so.16
        libthr.so.3
        libutil.so.9
        libz.so.6
Annotations    :
        FreeBSD_version: 1400097
        build_timestamp: 2025-11-13T00:01:02+00:00
        built_by       : poudriere-git-3.3.0-2420-g3a7024568
        no_provide_shlib: yes
        port_checkout_unclean: no
        ports_top_checkout_unclean: yes
        ports_top_git_hash: a5581322a5c3da107f83705f91c9900b8c219ae3
Flat size      : 252MiB
Description    :
OpenJDK is an open-source implementation of the Java Platform, Standard Edition.

In D53891#1231400, @kib wrote:

In D53891#1231399, @alc wrote:

Can you elaborate on what you saw when debugging this problem? In particular, whether the map entries had OBJ_ONEMAPPING set? In principle, the ref_count and size shouldn't be a concern if the object has OBJ_ONEMAPPING set. For example, suppose there is an anonymous mapping (with OBJ_ONEMAPPING set) for the range [A, D). Further, suppose we punch a hole in the middle of that mapping, by calling munmap() on the range [B, C) where A < B < C < D. Now, we have two mappings, [A, B) and [C, D), that both reference the original object, and that object should still have OBJ_ONEMAPPING set. Because OBJ_ONEMAPPING is set, the munmap() should have freed any physical pages and swap space from the object that fell within the range [B, C). So, if a new anonymous mapping is created starting at either B or D, we should be able to safely coalesce it.

I did not have access to the object state there (all debugging was done remotely).

The situation you described is one of the cases that concerned me. I am not sure that we have a guarantee that doing the coalesce on the object with OBJ_ONEMAPPING flag but ref_count > 1 would not corrupt some other mapping. We need to do vm_object_page_remove(), and in principle that could remove pages which belong to other fragment.

Removing unecessary comment lines