RFR: 8286597: Implement PollerProvider on AIX [v9]

[Martin Doerr]

On Fri, 19 May 2023 22:16:22 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

>>> The other implementations allocate a fixed size array at object creation. This imposes an upper limit on the number of fds that can be polled. I made the decision to move this allocation to the poll call and track the size of the poll set. This way, (1) the only limit to the size of the poll set is the system limit on number of open fds (if you can open an fd it can be polled) (2) there is no wasted space to an arbitrarily large array when there are only a few fds polled.
>> 
>> I don't have any experience on AIX but docs page for pollset_poll suggests it populates the array with the file descriptors that have pending events. If I read this correctly, then it's nothing to do with the number of file descriptors registered and it works similarly to /dev/poll, epoll and kqueue. So I think maybe look at this again.
>
> In regards to the speed and fragmentation issues. I think these are compelling reasons to consider the other approach (Option 2 below).
> 
> With respect to memory being returned to the OS: I would expect this issue to be minimal because the memory would 'stick' to the process and just be recycled.
> 
>> If I read this correctly, then it's nothing to do with the number of file descriptors registered
> 
> The implementation as it is written keeps track of the number of fds registered and only allocates memory for that number (0-2 in my testing) when the poll starts. The other implementations allocate space for 512 pollfds at object creation. You are correct that the library only _populates_ the space if there is an event, but space has to be allocated before hand.
> 
> The memory requirements per poller are actually doubled because there is always a reader and writer created.
> 
> ### Option 1: Memory allocated per-poll
> 
> Pros:
> - Memory footprint is minimal ~ `1 * sizeof(struct pollfd)`.
> 
> Cons:
> - Possible performance issues (speed).
> - Possible memory fragmentation issues.
> 
> ### Option 2: Memory allocated on Poller creation
> 
> Pros:
> - No issues with memory fragmentation or allocation performance (since malloc/free calls are minimized).
> 
> Cons:
> - Arbitrary upper limit on number of events per poll.
> - Much larger memory footprint `512 * sizeof(struct pollfd)`
> 
> ---
> 
> Option 2 seems to be the popular choice, and I'm amenable to changing that. It does seems a bit silly to allocate 2 * 512 * 8 bytes == 8 KiB for each Poller when I've only seen 4 * 8 bytes in use.

Are there alternatives like using alloca?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13452#discussion_r1199484076