December 2021 - core-libs-dev

JDK-17: Wndows jpackage destination directory not writable
by Sverre Moe 07 Mar '22

07 Mar '22

With JDK 17, jpackage fails to write to the destination directory on Windows. It worked fine with JDK 11 (with jpackage from JDK14) and Docker. Only happens on Windows docker. Running directly on WIndows it works with JDK 17. What has changed with jpackage that it no longer can write to the destination directory when running in Docker? Is it a regression/bug with jpackage? > Task :jpackageImage Caching disabled for task ':jpackageImage' because: Build cache is disabled Task ':jpackageImage' is not up-to-date because: Task has failed previously. input subdir: my-javafx-application Starting process 'command 'C:\Program Files\Java\jdk-17/bin/jpackage.exe''. Working directory: C:\Temp\my-javafx-application Command: C:\Program Files\Java\jdk-17/bin/jpackage.exe --type app-image --input C:\Temp\my-javafx-application\build\install\my-javafx-application\lib --main-jar my-javafx-application-1.8.0-SNAPSHOT.jar --main-class no.spacetec.dashboard.core.MeosDashboardLauncher --dest C:\Temp\my-javafx-application\build\native --name my-javafx-application --app-version 1.8.0 --runtime-image C:\Temp\my-javafx-application\build\runtime --resource-dir C:\Temp\my-javafx-application\build\package --java-options -Dfile.encoding=UTF-8 --java-options -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector --java-options -Dlog4j.configurationFactory=no.spacetec.dashboard.core.LoggingConfigurationFactory --verbose --description MEOS Dashboard Monitor and Control System GUI --vendor Kongsberg Space Ground Systems --icon C:\Temp\my-javafx-application\build/package/my-javafx-application.png Successfully started process 'command 'C:\Program Files\Java\jdk-17/bin/jpackage.exe'' [03:15:28.286] jdk.jpackage.internal.PackagerException: Destination directory C:\Temp\my-javafx-application\build\native is not writable at jdk.jpackage/jdk.jpackage.internal.IOUtils.writableOutputDir(IOUtils.java:266) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.createRoot(AppImageBundler.java:134) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.createAppBundle(AppImageBundler.java:163) at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.execute(AppImageBundler.java:91) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:676) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:550) at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52)

3 5

RFR: 8275731: CDS archived enums objects are recreated at runtime
by Ioi Lam 28 Feb '22

28 Feb '22

**Background:** In the Java Language, Enums can be tested for equality, so the constants in an Enum type must be unique. Javac compiles an enum declaration like this: public enum Day { SUNDAY, MONDAY ... } to public class Day extends java.lang.Enum { public static final SUNDAY = new Day("SUNDAY"); public static final MONDAY = new Day("MONDAY"); ... } With CDS archived heap objects, `Day::<clinit>` is executed twice: once during `java -Xshare:dump`, and once during normal JVM execution. If the archived heap objects references one of the Enum constants created at dump time, we will violate the uniqueness requirements of the Enum constants at runtime. See the test case in the description of [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731) **Fix:** During -Xshare:dump, if we discovered that an Enum constant of type X is archived, we archive all constants of type X. At Runtime, type X will skip the normal execution of `X::<clinit>`. Instead, we run `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that were saved at dump time. This is safe as we know that `X::<clinit>` has no observable side effect -- it only creates the constants of type X, as well as the synthetic value `X::$VALUES`, which cannot be observed until X is fully initialized. **Verification:** To avoid future problems, I added a new tool, CDSHeapVerifier, to look for similar problems where the archived heap objects reference a static field that may be recreated at runtime. There are some manual steps involved, but I analyzed the potential problems found by the tool are they are all safe (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details. An example trace of this tool can be found at https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt **Testing:** Passed Oracle CI tiers 1-4. WIll run tier 5 as well. ------------- Commit messages: - 8275731: CDS archived enums objects are recreated at runtime Changes: https://git.openjdk.java.net/jdk/pull/6653/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6653&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275731 Stats: 829 lines in 16 files changed: 787 ins; 2 del; 40 mod Patch: https://git.openjdk.java.net/jdk/pull/6653.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6653/head:pull/6653 PR: https://git.openjdk.java.net/jdk/pull/6653

4 15

RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe
by liach 22 Feb '22

22 Feb '22

Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) ------------- Commit messages: - 8261407: ReflectionFactory.checkInitted() is not thread-safe Changes: https://git.openjdk.java.net/jdk/pull/6889/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261407 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6889/head:pull/6889 PR: https://git.openjdk.java.net/jdk/pull/6889

5 42

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: 8213905: reflection not working for type annotations applied to exception types in the inner class constructor
by Vicente Romero 26 Jan '22

26 Jan '22

Hi, Please review this change that is fixing a bug in reflection in particular in `sun.reflect.annotation.TypeAnnotationParser::buildAnnotatedTypes` the current code is assuming that for inner class constructors it is always working on type annotations on parameters, but it is also invoked to extract type annotations applied to exception types for example. TIA ------------- Commit messages: - 8213905: Reflection, TYPE_USE annotation on THROWS on inner class constructor, Java 9+ Changes: https://git.openjdk.java.net/jdk/pull/6869/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6869&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8213905 Stats: 16 lines in 2 files changed: 11 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6869.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6869/head:pull/6869 PR: https://git.openjdk.java.net/jdk/pull/6869

4 6

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