November 2021 - core-libs-dev

RFR: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException
by Joe Darcy 17 Feb '22

17 Feb '22

Make explicit illegal argument cases of Class.arrayType. Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8268300 ------------- Commit messages: - Add test file. - Merge branch 'master' into 8268250 - 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException Changes: https://git.openjdk.java.net/jdk/pull/4382/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4382&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268250 Stats: 55 lines in 2 files changed: 55 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4382.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4382/head:pull/4382 PR: https://git.openjdk.java.net/jdk/pull/4382

5 13

RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
by kabutz 11 Feb '22

11 Feb '22

BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel. The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number. We have also parallelized the private square() method. Internally, the square() method defaults to be sequential. Some benchmark results, run on my 1-6-2 server: Benchmark (n) Mode Cnt Score Error Units BigIntegerParallelMultiply.multiply 1000000 ss 4 51.707 ± 11.194 ms/op BigIntegerParallelMultiply.multiply 10000000 ss 4 988.302 ± 235.977 ms/op BigIntegerParallelMultiply.multiply 100000000 ss 4 24662.063 ± 1123.329 ms/op BigIntegerParallelMultiply.parallelMultiply 1000000 ss 4 49.337 ± 26.611 ms/op BigIntegerParallelMultiply.parallelMultiply 10000000 ss 4 527.560 ± 268.903 ms/op BigIntegerParallelMultiply.parallelMultiply 100000000 ss 4 9076.551 ± 1899.444 ms/op We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine. ------------- Commit messages: - Added parallelMultiply() method to BigInteger to allow large multiplications to run in parallel Changes: https://git.openjdk.java.net/jdk/pull/6409/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6409&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277175 Stats: 269 lines in 3 files changed: 236 ins; 6 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/6409.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6409/head:pull/6409 PR: https://git.openjdk.java.net/jdk/pull/6409

12 81

Seeking inputs on 8224794: ZipFile/JarFile should open zip/JAR file with FILE_SHARE_DELETE sharing mode on Windows
by Jaikiran Pai 10 Feb '22

10 Feb '22

I have been experimenting with https://bugs.openjdk.java.net/browse/JDK-8224794 and have reached a stage with my changes where I would like some inputs before I move ahead or raise a PR for review. As noted in that JBS issue, the idea is to open the underlying file using FILE_SHARE_DELETE when using java.uitl.zip.ZipFile and java.util.jar.JarFile. From what I can infer from that JBS issue, the motivation behind this seems to be to allow deleting that underlying file when that file is currently opened and in use by the ZipFile/JarFile instance. The linked github issues seem to suggest the same. IMO, it's a reasonable expectation, given that such a deletion works on *nix platform. It's on Windows where such a deletion fails with "The process cannot access the file because it is being used by another process" (the other process in many cases will be the current JVM instance itself). So trying to get this to work on Windows by setting the FILE_SHARE_DELETE share access mode seems reasonable. Coming to the implementation part, I've an initial draft version here https://github.com/openjdk/jdk/pull/6477. It sets the FILE_SHARE_DELETE share access mode on the file when constructed by ZipFile/JarFile. It "works", in the sense that if you issue a delete against this underlying file (path) after its been opened by ZipFile/JarFile instance, you no longer see the error mentioned above and the delete completes without any exception. However, my experiments with this change have raised a bunch of questions related to this: The crucial part of the "DeleteFile" API in Windows is that, as stated in its documentation[1]: "The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED." So imagine the following pseudo-code: String path = "C:/foo.jar" 1. JarFile jar = new JarFile(path); // create a jar instance 2. var deleted = new File(path).delete(); // delete the underlying file 3. var exists = new File(path).exists(); // check file existence 4. FileOutputStream fos = new FileOutputStream(new File(path)); // open a FileOutputStream for /tmp/foo.jar 5. java.nio.file.Files.deleteIfExists(Path.of(path)); When this is run (on Windows) *without* the change that introduces FILE_SHARE_DELETE, I notice that line#2 returns "false" for File.delete() (since the file is in use by the JarFile instance) and then line#3 returns "true" since it still exists and line#4 succeeds and creates a new FileOutputStream and line#5 fails with an exception stating "java.nio.file.FileSystemException: foo.jar: The process cannot access the file because it is being used by another process " Now when the same code is run (on Windows) *with* the proposed FILE_SHARE_DELETE changes, I notice that line#2 returns "true" (i.e. the file is considered deleted) and line#3 returns "true" (i.e. it's considered the file still exists). So essentially the file is only marked for deletion and hasn't been deleted at the OS level, since the JarFile instance still has an handle open. Then line#4 unlike previously, now throws an exception and fails to create the FileOutputStream instance. The failure says "java.nio.file.AccessDeniedException: foo.jar". This exception matches the documentation from that Windows DeleteFile API. line#5 too fails with this same AccessDeniedException. So what this means is, although we have managed to allow the deletion to happen (i.e. the first call to delete does mark it for deletion at OS level), IMO, it still doesn't improve much and raises other difference in behaviour of APIs as seen above, unless the underlying file handle held by ZipFile/JarFile is closed. So that brings me to the next related issue. For this change to be really useful, the file handle (which is an instance of RandomAccessFile) held by ZipFile/JarFile needs to be closed. If a user application explicitly creates an instance of ZipFile/JarFile, it is expected that they close it themselves. However, the most prominent use of the JarFile creation is within the JDK code where it uses the sun.net.www.protocol.jar.JarURLConnection to construct the JarFile instances, typically from the URLClassLoader. By default these JarFile instances that are created by the sun.net.www.protocol.jar.JarURLConnection are cached and the close() on those instances is called only when the URLClassLoader is close()ed. That in itself doesn't guarantee that the underlying file descriptor corresponding to the JarFile instance gets closed, because there's one more level of reference counting "cache" in use in java.util.zip.ZipFile$Source class where the same underlying file descriptor (corresponding to the jar file) gets used by multiple JarFile instances (irrespective of who created those). So in short, the underlying file descriptor of a JarFile only gets closed when every single instance of a JarFile pointing to the same jar file has been close()ed within the JVM. Which effectively means that introducing the FILE_SHARE_DELETE semantics/changes for Windows will only allow the first delete() attempt to succeed (since that one marks it for deletion), but any subsequent operations like the one noted in the examples, that rely on that file being deleted will continue to fail with Access Denied errors. Given all this caching of JarFile and the reference count cache for the underlying jar file, is this change of FILE_SHARE_DELETE adding much value and should I pursue it further? [1] https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-delet… -Jaikiran

2 3

RFR: JDK-8277795: ldap connection timeout not honoured under contention
by Rob McKenna 04 Feb '22

04 Feb '22

This fix attemps to resolve an issue where threads can stack up on each other while waiting to get a connection from the ldap pool to an unreachable server. It does this by having each thread start a countdown prior to holding the pools' lock. (which has been changed to a ReentrantLock) Once the lock has been grabbed, the timeout is adjusted to take the waiting time into account and the process of getting a connection from the pool or creating a new one commences. Note: this fix also changes the meaning of the connection pools initSize somewhat. In a situation where we have a large initSize and a small timeout the first thread could actually exhaust the timeout before creating all of its initial connections. Instead this fix simply creates a single connection per pool-connection-request. It continues to do so for subsequent requests regardless of whether an existing unused connection is available in the pool until initSize is exhausted. As such it may require a CSR. ------------- Commit messages: - JDK-8277795: formatting - JDK-8277795: whitespace cleanup - JDK-8277795: ldap connection timeout not honoured under contention Changes: https://git.openjdk.java.net/jdk/pull/6568/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6568&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277795 Stats: 318 lines in 4 files changed: 175 ins; 72 del; 71 mod Patch: https://git.openjdk.java.net/jdk/pull/6568.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6568/head:pull/6568 PR: https://git.openjdk.java.net/jdk/pull/6568

4 21

RFR: JDK-8277375: jdeps errors on a class path with a file path with no permission
by Mandy Chung 27 Jan '22

27 Jan '22

This changes jdeps -cp to ignore files/directories with no permission to access. This is consistent with the runtime behavior. ------------- Commit messages: - JDK-8277375: jdeps errors on a class path with a file path with no permission Changes: https://git.openjdk.java.net/jdk/pull/6531/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6531&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277375 Stats: 113 lines in 2 files changed: 106 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6531.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6531/head:pull/6531 PR: https://git.openjdk.java.net/jdk/pull/6531

4 7

RFR: 8277155: Compress and expand vector operations
by Paul Sandoz 20 Jan '22

20 Jan '22

Add two new cross-lane vector operations, `compress` and `expand`. An example of such usage might be code that selects elements from array `a` and stores those selected elements in array `z`: int[] a = ...; int[] z = ...; int ai = 0, zi = 0; while (ai < a.length) { IntVector av = IntVector.fromArray(SPECIES, a, ai); // query over elements of vector av // returning a mask marking elements of interest VectorMask<Integer> m = interestingBits(av, ...); IntVector zv = av.compress(m); zv.intoArray(z, zi, m.compress()); ai += SPECIES.length(); zi += m.trueCount(); } (There's also a more sophisticated version using `unslice` to coalesce matching elements with non-masked stores.) Given RDP 1 for 18 is getting close, 2021/12/09, we may not get this reviewed in time and included in [JEP 417](https://openjdk.java.net/jeps/417). Still I think I think it worth starting the review now (the CSR is marked provisional). ------------- Commit messages: - 8277155: Compress and expand vector operations Changes: https://git.openjdk.java.net/jdk/pull/6545/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6545&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277155 Stats: 5429 lines in 105 files changed: 5315 ins; 21 del; 93 mod Patch: https://git.openjdk.java.net/jdk/pull/6545.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6545/head:pull/6545 PR: https://git.openjdk.java.net/jdk/pull/6545

1 3

RFR: 8277535: Remove redundant Stream.distinct()/sorted() steps
by Andrey Turbanov 20 Jan '22

20 Jan '22

1. Stream.distinct() is redundant before toSet() collector. Duplicates will be collapsed by Collector. 2. Stream.sorted() is redundant before toMap() collector. Keys will be shuffled by Collector (it's a HashMap in current implementation) ------------- Commit messages: - [PATCH] Remove redundant Stream.distinct()/sorted() steps Changes: https://git.openjdk.java.net/jdk/pull/5714/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5714&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277535 Stats: 4 lines in 3 files changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5714.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5714/head:pull/5714 PR: https://git.openjdk.java.net/jdk/pull/5714

3 3

RFR: 8274811: Remove superfluous use of boxing in java.base
by Andrey Turbanov 19 Jan '22

19 Jan '22

Usages of primitive types should be preferred and makes code easier to read. Similar cleanups: 1. [JDK-8273168](https://bugs.openjdk.java.net/browse/JDK-8273168) java.desktop 2. [JDK-8274234](https://bugs.openjdk.java.net/browse/JDK-8274234) java.sql.rowset ------------- Commit messages: - [PATCH] Remove superfluous use of boxing in java.base - [PATCH] Remove superfluous use of boxing in java.* modules - [PATCH] Remove superfluous use of boxing in java.* modules Changes: https://git.openjdk.java.net/jdk/pull/5481/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5481&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274811 Stats: 11 lines in 4 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5481.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5481/head:pull/5481 PR: https://git.openjdk.java.net/jdk/pull/5481

7 8

RFR: JDK-8276939: Fix AbstractLdapNamingEnumeration next to throw NoSuchElementException instead of NullPointerException
by andrewluotechnologies 13 Jan '22

13 Jan '22

`AbstractLdapNamingEnumeration` `next` throws `NullPointerException` instead of `NoSuchElementException`, however the javadoc for `NamingEnumeration` says that next should throw `NoSuchElementException` when no elements are available (https://docs.oracle.com/en/java/javase/17/docs/api/java.naming/javax/naming…) The bug is basically that `next()` calls `hasMore()` -> `hasMoreImpl()` which calls `cleanup()` when there are no more elements. `cleanup()` sets `homeCtx = null;` which causes NullPointerException to be thrown on this line in `getNextBatch()`: `res = homeCtx.getSearchReply(enumClnt, res);` ------------- Commit messages: - JDK-8276939: Fix AbstractLdapNamingEnumeration next to throw NoSuchElementException instead of NullPointerException Changes: https://git.openjdk.java.net/jdk/pull/6095/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6095&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276939 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6095.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6095/head:pull/6095 PR: https://git.openjdk.java.net/jdk/pull/6095

2 1

RFR: 8277015: Use blessed modifier order in Panama code
by Magnus Ihse Bursie 13 Jan '22

13 Jan '22

I ran bin/blessed-modifier-order.sh on source owned by Project Panama. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. In this case, while the script did into the "correct" thing, it turns out that the method signatures in `src/jdk.incubator.vector/share/classes/jdk/incubator/vector` has some room for improvement... The files contains method headers which look like this: final @Override @ForceInline long longToElementBits(... @ForceInline static long toIntegralChecked(... @ForceInline @Override final ByteVector dummyVector(... My personal opinion is that these should have been written like this: @Override @ForceInline final long longToElementBits(... @ForceInline static long toIntegralChecked(... @ForceInline @Override final ByteVector dummyVector(... or possibly @Override @ForceInline final long longToElementBits(... @ForceInline static long toIntegralChecked(... @ForceInline @Override final ByteVector dummyVector(... If you want me to make that change as well as part of the fix, let me know. Furthermore, I don't know how much the code in mainline differs from the code in the Panama branches. If the discrepancy is large, you might want to run `bash bin/blessed-modifier-order.sh src/jdk.incubator.vector` and `bash bin/blessed-modifier-order.sh src/jdk.incubator.foreign` in those branches. ------------- Commit messages: - 8277015: Use blessed modifier order in Panama code Changes: https://git.openjdk.java.net/jdk/pull/6355/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6355&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277015 Stats: 21 lines in 13 files changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/6355.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6355/head:pull/6355 PR: https://git.openjdk.java.net/jdk/pull/6355

6 20