JaMoPP can parse Java source and byte code into EMF-based models and vice versa. It preserves source formatting and can be used for code analysis and refactoring.
Currently, everytime a JavaContextDependentURIFragmentFactory is required a new instance is created in the JaMoPP code.
This leads to a new Factory for each URIFragement during code parsing.
A code review showd that the typed JavaContextDependentURIFragmentFactory is thread safe due to it's stateless processing.
A single instance per type could be used.
JavaParser
In the current implementation, new instances are created for each method call, for example of the parse methods of the JavaParser.
For example in parse_org_emftext_language_java_annotations_AnnotationAttributeSetting() each method invocation creates a new JavaContextDependentURIFragmentFactory instance:
The typed JavaContextDependentURIFragmentFactory is always the same for a specific parse method and could be instantiated per JavaParser instance.
getReferenceResolverSwitch() always return the same switch instance provided by the metaInformation which is not null and the same for each ParserInstance. (see DevBoost/JaMoPP#16)
This allows to simplify the instantiation of the typed JavaContextDependentURIFragmentFactory per JavaParser instance.
JavaContextDependentURIFragmentFactory
Another code location instantiating JavaContextDependentURIFragmentFactory instances is in JavaResourcePostProcessor.
This can also be optimized by using a single instance of this factory per JavaResourcePostProcessor instance.
Optimization Result
The modifications lead to a static number of factory instances, independend of the number of processed java elements.
With the ArgoUML SPLevo/KoPL case study, this is more than 0.5 billion object instances (increasing, total number not available because parsing not possible yet).
Background
Currently, everytime a JavaContextDependentURIFragmentFactory is required a new instance is created in the JaMoPP code. This leads to a new Factory for each URIFragement during code parsing.
A code review showd that the typed JavaContextDependentURIFragmentFactory is thread safe due to it's stateless processing. A single instance per type could be used.
JavaParser
In the current implementation, new instances are created for each method call, for example of the parse methods of the JavaParser.
For example in
parse_org_emftext_language_java_annotations_AnnotationAttributeSetting()each method invocation creates a new JavaContextDependentURIFragmentFactory instance:The typed JavaContextDependentURIFragmentFactory is always the same for a specific parse method and could be instantiated per JavaParser instance.
getReferenceResolverSwitch() always return the same switch instance provided by the metaInformation which is not null and the same for each ParserInstance. (see DevBoost/JaMoPP#16) This allows to simplify the instantiation of the typed JavaContextDependentURIFragmentFactory per JavaParser instance.
JavaContextDependentURIFragmentFactory
Another code location instantiating JavaContextDependentURIFragmentFactory instances is in JavaResourcePostProcessor. This can also be optimized by using a single instance of this factory per JavaResourcePostProcessor instance.
Optimization Result
The modifications lead to a static number of factory instances, independend of the number of processed java elements. With the ArgoUML SPLevo/KoPL case study, this is more than 0.5 billion object instances (increasing, total number not available because parsing not possible yet).