3:45 p.m.
On May 17, 2017, at 3:29 PM, Jason Greene
<jason.greene(a)redhat.com> wrote:
> 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.
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.
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat