On Tue, Apr 12, 2022 at 9:14 AM Mark Thomas <ma...@apache.org> 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. > > <snip/> > > > 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
