[weld-issues] [JBoss JIRA] (WELD-53) Refactor reflection layer to be less of a memory hog

[Jozef Hartinger (JIRA)]

     [ https://issues.jboss.org/browse/WELD-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger resolved WELD-53.
---------------------------------

         Assignee: Jozef Hartinger
    Fix Version/s: 2.0.0.Alpha2
                       (was: 1.2.0.Beta1)
       Resolution: Done

    
> 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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira