[
https://issues.jboss.org/browse/WELD-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pete Muir updated WELD-53:
--------------------------
Summary: Refactor reflection layer to be less of a memory hog (was:
Full review of built in Reflection layer)
Priority: Blocker (was: Major)
Description:
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
was:
A few things:
* should we use javassist?
* need a full review of how we deal with Annotated*
> 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: http://www.atlassian.com/software/jira
_______________________________________________
weld-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-issues
