On Tue, 27 Sep 2022 11:30:26 GMT, Doug Simon <dnsi...@openjdk.org> wrote:
> This PR adds a new jlink plugin (`--copy-files=<filenames>`) that copies > specified files from the current image into the output image. > This is useful in the context of GraalVM where libgraal (e.g. > `lib/libjvmcicompiler.so`) is produced after the final jlink step in the > GraalVM JDK build process. The plugin makes it possible for jlink in a > GraalVM JDK to propagate libgraal. > > The advantages of this solution over packaging libgraal as a module are: > * No need to complicate and slow down the GraalVM JDK build process with an > extra jlink step. > * No need to pay the footprint of libgraal twice in a GraalVM JDK (i.e., once > in,`lib/libjvmcicompiler.so` and again in a jmod file). @dougxc As you know, the JDK moved to a modular run-image in JDK 9 with jlink generating a run-time image from a set of modules. Aside from src.zip, we've avoiding needing to overlay files that aren't coming from modules so it sets up jlink for possible optimizations in the future where it knows about all classes and resources. A general purpose CopyFiles plugin goes against that design/direction to some extent as it can be used to copy anything into the run-time image. The jlink tool may be doing the copying but the connection to any module is lost. So I think we need to be cautious and fully understand the problems. What are the complicates and performance issues when libjvmcicompiler.so is in a module? Is this a jmod or jlink performance issue that should be looked at? ------------- PR: https://git.openjdk.org/jdk/pull/10448
