Re: Native Compilation, Continuation 2022
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 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 > >
Re: Native Compilation, Continuation 2022
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? 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. 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. 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
Re: Native Compilation, Continuation 2022
On Tue, Apr 12, 2022 at 9:14 AM Mark Thomas wrote: > > On 11/04/2022 23: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 > > Keep in mind I have not been as involved in these changes as other folks > have so while I am expressing my current opinions below, I am likely to > defer to the folks that have been more involved if their opinion differs > from mine. > > > > > Back to Proposal > > 1. Remove tomcat-embed-programmatic > > I believe this served its purpose. > > If there is consensus that it has served its purpose then removal makes > sense. I have no view on whether tomcat-embed-programmatic has served > its purpose or not. > > Would this be deprecation in 9.0.x/10.0.x and removal in 10.1.x? > > > 2. Refactor existing graal JSON files > > This can allow us to create profiles with various memory footprints > > depending on functionality desired. > > Seems reasonable to me. > > > 3. Potentially introduce tomcat-embed-graal > > This can have various code substitutions that we find beneficial. [4] > > If this sits alongside the existing code in a separate package and JAR > (or something along those lines) then that seems reasonable to me. > > > 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. > > This is the interesting one. > > I think there is a balance to strike here between making native > compilation easier and making the existing code less clear. I think I'd > want to look at each proposed refactoring on a case-by-case basis. > Generally, I'm willing to consider a little more complexity but I > suspect there will be some cases where substitution is the better option. Yes, I agree with that opinion, it's all about good balance. I'm not sure that the additional benefits that remain matter a lot (as an example, embedded code generation does something, but it's really little; generating the full web.xml processing was something I tried, but it starts being very complex very quickly), so this better not do anything that would look weird or convoluted to achieve something. Overall Tomcat is still EE so it's never going to be fully optimal for Graal, which IMO is not the end of the world (the container remains small compared to the app, so any savings will be hard to notice; feel free to prove me wrong ;) ). Last, there will be more AOT techs after Graal. Rémy > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Native Compilation, Continuation 2022
On 11/04/2022 23: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 Keep in mind I have not been as involved in these changes as other folks have so while I am expressing my current opinions below, I am likely to defer to the folks that have been more involved if their opinion differs from mine. Back to Proposal 1. Remove tomcat-embed-programmatic I believe this served its purpose. If there is consensus that it has served its purpose then removal makes sense. I have no view on whether tomcat-embed-programmatic has served its purpose or not. Would this be deprecation in 9.0.x/10.0.x and removal in 10.1.x? 2. Refactor existing graal JSON files This can allow us to create profiles with various memory footprints depending on functionality desired. Seems reasonable to me. 3. Potentially introduce tomcat-embed-graal This can have various code substitutions that we find beneficial. [4] If this sits alongside the existing code in a separate package and JAR (or something along those lines) then that seems reasonable to me. 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. This is the interesting one. I think there is a balance to strike here between making native compilation easier and making the existing code less clear. I think I'd want to look at each proposed refactoring on a case-by-case basis. Generally, I'm willing to consider a little more complexity but I suspect there will be some cases where substitution is the better option. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
