On Wed, 10 Jun 2026 12:34:38 GMT, Dusan Balek <[email protected]> wrote:
>> 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.or... > > Dusan Balek has updated the pull request incrementally with one additional > commit since the last revision: > > Modified to follow the last reviewer comment. The javac part seems sensible to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/31417#pullrequestreview-4467837398
