[
https://issues.jboss.org/browse/WELD-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ales Justin updated WELD-53:
----------------------------
Fix Version/s: 1.2.0.Beta1
(was: 1.1.6.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.
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
_______________________________________________
weld-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-issues
