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 Assignee: Jozef Hartinger Priority: Blocker Fix For: 2.0.0.Alpha2 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