On May 17, 2017, at 1:42 PM, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
> On May 15, 2017, at 10:04 AM, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote:
>
>
> On Mon, May 15, 2017 at 4:13 PM, Brian Stansberry <brian.stansberry(a)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.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat