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
