Re: Becoming graalvm friendly?

[Romain Manni-Bucau]

Depending the reflection usage you can generate a feature registering all
the classes for reflections, is it predicble and "generable" at build time?
Can lead to a "a bit too big" metadata space but nothing crazy.

here what i used in manual mode for a sample (if it helps):
https://github.com/rmannibucau/docosh/blob/broken-graal-threadlocal/src/main/java/com/github/rmannibucau/docker/compose/cli/svm/Feature_Reflections.java#L35

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 26 avr. 2019 à 11:42, Rémy Maucherat  a écrit :

> On Thu, Apr 25, 2019 at 3:07 PM Rémy Maucherat  wrote:
>
> > On Wed, Apr 24, 2019 at 6:29 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> Awesome news Rémy, thanks for sharing!
> >>
> >
> > Next roadblock is https://github.com/oracle/graal/issues/684
> > It's probably not 100% mandatory but I'd rather have a minimum of
> > flexibility (I'm not a big believer of Java only embedding since
> > configuration can get complex fast and it's harder to maintain long
> term).
> >
> > Feel free to help if you'd like.
> >
>
> Ok, so after configuring reflection to some extent in order to examine the
> behavior, I am now rather confident things might work out eventually.
> I thought the best strategy was to add tracing to Tomcat and have the user
> do a regular run with its config to generate the reflection json. In the
> end, I found that there's a tool to do that already in graal, in the form
> of a jvm agent. I then ran into
> https://github.com/oracle/graal/issues/1194
> (exact same crash trace), not sure about any workaround so I'll wait for
> the issue to be resolved in a future RC.
>
> Rémy
>

Re: Becoming graalvm friendly?

[Rémy Maucherat]

On Thu, Apr 25, 2019 at 3:07 PM Rémy Maucherat  wrote:

> On Wed, Apr 24, 2019 at 6:29 PM Romain Manni-Bucau 
> wrote:
>
>> Awesome news Rémy, thanks for sharing!
>>
>
> Next roadblock is https://github.com/oracle/graal/issues/684
> It's probably not 100% mandatory but I'd rather have a minimum of
> flexibility (I'm not a big believer of Java only embedding since
> configuration can get complex fast and it's harder to maintain long term).
>
> Feel free to help if you'd like.
>

Ok, so after configuring reflection to some extent in order to examine the
behavior, I am now rather confident things might work out eventually.
I thought the best strategy was to add tracing to Tomcat and have the user
do a regular run with its config to generate the reflection json. In the
end, I found that there's a tool to do that already in graal, in the form
of a jvm agent. I then ran into https://github.com/oracle/graal/issues/1194
(exact same crash trace), not sure about any workaround so I'll wait for
the issue to be resolved in a future RC.

Rémy

Re: Becoming graalvm friendly?

[Rémy Maucherat]

On Wed, Apr 24, 2019 at 6:29 PM Romain Manni-Bucau 
wrote:

> Awesome news Rémy, thanks for sharing!
>

Next roadblock is https://github.com/oracle/graal/issues/684
It's probably not 100% mandatory but I'd rather have a minimum of
flexibility (I'm not a big believer of Java only embedding since
configuration can get complex fast and it's harder to maintain long term).

Feel free to help if you'd like.

Rémy

Re: Becoming graalvm friendly?

[Romain Manni-Bucau]

Awesome news Rémy, thanks for sharing!

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 24 avr. 2019 à 18:06, Rémy Maucherat  a écrit :

> On Thu, Mar 28, 2019 at 3:38 PM Rémy Maucherat  wrote:
>
> > On Wed, Mar 20, 2019 at 4:45 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> Most of the time monitoring is done through a custom exporter in
> practise
> >> based on other impl - sigar, library integration like
> >> hibernate/eclipselinks ones, metrics, microprofile etc... -  and JMX is
> >> not
> >> then used - not judging it is good, bad, lack of knowledge or not, just
> >> saying what i see.
> >> Now I'm happy if JMX is made graal compatible. From what I saw, mainly
> the
> >> MBeanServer and Notifier (through the hierarchy it goes until that point
> >> in
> >> the JVM in standard mbeans) are blocking the compilation. I'm pretty
> sure
> >> these parts of Tomcat can be extracted in a particular class and then
> >> substrated which would make it graal compatible probably.
> >>
> >
> > Ok, so I had a (quick) look, and this doesn't seem to be something that
> is
> > adapted to Tomcat at this time.
> >
> > Steps:
> > - I built the embedded packaging here
> > https://github.com/apache/tomcat/tree/master/res/tomcat-maven
> > - It produces a standalone jar in target/tomcat-maven-1.0.jar
> > - Une the graal tool $GRAALVM/bin/native-image -jar
> > target/tomcat-maven-1.0.jar
> >
> > Produces:
> > Error: No instances are allowed in the image heap for a class that is
> > initialized or reinitialized at image runtime:
> > java.util.logging.SimpleFormatter
> > Detailed message:
> > Error: No instances are allowed in the image heap for a class that is
> > initialized or reinitialized at image runtime:
> > java.util.logging.SimpleFormatter
> > Trace: object java.util.logging.ConsoleHandler
> > object java.lang.Object[]
> > object java.util.concurrent.CopyOnWriteArrayList
> > object java.util.logging.LogManager$RootLogger
> > object java.util.logging.Logger
> > object org.apache.juli.logging.DirectJDKLog
> > method
> > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
> > Object, boolean)
> > Call path from entry point to
> > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
> > Object, boolean):
> > at
> >
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:390)
> > at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:193)
> > at org.apache.catalina.startup.Tomcat.start(Tomcat.java:455)
> > at org.apache.catalina.startup.Tomcat.main(Tomcat.java:1444)
> > at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:152)
> > at
> >
> com.oracle.svm.core.code.IsolateEnterStub.JavaMainWrapper_run_5087f5482cc9a6abc971913ece43acb471d2631b(generated:0)
> >
> > If you want to work on this, you can (git makes it easy) but it looks a
> > bit daunting at this point (java.util.logging is not supported either ?
> > this is not documented at
> > https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md
> ).
> >
>
> https://www.graalvm.org/docs/release-notes/#10-rc16 finally adds
> java.util.logging support, so I can resume investigations.
>
> ../graalvm-ce-1.0.0-rc16/bin/native-image -jar tomcat-maven-1.0.jar
> Build on Server(pid: 1452, port: 38003)*
> [tomcat-maven-1.0:1452]classlist:   2,157.50 ms
> [tomcat-maven-1.0:1452](cap): 801.03 ms
> [tomcat-maven-1.0:1452]setup:   1,746.56 ms
> [tomcat-maven-1.0:1452]   (typeflow):   4,968.17 ms
> [tomcat-maven-1.0:1452](objects):   3,425.07 ms
> [tomcat-maven-1.0:1452]   (features): 176.88 ms
> [tomcat-maven-1.0:1452] analysis:   8,816.22 ms
> [tomcat-maven-1.0:1452] universe: 289.24 ms
> Warning: Reflection method java.lang.Class.forName invoked at
> org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:686)
> Warning: Reflection method java.lang.Class.forName invoked at
>
> org.apache.catalina.core.NamingContextListener.constructEnvEntry(NamingContextListener.java:797)
> Warning: Reflection method java.lang.Class.forName invoked at
>
> org.apache.tomcat.util.modeler.ManagedBean.createMBean(ManagedBean.java:303)
> Warning: Reflection method java.lang.Class.forName invoked at
> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:821)
> Warning: Reflection method java.lang.Class.forName invoked at
>
> org.apache.catalina.realm.RealmBase.createUsernameRetriever(RealmBase.java:1506)
> Warning: Reflection method java.lang.Class.forName invoked at
> org.apache.catalina.startup.Tomcat.createContext(Tomcat.java:964)
> Warning: Reflection method java.lang.Class.forName 

Re: Becoming graalvm friendly?

[Rémy Maucherat]

On Thu, Mar 28, 2019 at 3:38 PM Rémy Maucherat  wrote:

> On Wed, Mar 20, 2019 at 4:45 PM Romain Manni-Bucau 
> wrote:
>
>> Most of the time monitoring is done through a custom exporter in practise
>> based on other impl - sigar, library integration like
>> hibernate/eclipselinks ones, metrics, microprofile etc... -  and JMX is
>> not
>> then used - not judging it is good, bad, lack of knowledge or not, just
>> saying what i see.
>> Now I'm happy if JMX is made graal compatible. From what I saw, mainly the
>> MBeanServer and Notifier (through the hierarchy it goes until that point
>> in
>> the JVM in standard mbeans) are blocking the compilation. I'm pretty sure
>> these parts of Tomcat can be extracted in a particular class and then
>> substrated which would make it graal compatible probably.
>>
>
> Ok, so I had a (quick) look, and this doesn't seem to be something that is
> adapted to Tomcat at this time.
>
> Steps:
> - I built the embedded packaging here
> https://github.com/apache/tomcat/tree/master/res/tomcat-maven
> - It produces a standalone jar in target/tomcat-maven-1.0.jar
> - Une the graal tool $GRAALVM/bin/native-image -jar
> target/tomcat-maven-1.0.jar
>
> Produces:
> Error: No instances are allowed in the image heap for a class that is
> initialized or reinitialized at image runtime:
> java.util.logging.SimpleFormatter
> Detailed message:
> Error: No instances are allowed in the image heap for a class that is
> initialized or reinitialized at image runtime:
> java.util.logging.SimpleFormatter
> Trace: object java.util.logging.ConsoleHandler
> object java.lang.Object[]
> object java.util.concurrent.CopyOnWriteArrayList
> object java.util.logging.LogManager$RootLogger
> object java.util.logging.Logger
> object org.apache.juli.logging.DirectJDKLog
> method
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
> Object, boolean)
> Call path from entry point to
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
> Object, boolean):
> at
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:390)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:193)
> at org.apache.catalina.startup.Tomcat.start(Tomcat.java:455)
> at org.apache.catalina.startup.Tomcat.main(Tomcat.java:1444)
> at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:152)
> at
> com.oracle.svm.core.code.IsolateEnterStub.JavaMainWrapper_run_5087f5482cc9a6abc971913ece43acb471d2631b(generated:0)
>
> If you want to work on this, you can (git makes it easy) but it looks a
> bit daunting at this point (java.util.logging is not supported either ?
> this is not documented at
> https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md ).
>

https://www.graalvm.org/docs/release-notes/#10-rc16 finally adds
java.util.logging support, so I can resume investigations.

../graalvm-ce-1.0.0-rc16/bin/native-image -jar tomcat-maven-1.0.jar
Build on Server(pid: 1452, port: 38003)*
[tomcat-maven-1.0:1452]classlist:   2,157.50 ms
[tomcat-maven-1.0:1452](cap): 801.03 ms
[tomcat-maven-1.0:1452]setup:   1,746.56 ms
[tomcat-maven-1.0:1452]   (typeflow):   4,968.17 ms
[tomcat-maven-1.0:1452](objects):   3,425.07 ms
[tomcat-maven-1.0:1452]   (features): 176.88 ms
[tomcat-maven-1.0:1452] analysis:   8,816.22 ms
[tomcat-maven-1.0:1452] universe: 289.24 ms
Warning: Reflection method java.lang.Class.forName invoked at
org.apache.catalina.startup.Tomcat.addWebapp(Tomcat.java:686)
Warning: Reflection method java.lang.Class.forName invoked at
org.apache.catalina.core.NamingContextListener.constructEnvEntry(NamingContextListener.java:797)
Warning: Reflection method java.lang.Class.forName invoked at
org.apache.tomcat.util.modeler.ManagedBean.createMBean(ManagedBean.java:303)
Warning: Reflection method java.lang.Class.forName invoked at
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:821)
Warning: Reflection method java.lang.Class.forName invoked at
org.apache.catalina.realm.RealmBase.createUsernameRetriever(RealmBase.java:1506)
Warning: Reflection method java.lang.Class.forName invoked at
org.apache.catalina.startup.Tomcat.createContext(Tomcat.java:964)
Warning: Reflection method java.lang.Class.forName invoked at
org.apache.tomcat.util.modeler.Registry.getModelerSource(Registry.java:723)
Warning: Reflection method java.lang.Class.getMethod invoked at
org.apache.tomcat.util.modeler.ManagedBean.getGetter(ManagedBean.java:450)
Warning: Reflection method java.lang.Class.getMethod invoked at
org.apache.tomcat.util.modeler.ManagedBean.getGetter(ManagedBean.java:443)
Warning: Reflection method java.lang.Class.getMethod invoked at
org.apache.catalina.deploy.NamingResourcesImpl.cleanUp(NamingResourcesImpl.java:1061)
Warning: Reflection method java.lang.Class.getConstructor invoked at

Re: Becoming graalvm friendly?

[Romain Manni-Bucau]

You can make it supporting JUL switching the log manager to a simpler
version, AFAIK this is what quarkus does using jboss logging log manager,
guess it shouldn't be that complicated to switch to a lighter version of
JUL one without reload capabilities - still thinking out loud.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 28 mars 2019 à 16:19, Rémy Maucherat  a écrit :

> On Thu, Mar 28, 2019 at 3:43 PM Romain Manni-Bucau 
> wrote:
>
> > In my case - I tried on meecrowave - i just switched using Log SPI the
> impl
> > to something else - custom log4j2 IIRC - and it passed that state until
> it
> > fails on JMX. Then i @Subtitute some code in the Registry and base
> classes
> > but it is literally "monkey patching" Tomcat which is something I really
> > disliked - versus adding a module using a SPI which deactivates some
> > potential code path.
> >
> > My goal is to avoid to fork most of the stack as quarkus did and ensure
> > built-in tomcat can be compiled natively. Using more SPI can be a good
> > option probably and even open more doors to integrators which is never
> bad
> > IMHO.
> >
>
> Well, support for java.util.logging shouldn't be optional (this isn't even
> documented, while JMX is at least documented as not supported). I don't
> think Tomcat support is ever going to happen unless Graal capabilities
> manages to improve, if at all possible, right now it's simply too alien.
>
> Rémy
>

Re: Becoming graalvm friendly?

[Rémy Maucherat]

On Thu, Mar 28, 2019 at 3:43 PM Romain Manni-Bucau 
wrote:

> In my case - I tried on meecrowave - i just switched using Log SPI the impl
> to something else - custom log4j2 IIRC - and it passed that state until it
> fails on JMX. Then i @Subtitute some code in the Registry and base classes
> but it is literally "monkey patching" Tomcat which is something I really
> disliked - versus adding a module using a SPI which deactivates some
> potential code path.
>
> My goal is to avoid to fork most of the stack as quarkus did and ensure
> built-in tomcat can be compiled natively. Using more SPI can be a good
> option probably and even open more doors to integrators which is never bad
> IMHO.
>

Well, support for java.util.logging shouldn't be optional (this isn't even
documented, while JMX is at least documented as not supported). I don't
think Tomcat support is ever going to happen unless Graal capabilities
manages to improve, if at all possible, right now it's simply too alien.

Rémy

Re: Becoming graalvm friendly?

[Romain Manni-Bucau]

In my case - I tried on meecrowave - i just switched using Log SPI the impl
to something else - custom log4j2 IIRC - and it passed that state until it
fails on JMX. Then i @Subtitute some code in the Registry and base classes
but it is literally "monkey patching" Tomcat which is something I really
disliked - versus adding a module using a SPI which deactivates some
potential code path.

My goal is to avoid to fork most of the stack as quarkus did and ensure
built-in tomcat can be compiled natively. Using more SPI can be a good
option probably and even open more doors to integrators which is never bad
IMHO.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 28 mars 2019 à 15:38, Rémy Maucherat  a écrit :

> On Wed, Mar 20, 2019 at 4:45 PM Romain Manni-Bucau 
> wrote:
>
> > Most of the time monitoring is done through a custom exporter in practise
> > based on other impl - sigar, library integration like
> > hibernate/eclipselinks ones, metrics, microprofile etc... -  and JMX is
> not
> > then used - not judging it is good, bad, lack of knowledge or not, just
> > saying what i see.
> > Now I'm happy if JMX is made graal compatible. From what I saw, mainly
> the
> > MBeanServer and Notifier (through the hierarchy it goes until that point
> in
> > the JVM in standard mbeans) are blocking the compilation. I'm pretty sure
> > these parts of Tomcat can be extracted in a particular class and then
> > substrated which would make it graal compatible probably.
> >
>
> Ok, so I had a (quick) look, and this doesn't seem to be something that is
> adapted to Tomcat at this time.
>
> Steps:
> - I built the embedded packaging here
> https://github.com/apache/tomcat/tree/master/res/tomcat-maven
> - It produces a standalone jar in target/tomcat-maven-1.0.jar
> - Une the graal tool $GRAALVM/bin/native-image -jar
> target/tomcat-maven-1.0.jar
>
> Produces:
> Error: No instances are allowed in the image heap for a class that is
> initialized or reinitialized at image runtime:
> java.util.logging.SimpleFormatter
> Detailed message:
> Error: No instances are allowed in the image heap for a class that is
> initialized or reinitialized at image runtime:
> java.util.logging.SimpleFormatter
> Trace: object java.util.logging.ConsoleHandler
> object java.lang.Object[]
> object java.util.concurrent.CopyOnWriteArrayList
> object java.util.logging.LogManager$RootLogger
> object java.util.logging.Logger
> object org.apache.juli.logging.DirectJDKLog
> method
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
> Object, boolean)
> Call path from entry point to
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
> Object, boolean):
> at
>
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:390)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:193)
> at org.apache.catalina.startup.Tomcat.start(Tomcat.java:455)
> at org.apache.catalina.startup.Tomcat.main(Tomcat.java:1444)
> at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:152)
> at
>
> com.oracle.svm.core.code.IsolateEnterStub.JavaMainWrapper_run_5087f5482cc9a6abc971913ece43acb471d2631b(generated:0)
>
> If you want to work on this, you can (git makes it easy) but it looks a bit
> daunting at this point (java.util.logging is not supported either ? this is
> not documented at
> https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md ).
>
> Rémy
>

Re: Becoming graalvm friendly?

[Rémy Maucherat]

On Wed, Mar 20, 2019 at 4:45 PM Romain Manni-Bucau 
wrote:

> Most of the time monitoring is done through a custom exporter in practise
> based on other impl - sigar, library integration like
> hibernate/eclipselinks ones, metrics, microprofile etc... -  and JMX is not
> then used - not judging it is good, bad, lack of knowledge or not, just
> saying what i see.
> Now I'm happy if JMX is made graal compatible. From what I saw, mainly the
> MBeanServer and Notifier (through the hierarchy it goes until that point in
> the JVM in standard mbeans) are blocking the compilation. I'm pretty sure
> these parts of Tomcat can be extracted in a particular class and then
> substrated which would make it graal compatible probably.
>

Ok, so I had a (quick) look, and this doesn't seem to be something that is
adapted to Tomcat at this time.

Steps:
- I built the embedded packaging here
https://github.com/apache/tomcat/tree/master/res/tomcat-maven
- It produces a standalone jar in target/tomcat-maven-1.0.jar
- Une the graal tool $GRAALVM/bin/native-image -jar
target/tomcat-maven-1.0.jar

Produces:
Error: No instances are allowed in the image heap for a class that is
initialized or reinitialized at image runtime:
java.util.logging.SimpleFormatter
Detailed message:
Error: No instances are allowed in the image heap for a class that is
initialized or reinitialized at image runtime:
java.util.logging.SimpleFormatter
Trace: object java.util.logging.ConsoleHandler
object java.lang.Object[]
object java.util.concurrent.CopyOnWriteArrayList
object java.util.logging.LogManager$RootLogger
object java.util.logging.Logger
object org.apache.juli.logging.DirectJDKLog
method
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
Object, boolean)
Call path from entry point to
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleState,
Object, boolean):
at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:390)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:193)
at org.apache.catalina.startup.Tomcat.start(Tomcat.java:455)
at org.apache.catalina.startup.Tomcat.main(Tomcat.java:1444)
at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:152)
at
com.oracle.svm.core.code.IsolateEnterStub.JavaMainWrapper_run_5087f5482cc9a6abc971913ece43acb471d2631b(generated:0)

If you want to work on this, you can (git makes it easy) but it looks a bit
daunting at this point (java.util.logging is not supported either ? this is
not documented at
https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md ).

Rémy

Re: Becoming graalvm friendly?

[Romain Manni-Bucau]

Le mer. 20 mars 2019 à 15:06, Rémy Maucherat  a écrit :

> On Tue, Mar 19, 2019 at 4:52 PM Romain Manni-Bucau 
> wrote:
>
> > Hi Rémy, well there are two topics here:
> >
> > 1. how to run tomcat without all that JMX stuff - in Meecrowave for
> > instance we deactivate it by default since in 80% of the usages it is not
> > used - so I think it is a valid option to make it easily deactivable and
> if
> > done well enough it would be easy to "subtrate" the code through svm
> (from
> > graal project) which enable to kind of monkey patch an app (so it should
> be
> > very localized otherwise the maintenance is just hell)
> >
>
> JMX does all the Tomcat monitoring (JVM + container), including also the
> monitoring in cloud environments (with Jolokia and Prometheus). So it is
> difficult for me to understand why it's a such good idea for users to
> remove it. It's quite a bit of work too.
>

Most of the time monitoring is done through a custom exporter in practise
based on other impl - sigar, library integration like
hibernate/eclipselinks ones, metrics, microprofile etc... -  and JMX is not
then used - not judging it is good, bad, lack of knowledge or not, just
saying what i see.
Now I'm happy if JMX is made graal compatible. From what I saw, mainly the
MBeanServer and Notifier (through the hierarchy it goes until that point in
the JVM in standard mbeans) are blocking the compilation. I'm pretty sure
these parts of Tomcat can be extracted in a particular class and then
substrated which would make it graal compatible probably.



>
>
> > 2. graalvm will get more and more support for these parts but I guess
> > tomcat could be less coupled to JMX - in terms of code path - which would
> > also solve the issue.
> >
> > Finally on the url handler part, it is plain useless in native mode so
> > being able to move that URL.setXXX in a static class we would substrate
> by
> > a noop can be worth it too.
> >
> > Hope it makes some sense.
> >
>
> Rémy
>
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mar. 19 mars 2019 à 16:38, Rémy Maucherat  a écrit :
> >
> > > On Sun, Mar 10, 2019 at 6:24 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Hi guys,
> > > >
> > > > Anyone got a look to graalvm native-image tool?
> > > > Tomcat does not work OOTB due to its JMX wide usage - all is not
> > > > implemented in graalvm native scope. That said most of this code is
> not
> > > > really used by Tomcat and can be dropped while keeping Tomcat - at
> > least
> > > > embedded - running. The other hit issue is the URL handler usage.
> > > >
> > > > So concretely - and without entering into the details at that early
> > > stage,
> > > > ensuring TomcatURLStreamHandlerFactory does not use URL custom
> factory
> > > > registration (constructor) and Registry/MBeanUtils don't rely on
> > > > MBeanServer loading directly would be a first step to be able native
> > > > images. To test it I @Substitute them with substrate API but it
> > requires
> > > to
> > > > fork some part of Tomcat which is not desired at all on my side.
> > > >
> > > > This is just the first step since, if you want to keep all features,
> > you
> > > > will need to create a json with the reflection metadata for some
> > features
> > > > but at least these two "changes" would enable to run native-image
> > > > successfully.
> > > >
> > > > Overall this mail does not intend to speak of "fix" yet but only
> mainly
> > > > intend to ask two questions:
> > > >
> > > > 1. any existing status on graalvm native image support I would have
> > > missed?
> > > > 2. any will to work in that direction in the community? (graalvm is
> > still
> > > > very young and lack several features to really embrace java ecosystem
> > so
> > > > can be fair to say "later")
> > > >
> > >
> > > Well, the said features are quite useful/nice/etc, and I haven't been
> > > looking at native images. Any real concrete plan to improve things
> > without
> > > removing useful items ?
> > >
> > > Rémy
> > >
> >
>

Re: Becoming graalvm friendly?

[Rémy Maucherat]

On Tue, Mar 19, 2019 at 4:52 PM Romain Manni-Bucau 
wrote:

> Hi Rémy, well there are two topics here:
>
> 1. how to run tomcat without all that JMX stuff - in Meecrowave for
> instance we deactivate it by default since in 80% of the usages it is not
> used - so I think it is a valid option to make it easily deactivable and if
> done well enough it would be easy to "subtrate" the code through svm (from
> graal project) which enable to kind of monkey patch an app (so it should be
> very localized otherwise the maintenance is just hell)
>

JMX does all the Tomcat monitoring (JVM + container), including also the
monitoring in cloud environments (with Jolokia and Prometheus). So it is
difficult for me to understand why it's a such good idea for users to
remove it. It's quite a bit of work too.


> 2. graalvm will get more and more support for these parts but I guess
> tomcat could be less coupled to JMX - in terms of code path - which would
> also solve the issue.
>
> Finally on the url handler part, it is plain useless in native mode so
> being able to move that URL.setXXX in a static class we would substrate by
> a noop can be worth it too.
>
> Hope it makes some sense.
>

Rémy

>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 19 mars 2019 à 16:38, Rémy Maucherat  a écrit :
>
> > On Sun, Mar 10, 2019 at 6:24 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Hi guys,
> > >
> > > Anyone got a look to graalvm native-image tool?
> > > Tomcat does not work OOTB due to its JMX wide usage - all is not
> > > implemented in graalvm native scope. That said most of this code is not
> > > really used by Tomcat and can be dropped while keeping Tomcat - at
> least
> > > embedded - running. The other hit issue is the URL handler usage.
> > >
> > > So concretely - and without entering into the details at that early
> > stage,
> > > ensuring TomcatURLStreamHandlerFactory does not use URL custom factory
> > > registration (constructor) and Registry/MBeanUtils don't rely on
> > > MBeanServer loading directly would be a first step to be able native
> > > images. To test it I @Substitute them with substrate API but it
> requires
> > to
> > > fork some part of Tomcat which is not desired at all on my side.
> > >
> > > This is just the first step since, if you want to keep all features,
> you
> > > will need to create a json with the reflection metadata for some
> features
> > > but at least these two "changes" would enable to run native-image
> > > successfully.
> > >
> > > Overall this mail does not intend to speak of "fix" yet but only mainly
> > > intend to ask two questions:
> > >
> > > 1. any existing status on graalvm native image support I would have
> > missed?
> > > 2. any will to work in that direction in the community? (graalvm is
> still
> > > very young and lack several features to really embrace java ecosystem
> so
> > > can be fair to say "later")
> > >
> >
> > Well, the said features are quite useful/nice/etc, and I haven't been
> > looking at native images. Any real concrete plan to improve things
> without
> > removing useful items ?
> >
> > Rémy
> >
>

Re: Becoming graalvm friendly?

[Romain Manni-Bucau]

Hi Rémy, well there are two topics here:

1. how to run tomcat without all that JMX stuff - in Meecrowave for
instance we deactivate it by default since in 80% of the usages it is not
used - so I think it is a valid option to make it easily deactivable and if
done well enough it would be easy to "subtrate" the code through svm (from
graal project) which enable to kind of monkey patch an app (so it should be
very localized otherwise the maintenance is just hell)
2. graalvm will get more and more support for these parts but I guess
tomcat could be less coupled to JMX - in terms of code path - which would
also solve the issue.

Finally on the url handler part, it is plain useless in native mode so
being able to move that URL.setXXX in a static class we would substrate by
a noop can be worth it too.

Hope it makes some sense.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 19 mars 2019 à 16:38, Rémy Maucherat  a écrit :

> On Sun, Mar 10, 2019 at 6:24 PM Romain Manni-Bucau 
> wrote:
>
> > Hi guys,
> >
> > Anyone got a look to graalvm native-image tool?
> > Tomcat does not work OOTB due to its JMX wide usage - all is not
> > implemented in graalvm native scope. That said most of this code is not
> > really used by Tomcat and can be dropped while keeping Tomcat - at least
> > embedded - running. The other hit issue is the URL handler usage.
> >
> > So concretely - and without entering into the details at that early
> stage,
> > ensuring TomcatURLStreamHandlerFactory does not use URL custom factory
> > registration (constructor) and Registry/MBeanUtils don't rely on
> > MBeanServer loading directly would be a first step to be able native
> > images. To test it I @Substitute them with substrate API but it requires
> to
> > fork some part of Tomcat which is not desired at all on my side.
> >
> > This is just the first step since, if you want to keep all features, you
> > will need to create a json with the reflection metadata for some features
> > but at least these two "changes" would enable to run native-image
> > successfully.
> >
> > Overall this mail does not intend to speak of "fix" yet but only mainly
> > intend to ask two questions:
> >
> > 1. any existing status on graalvm native image support I would have
> missed?
> > 2. any will to work in that direction in the community? (graalvm is still
> > very young and lack several features to really embrace java ecosystem so
> > can be fair to say "later")
> >
>
> Well, the said features are quite useful/nice/etc, and I haven't been
> looking at native images. Any real concrete plan to improve things without
> removing useful items ?
>
> Rémy
>

Re: Becoming graalvm friendly?

[Rémy Maucherat]

On Sun, Mar 10, 2019 at 6:24 PM Romain Manni-Bucau 
wrote:

> Hi guys,
>
> Anyone got a look to graalvm native-image tool?
> Tomcat does not work OOTB due to its JMX wide usage - all is not
> implemented in graalvm native scope. That said most of this code is not
> really used by Tomcat and can be dropped while keeping Tomcat - at least
> embedded - running. The other hit issue is the URL handler usage.
>
> So concretely - and without entering into the details at that early stage,
> ensuring TomcatURLStreamHandlerFactory does not use URL custom factory
> registration (constructor) and Registry/MBeanUtils don't rely on
> MBeanServer loading directly would be a first step to be able native
> images. To test it I @Substitute them with substrate API but it requires to
> fork some part of Tomcat which is not desired at all on my side.
>
> This is just the first step since, if you want to keep all features, you
> will need to create a json with the reflection metadata for some features
> but at least these two "changes" would enable to run native-image
> successfully.
>
> Overall this mail does not intend to speak of "fix" yet but only mainly
> intend to ask two questions:
>
> 1. any existing status on graalvm native image support I would have missed?
> 2. any will to work in that direction in the community? (graalvm is still
> very young and lack several features to really embrace java ecosystem so
> can be fair to say "later")
>

Well, the said features are quite useful/nice/etc, and I haven't been
looking at native images. Any real concrete plan to improve things without
removing useful items ?

Rémy

Becoming graalvm friendly?

[Romain Manni-Bucau]

Hi guys,

Anyone got a look to graalvm native-image tool?
Tomcat does not work OOTB due to its JMX wide usage - all is not
implemented in graalvm native scope. That said most of this code is not
really used by Tomcat and can be dropped while keeping Tomcat - at least
embedded - running. The other hit issue is the URL handler usage.

So concretely - and without entering into the details at that early stage,
ensuring TomcatURLStreamHandlerFactory does not use URL custom factory
registration (constructor) and Registry/MBeanUtils don't rely on
MBeanServer loading directly would be a first step to be able native
images. To test it I @Substitute them with substrate API but it requires to
fork some part of Tomcat which is not desired at all on my side.

This is just the first step since, if you want to keep all features, you
will need to create a json with the reflection metadata for some features
but at least these two "changes" would enable to run native-image
successfully.

Overall this mail does not intend to speak of "fix" yet but only mainly
intend to ask two questions:

1. any existing status on graalvm native image support I would have missed?
2. any will to work in that direction in the community? (graalvm is still
very young and lack several features to really embrace java ecosystem so
can be fair to say "later")


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book