RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all
dmitry.samersoff at oracle.com
Tue Mar 1 10:20:23 UTC 2016
Sorry for being later.
I'm not sure we should take a lock at ll. 131 for each fdTable lookup.
As soon as we never deallocate fdTable[base_index] it's safe to try to
return value first and then take a slow path (take a lock and check
On 2016-02-24 20:30, 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:
> 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
> 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.
> 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
> Thank you and Kind Regards, Thomas
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
More information about the core-libs-dev