[wildfly-dev] Speeding up WildFly boot time

[Kabir Khan]

> On 17 May 2017, at 22:45, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> 
>> On May 17, 2017, at 3:29 PM, Jason Greene <jason.greene at redhat.com> wrote:
>> 
>> 
>>> On May 17, 2017, at 1:42 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>> 
>>> 
>>>> On May 15, 2017, at 10:04 AM, Tomaž Cerar <tomaz.cerar at gmail.com> wrote:
>>>> 
>>>> 
>>>> On Mon, May 15, 2017 at 4:13 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>> So why does adding two more make such a big difference?
>>>> 
>>>> Main reason is that this two threads load most of later required classes which can later be quickly loaded from multiple parallel threads.
>>>> 
>>>> Currently concurrency causes that 8 -16 threads (on 4-8 logical core systems) try to load same classes at same time.
>>>> this leads to lots of contention as result. "preloading" some of this classes reduces contention.
>>>> 
>>>> Looking at the list in the current "hack impl" there are lots of classes that don't need to be there, stuff like subsystem parsers which are only loaded once in any case.
>>>> 
>>>> Main pressure is on classes from jboss-modules, controller, server & xml parsers modules, all others are not as problematic.
>>>> This is also reason why lots of contention is happening on JDK classes as well as those are shared between all parts of server code.
>>>> 
>>> 
>>> Stuart/Tomaz — 
>>> 
>>> Please ignore this for now if your thinking has moved on to other approaches, e.g. better concurrency in classloading. :)
>>> 
>>> Otherwise, are there any numbers on this last point Tomaz made?
>>> 
>>> I ask because people are asking for a static list since a dynamic list is of no benefit to cloud use cases.
>>> 
>>> A static list is painful to administer though, and if not administered well can result in loading unneeded classes and wasting memory.
>>> 
>>> But, a static list limited to modules that are part of the WildFly Core kernel is not particularly hard to administer. So if we can get the bulk of the gains with the minimum of the pain, we might consider that.
>>> 
>> 
>> We can also just have a dynamic offline list generation, which is ran as a build task. 
> 
> Yes, that’s my assumption. When I say “static” I mean static on a given installation.
> 
> If it is limited to the kernel (including relevant JDK bits), then there are no issues with ensuring different feature pack maintainers are doing this, no need to combine lists from different parts of the build, no worries about ensuring only those bits relevant to what the user is actually running are loaded, etc.  Those things are the “painful to administer part”. They might very well be worth it but data should demonstrate that.
If it turns out to be worth it, the feature pack generation stuff could be enhanced to generate the list for each config. Perhaps only if doing -Prelease so we don't slow down everybody's builds while developing
> 
> -- 
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
> 
> 
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev