RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Roger Riggs Roger.Riggs at Oracle.com
Wed Feb 24 19:28:01 UTC 2016


Hi Thomas,

On 2/24/2016 12:30 PM, Thomas Stüfe wrote:
> Hi all,
>
> please take a look at this proposed fix.
>
> The bug: https://bugs.openjdk.java.net/browse/JDK-8150460
> The Webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.00/webrev/
>
> Basically, the file descriptor table implemented in linux_close.c may not
> work for RLIMIT_NO_FILE=infinite or may grow very large (I saw a 50MB
> table) for high values for RLIMIT_NO_FILE. Please see details in the bug
> description.
>
> The proposed solution is to implement the file descriptor table not as
> plain array, but as a twodimensional sparse array, which grows on demand.
> This keeps the memory footprint small and fixes the corner cases described
> in the bug description.
>
> Please note that the implemented solution is kept simple, at the cost of
> somewhat higher (some kb) memory footprint for low values of RLIMIT_NO_FILE.
> This can be optimized, if we even think it is worth the trouble.
>
> Please also note that the proposed implementation now uses a mutex lock for
> every call to getFdEntry() - I do not think this matters, as this is all in
> preparation for an IO system call, which are usually way more expensive
> than a pthread mutex. But again, this could be optimized.
I would suggest preallocating the index[0] array and then skip the mutex 
for that case.
That would give the same as current performance.

And I'd suggest a different hi/low split of the indexes to reduce the 
size of pre-allocated memory.
Most processes are going to use a lot fewer than 16384 fd's.  How about 
2048?
I have my doubts about needing to cover fd's  up to the full range of 32 
bits.
Can the RLIMIT_NO_FILE be used too parametrize the allocation of the 
first level table?

Not specific to your change but it would nice to see consistency between 
libnio and libnet on
the name of the sigWakeup/INTERRUPT_SIGNAL constant.
>
> This is an implementation proposal for Linux; the same code found its way
> to BSD and AIX. Should you approve of this fix, I will modify those files
> too.
yes please.

$.02, Roger

>
> Thank you and Kind Regards, Thomas




More information about the core-libs-dev mailing list