Re: speed of class loading via a modulepath
Thanks, Rémi and Alan. On 11/19/18 12:53 AM, Alan Bateman wrote: On 18/11/2018 20:00, Richard Hillegas wrote: I am updating Apache Derby documentation to reflect the recent modularization of the codeline. While doing this, I have stumbled across an old piece of advice from the Derby Tuning Guide: "The structure of your classpath can affect Derby startup time and the time required to load a particular class. The classpath is searched linearly, so locate Derby's libraries at the beginning of the classpath so that they are found first. If the classpath first points to a directory that contains multiple files, booting Derby can be very slow." That may be an old, Java 1.2 concern, which no longer affects modern JVMs. I have a couple questions: 1) Is this still good advice when booting a large application like Derby via a classpath? 2) What about the modulepath? Can classes be faulted in faster by re-arranging the order of jar files on the modulepath? The position of the directory or module on the module path won't impact class/resources loading as modules are accessed directly (as Remi notes) so no linear scan/searching after startup. Ordering is of course important when you end up with a multiple versions of the same module on the path, in that case the first version of a module wins. One other thing to be aware of is that the initial scanning of the module path can be slow when it contains lots of automatic modules or modules that have been packaged with the jar tool from JDK 8 or older. Explicit modules that are packaged with the JDK 9 (or newer) jar tool are indexed at packaging time to avoid scanning the contents at startup. -Alan
Re: speed of class loading via a modulepath
On 18/11/2018 20:00, Richard Hillegas wrote: I am updating Apache Derby documentation to reflect the recent modularization of the codeline. While doing this, I have stumbled across an old piece of advice from the Derby Tuning Guide: "The structure of your classpath can affect Derby startup time and the time required to load a particular class. The classpath is searched linearly, so locate Derby's libraries at the beginning of the classpath so that they are found first. If the classpath first points to a directory that contains multiple files, booting Derby can be very slow." That may be an old, Java 1.2 concern, which no longer affects modern JVMs. I have a couple questions: 1) Is this still good advice when booting a large application like Derby via a classpath? 2) What about the modulepath? Can classes be faulted in faster by re-arranging the order of jar files on the modulepath? The position of the directory or module on the module path won't impact class/resources loading as modules are accessed directly (as Remi notes) so no linear scan/searching after startup. Ordering is of course important when you end up with a multiple versions of the same module on the path, in that case the first version of a module wins. One other thing to be aware of is that the initial scanning of the module path can be slow when it contains lots of automatic modules or modules that have been packaged with the jar tool from JDK 8 or older. Explicit modules that are packaged with the JDK 9 (or newer) jar tool are indexed at packaging time to avoid scanning the contents at startup. -Alan
Re: speed of class loading via a modulepath
Hi Richard, - Mail original - > De: "Richard Hillegas" > À: "core-libs-dev" > Envoyé: Dimanche 18 Novembre 2018 21:00:14 > Objet: speed of class loading via a modulepath > I am updating Apache Derby documentation to reflect the recent > modularization of the codeline. While doing this, I have stumbled across > an old piece of advice from the Derby Tuning Guide: > > "The structure of your classpath can affect Derby startup time and the > time required to load a particular class. > > The classpath is searched linearly, so locate Derby's libraries at the > beginning of the classpath so that they are found first. If the > classpath first points to a directory that contains multiple files, > booting Derby can be very slow." > > That may be an old, Java 1.2 concern, which no longer affects modern > JVMs. I have a couple questions: > > 1) Is this still good advice when booting a large application like Derby > via a classpath? yes. > > 2) What about the modulepath? Can classes be faulted in faster by > re-arranging the order of jar files on the modulepath? For the modulepath, a module own the packages it contains so the VM maintains a map that associate a package name to a modular jar, there is no linear lookup to find a class anymore. Now, if you use the modulepath, you may have regression at startup compared to using the classpath because by default the module graph is created and checked at startup before running the application. For faster startup, you can combined jlink (that created one archive from all jars), appcds (prepare an image of the classes in memory), jaotc (pre-JIT the bytecode) or use graal native image (again pre-JIT + one image but with reflection limitation and its own GC). > > Thanks, > -Rick cheers, Rémi
speed of class loading via a modulepath
I am updating Apache Derby documentation to reflect the recent modularization of the codeline. While doing this, I have stumbled across an old piece of advice from the Derby Tuning Guide: "The structure of your classpath can affect Derby startup time and the time required to load a particular class. The classpath is searched linearly, so locate Derby's libraries at the beginning of the classpath so that they are found first. If the classpath first points to a directory that contains multiple files, booting Derby can be very slow." That may be an old, Java 1.2 concern, which no longer affects modern JVMs. I have a couple questions: 1) Is this still good advice when booting a large application like Derby via a classpath? 2) What about the modulepath? Can classes be faulted in faster by re-arranging the order of jar files on the modulepath? Thanks, -Rick
