RFR [9] 8035897 : FD_SETSIZE should be set on macosx

[Michael McMahon]

On 28/02/14 14:40, Chris Hegarty wrote:
> [ Volker: there are some trivial AIX changes here, maybe you could 
> verify them? ]
>
> JDK-8021820 adds -D_DARWIN_UNLIMITED_SELECT to the build, but the 
> fd_set struct is still limited to 1024.
>
> Snippet from man select(2):
>
>    "Although the provision of getdtablesize(2) was intended to allow 
> user programs to be written
>      independent of the kernel limit on the number of open files, the 
> dimension of a sufficiently
>      large bit field for select remains a problem. The default size 
> FD_SETSIZE (currently 1024) is
>      somewhat smaller than the current kernel limit to the number of 
> open files. However, in order
>      to accommodate programs which might potentially use a larger 
> number of open files with select,
>      it is possible to increase this size within a program by 
> providing a larger definition of
>      FD_SETSIZE before the inclusion of <sys/types.h>.
>
> Either:
>  1) FD_SETSIZE needs to be set to a larger value, but what value, the
>     kernel limit, or other? This is wasteful for most typical apps that
>     don't use large numbers of file descriptors. Or,
>  2) If fd is greater than 1024, then an appropriate amount of memory
>     could be allocated and cast to an fd_set. The FD_SET macro will
>     write past FD_SETSIZE.
>
> I think option 2 is preferable:
>  http://cr.openjdk.java.net/~chegar/8035897/webrev.00/webrev/
>
> I'm still checking to see it an automatic regression test is possible, 
> but I wanted to circulate the changes for comment first.
>
> Thanks,
> -Chris.

I agree option 2 sounds better since adding (say) 4k * sizeof(fd_set) to 
the stack is quite
significant given that it would rarely be required.

On the change itself I noticed one path in bsd_close.c NET_Timeout where 
the malloc'd buffer
is not freed (line 418)

Is it potentially more efficient to use calloc() rather than malloc() + 
memset()?

Maybe a test might need a shell script to call "ulimit -n 4096" or 
something to be able to test it.

Michael