Uploaded image for project: 'Weld'
  1. Weld
  2. WELD-53

Refactor reflection layer to be less of a memory hog

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Done
    • Icon: Blocker Blocker
    • 2.0.0.Alpha2
    • None
    • Resolution
    • None

      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

              rhn-engineering-jharting Jozef Hartinger
              pmuiratbleepbleep Pete Muir (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: