On 18 May 2017 at 10:33, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote:
On Thu, May 18, 2017 at 10:28 AM, Kabir Khan <kabir.khan(a)jboss.com> wrote:
>
> > 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
I think that only core stuff should need this, as there is where most of
contention for class loading is.
As all extension need classes from core it is most contested.
So I think if we go with this, jdk + core would be the yield best work /
benefit results
Be it first boot or deployment, I agree that what matters most is the
time to have the deployed application running & responding.
So it would be nice if such a technique could be automated and made
generic, to see if other components can benefit from such an approach
at minimal maintenance overhead.
Incidentally I'm mostly bothered by Hibernate being slow to boot, but
I don't think this particular optimisation would help.
Our bootstrap isn't concurrent; there's just a lot to load -
sequentially - and possibly scanning a combination of classpaths for
discovery of entities & services; hopefully we can improve this by
narrowing down the scope to be scanned but that's clearly an
orthogonal issue.
Thanks,
Sanne