> When used with the `--system` option to target a different modularized JDK, > `JavacTask` keeps both `lib/jrt-fs.jar` and `lib/modules` open even after it > completes. > > The `lib/jrt-fs.jar` file remains open because the host-side > `JrtFileSystemProvider` creates a `URLClassLoader` to load the target > platform's `JrtFileSystemProvider` from `lib/jrt-fs.jar` when creating a > `JrtFileSystem`. This `URLClassLoader` is never closed, causing the file to > remain open. > > The `lib/modules` file remains open because `BasicImageReader` uses a > memory-mapped file whose mapping persists until the associated buffer is > garbage-collected. > > To ensure that `lib/jrt-fs.jar` is properly closed, the proposed solution is > to make the client responsible for closing the file system's class loader > when "java.home" is passed in the `env` argument to > `FileSystems.newFileSystem(...)`. > This approach (currently implemented in the `Locations` class) is simple and > works reliably even with older target platform versions. (An alternative > approach would be to automatically close the `URLClassLoader` when the > `JrtFileSystem` is closed. However, this solution has two significant > drawbacks. First, it does not work with older target platform versions > because it requires modifications to the target platform's `JrtFileSystem` > implementation. Second, it is not reliable. A user may obtain a reference to > the provider that created a `JrtFileSystem` instance, close that instance, > and then use the same provider to create another `JrtFileSystem`. In that > case, the provider's `URLClassLoader` may have already been closed > automatically, preventing the creation of the new file system instance). > > To ensure that `lib/modules` is properly closed, the proposed solution is to > modify `BasicImageReader` so that it uses memory-mapped I/O only for the > current runtime and falls back to regular file I/O when accessing a different > target system. (An alternative solution would be to explicitly unmap the > memory-mapped file when the reader is closed. On JDK 22 and later, the > Foreign Function & Memory API could be used for that purpose. However, in > that case, `lib/jrt-fs.jar` could no longer be compiled to run on JDK 8). > Note that neither of these solutions work for older target platform versions, > as both require changes to the target platform's `BasicImageReader` > implementation. > > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai).
Dusan Balek has updated the pull request incrementally with one additional commit since the last revision: Following reviewver comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/31417/files - new: https://git.openjdk.org/jdk/pull/31417/files/2a8fcc97..d84bab9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=31417&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=31417&range=00-01 Stats: 38 lines in 2 files changed: 11 ins; 18 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/31417.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/31417/head:pull/31417 PR: https://git.openjdk.org/jdk/pull/31417
