Context: As discussed in https://github.com/openjdk/leyden/blob/leyden-ea1-release-notes/README.md, Java SE's Project Leyden is doing work to facilitate work shifting from runtime to earlier stages. This might be interesting for WildFly, as we do a lot of work at boot that if it could be done in advance might reduce boot time (particularly with a non-trivial deployed app) enough to allow WildFly to support more use cases, e.g. light-switch-ops type uses where a WildFly server that isn't actually handling requests can be stop, and then quickly started again (by some external process) if requests come in.

WildFly developers are familiar with the huge difference in boot time of a WildFly process when it is 'reloaded' via the management vs a fresh boot. A reload of a server with no deployment takes 200-300ms, while a fresh boot takes 2-3 seconds. (Adding a deployment will result in a different relationship between these figures, and what the relationship is depends on what the deployment does.) The fundamental reason a reload is so fast is that a lot of classloading and static initialization work doesn't get repeated. So, if work shifting techniques like Leyden is working on can move some of that work out of initial boot and into some earlier phase, we may see benefits.

The task is to experiment with Leyden and see what happens:

See '2. Try out Leyden Features' in https://github.com/openjdk/leyden/blob/leyden-ea1-release-notes/README.md.

A simple training run would be to start WildFly, connect a CLI and reload a few times, and then use the CLI to shutdown.

A bit more would be to deploy an app like quickstart kitchensink, connect a CLI and reload a few times, exercise the app a bit, and then use the CLI to shutdown.

Report back some figures here.