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.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to