On Wed, Apr 13, 2022 at 9:45 AM Christopher Schultz < ch...@christopherschultz.net> wrote:
> Filip, > > On 4/11/22 18:32, Filip Hanik wrote: > > Hi folks, > > > > I'm jumping in on the bandwagon again. Specifically to talk some more > about > > native compilation. The graal compiler is making headway, and it's > becoming > > better and better at native compilation [1]. > > > > I'll put some historical context at the bottom of this post for clarity. > I > > have a few suggestions that I'd like some input on > > > > 1. Get rid of tomcat-embed-programmatic > > Why? Does it interfere with providing GraalVM support? > tomcat-embed-programmatic.jar is a subset of the existing tomcat-embed-core.jar Moving forward, we'd like to not have to create a secondary artifact, if we can achieve the same optimizations by using the existing artifact tomcat-embed-core.jar > > > 2. Refactor existing graal JSON instructions [2] > > 3. Potentially introduce tomcat-embed-graal > > 4. Add in build feature flags to the code or code optimizations > > > > Today > > The amount of input we can provide to the graal compiler today, lets us > > work around many of the issues that were the reason for the > > tomcat-embed-programmatic. > > > > For example, graal can apply build time code substitution, like mentioned > > here [4]. We can also provide multiple JSON files [2], and effectively > > create profiles. So there can be an NIO profile, an NIO2 profile and an > APR > > profile, if that's desired. > > > > Back to Proposal > > 1. Remove tomcat-embed-programmatic > > I believe this served its purpose. > > How would anyone use Tomcat in an embedded way without this? Or are you > suggesting that a tomcat-embed-graal could be used in its place, but > without actually using GraalVM? Say some product wants to ship with (a) > Tomcat embedded (using whatever strategy, where the application > orchestrates the launch of the servlet container instead of the > container launching the application) and (b) OpenJDK (or pick your JVM). > Would that still be possible? Because taking that away would be a Bad > Thing IMHO. > It may be easier if I illustrate this via the graal native compilation command, where the classpath changes ## Optimized Tomcat today - uses modified programmatic artifact to achieve optimal size native-image \ #compiler -H:Name=my-app-native \ #name of produced binary -cp ../embed/tomcat-embed-programmatic.jar:my-application.jar \ #classpath org.example.MyNativeEmbeddedTomcat #launch class ## Optimized Tomcat tomorrow - achieve the same optimizations native-image \ #compiler -some-flag \ #flags that select an optimized embedded tomcat profile, for example NIO only -H:Name=my-app-native \ #name of produced binary -cp ../embed/tomcat-embed-core.jar:my-application.jar \ #classpath org.example.MyNativeEmbeddedTomcat #launch class > > > 2. Refactor existing graal JSON files > > This can allow us to create profiles with various memory footprints > > depending on functionality desired. > > > > 3. Potentially introduce tomcat-embed-graal > > This can have various code substitutions that we find beneficial. [4] > > > > 4. Add in build feature flags to the code or code optimizations > > graal can still do static analysis to optimize inclusion of code paths. > as > > demonstrated in this example [5]. As this seems to pollute our codebase > > with graal specific stuff when it could have been done as a substitution, > > I'm still presenting it to gather more opinions. > > > > Filip > > > > Historical Context > > When we created tomcat-embed-programmatic, we did so to reduce the memory > > footprint[3] of the simplest tomcat installation. At the time, the graal > > compiler was indiscriminate and would absorb virtually any class file in > a > > library. So we created an experimental jar, tomcat-embed-programmatic, > that > > was reduced to be embedded, no resource files, no XML support, and > removed > > the reflection property setters for configurable components. > > Hmm. Perhaps I don't understand exactly what tomcat-embed-programmatic > means. I was thinking you were talking about dropping the Tomcat class > which is used to launch Tomcat from other Java code. > tomcat-embed-programmatic == tomcat-embed-core <minus> NIO2/APR/string resources/other-code-that-isn't-needed Basically, to produce tomcat-embed-programmatic, we took the "core" artifact, and removed files from the .jar file that we knew belonged in code paths that wouldn't get executed. Filip > Apologies if I'm speaking from a position of ignorance. > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
