Thomas, 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 fdTable[base_index] again) -Dmitry 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: > 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. > > 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. > > Thank you and Kind Regards, Thomas > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
