I don't have knowledge of the xnu kernel code, nor do I have an easy/quick way to debug/investigate this issue myself. However, a very brief look at the socket code seems to suggest that when a socket fd is closed using "close(fd)", like in that reproducer, the necessary decrement of memory accounting doesn't seem to be happening. Very specifically, it looks like the sodealloc(...) in bsd/kern/uipc_socket.c seems to be responsible to "releasing"/decrementing the memory accounting counter here https://github.com/apple-oss-distributions/xnu/blob/xnu-12377.61.12/bsd/kern/uipc_socket.c#L797. Looking at the soclose_locked(...) function in that same file, it calls sofree(so) here https://github.com/apple-oss-distributions/xnu/blob/xnu-12377.61.12/bsd/kern/uipc_socket.c#L1332. The implementation of sofree(struct socket *so) then calls sofreelastref(so, 0) https://github.com/apple-oss-distributions/xnu/blob/xnu-12377.61.12/bsd/kern/uipc_socket.c#L7315. The second param there is dealloc and is being passed a value of 0 indicating "don't deallocate". So the implementation of sofreelastref(...), then skips the deallocation call to sodealloc(...) https://github.com/apple-oss-distributions/xnu/blob/xnu-12377.61.12/bsd/kern/uipc_socket.c#L1074 - the one which is responsible for decrementing the memory accounting counter. Like I said, I have zero knowledge of this code, so it's possible that I maybe looking at completely unrelated code. If so do let me know (that will help me in future when looking into such issues).

After looking into this more, we have been able to narrow this down to a very trivial C code which is as follows (also attached) Looks like I forgot to attach that file (at least I can't see it attached in this thread) and I can't edit the original post. So attaching it here: sockbufspaceerr.c

Once you’re done, please post your bug number, just for the record. Thank you Quinn, I've now filed FB21686886. And thanks, as always, for your efforts here. Your test suite is certainly doing its bit to keep us honest (-: I'm happy to help :) The OpenJDK testsuite is indeed vast. One of our bigger challenges in recent times has been trying to get a resolution for several stability issues/regressions with BSD socket APIs on macos. I'm glad that these dev forums exist and there are knowledgeable engineers from Apple who regularly respond and provide help. That helps stay motivated to investigate these issues and report them. Feedback assistant tool on the other hand is a bit of a disappointment - lack of any response and visibility on the filed issues there for several months/years even for basic questions makes it a bigger challenge to take such reported issues to a proper resolution. Hopefully that tool/process will see some improvement in future. Thanks again for the help.