[
https://issues.jboss.org/browse/WFCORE-3466?page=com.atlassian.jira.plugi...
]
Brian Stansberry edited comment on WFCORE-3466 at 12/19/17 6:28 PM:
--------------------------------------------------------------------
Besides eliminating the cost of the Suppliers, we really want to get rid of the loading of
the parser impl Class, and only load it if we actually encounter the namespace that
demands it.
Exception being the current parser, which we often want to load during
Extension.initializeParsers, since in most subsystems that means the subsystem static
initialization stuff (AttributeDefinition etc) gets run during the concurrent part of
boot.
was (Author: brian.stansberry):
Besides eliminating the cost of the Suppliers, we really want to get rid of the loading of
the parser impl Class, and only load it if we actually encounter the namespace that
demands it.
Add reflection option to
org.jboss.as.controller.parsing.ExtensionParsingContext
--------------------------------------------------------------------------------
Key: WFCORE-3466
URL:
https://issues.jboss.org/browse/WFCORE-3466
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: David Lloyd
As a way to combat aggressive class initialization, WFCORE-1841 added a variant method to
{{ExtensionParsingContext}} which allowed a supplier of a parser to be provided.
This has resulted in an explosion of lambda usage; around 150 calls to this method exist,
most of which supply constructor references as the {{Supplier}} argument.
We can theoretically save considerable metaspace by doing one of the following:
* Add a variation of the method which accepts a {{Class}} instead of a {{Supplier}}; it
uses {{Class.newInstance()}} or {{Class.getConstructor().newInstance()}} to instantiate
the parser on demand
* Create a reflective {{Supplier}} implementation which, given a {{Class}}, uses it in
this way to construct instances
Performance impact should be very minimal, as the overhead of calling a constructor is
less than that of compiling a method reference, and the overhead in metaspace is nearly
non-existent in comparison.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)