]
Ales Justin updated WELD-53:
----------------------------
Fix Version/s: 1.2.0.Beta1
(was: 1.1.1.Final)
Refactor reflection layer to be less of a memory hog
----------------------------------------------------
Key: WELD-53
URL:
https://issues.jboss.org/browse/WELD-53
Project: Weld
Issue Type: Feature Request
Components: Resolution (Typesafe and by Name)
Reporter: Pete Muir
Priority: Blocker
Fix For: 1.2.0.Beta1
Currently the reflection layer stores too much information, meaning we waste valuable
heap space. This comes about because we build "extended metadata" for every
deployed class; however we don't need this extended metadata for every class, and we
also only need it at boot time. Therefore the proposed redesign looks like:
1) Create lightweight AnnotatedType implementations (work done, see
https://github.com/pmuir/weld-core/tree/WELD-13_initial_slim)
2) Use these to fire the ProcessAnnotatedType events as needed (using the
"backed" annotated impls)
2a) If the annotated type is unchanged, keep the backed annotated impl. This is the
annotated impl that will be kept around at runtime, and is designed to be as slimline as
possible for mem usage, delegating everything possible to existing objects
2b) If the annotated type is changed, wrap it in an "unbacked" annotated type.
This may seem unecessary, however it does mean we are providing a consistent view for
debugging, error reporting etc.
3) If a bean is required for the AnnotatedType, load extended metadata for it.
3a) This should be pluggable by the container, allowing something like jandex to be used
if desired
3b) I would propose we use a Map like structure on load, so that the api looks like:
ExtendedAnnotatedType ExtendedMetadataLoader.load(AnnotatedType type);
3c) This extended metadata should include all the rich information available today on
WeldClass and co, including stuff like being able to load methods by parameter
annotations, meta-annotation support etc.
3d) Beans are created, using the extended metadata
3e) this extended metadata should have no references to it after bootstrap, allowing it
to be removed at next gc run
Notes:
* Creating a parallel hierarchy of classes is not possible whilst preserving
immutability, so extended metadata objects are not linked to each other, you traverse the
graph using annotated type impls
--
This message is automatically generated by JIRA.
For more information on JIRA, see: