Hi, may I have a review of this new iteration for this fix?
Thank you! Thomas On Thu, Mar 3, 2016 at 5:26 PM, Thomas Stüfe <thomas.stu...@gmail.com> wrote: > Hi all, > > https://bugs.openjdk.java.net/browse/JDK-8150460 > > thanks to all who took the time to review the first version of this fix! > > This is the new version: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.02/webrev/ > > I reworked the fix, trying to add in all the input I got: This fix uses a > simple one-dimensional array, preallocated at startup, for low-value file > descriptors. Like the code did before. Only for large values of file > descriptors it switches to an overflow table, organized as two dimensional > sparse array of fixed sized slabs, which are allocated on demand. Only the > overflow table is protected by a lock. > > For 99% of all cases we will be using the plain simple fdTable structure > as before. Only for unusually large file descriptor values we will be using > this overflow table. > > Memory footprint is kept low: for small values of RLIMIT_NOFILE, we will > only allocate as much space as we need. Only if file descriptor values get > large, memory is allocated in the overflow table. > > Note that I avoided the proposed double-checked locking solution: I find > it too risky in this place and also unnecessary. When calling getFdEntry(), > we will be executing a blocking IO operation afterwards, flanked by two > mutex locks (in startOp and endOp). So, I do not think the third mutex lock > in getFdEntry will add much, especially since it is only used in case of > larger file descriptor values. > > I also added the fix to bsd_close.c and aix_close.c. I do not like this > code triplication. I briefly played around with unifying this code, but > this is more difficult than it seems: implementations subtly differ between > the three platforms, and solaris implementation is completely different. It > may be a worthwhile cleanup, but that would be a separate issue. > > I did some artificial tests to check how the code does with many and large > file descriptor values, all seemed to work well. I also ran java/net jtreg > tests on Linux and AIX. > > Kind Regards, Thomas > >
