We are currently adding support for concurrent and parallel evaluation of
attributes to JastAdd. A beta implementation is available on the
branch in the JastAdd Git repository.
For concurrent attributes it is very important that there are no side effects in attribute equations. For JastAdd projects that are absolutely side effect free it should be possible to seamlessly switch to the concurrent attribute code generator.
Concurrent attributes can be enabled by adding the following flags to the JastAdd command:
The old rewrite mechanism can not be used together with concurrent attributes,
so when concurrent attributes are used JastAdd automatically switches to the
Circular NTA rewrite implementation. If you use rewrites in your project and
want to try the concurrent attributes you should first try to compile with the
--rewrite=cnta --safeLazy flags to ensure that your project works with
Circular NTA rewrites.
Parallelization can be added either by calling attribute methods from different
threads, or by using parallel collection attributes. Collection attributes can
be parallelized by adding the
@ParallelSurvey annotations to
the attribute to parallelize the collection and/or survey phase of the
Parallel collection attributes are implemented by using a thread pool of threads to walk the AST (in the survey phase) and to evaluate contributions (in the collection phase).
In order to make attributes thread safe caching has become more costly, in particular these attributes are extra costly to memoize with the concurrent code generator:
- Parameterized attributes
- Circular attributes
The change in caching cost changes the trade-off between using memoized and non-memoized attributes. To get the best performance it is necessary to reconfigure attribute cache declarations. For small attributes with short evaluation should mostly not be cached, and large attributes with long evaluation times should mostly be cached. However, it depends on how often the attribute is evaluated too: a long-running attribute that is only evaluated once should not be cached.
For most JastAdd projects, switching to concurrent attributes and using parallel evaluation may not pay off directly. It may even be difficult to gain a performance advantage after refactoring with parallel evaluation in mind, however if a project is designed from the start for parallel evaluation it should be possible to make a system with higher throughput than is possible in the single-threaded non-concurrent case.
ExtendJ is currently undergoing refactoring to use parallel attribute evaluation. The goal is to make the parallel version of ExtendJ faster than the single-threaded version, however right now it runs slower. A major hurdle to make ExtendJ work with concurrent attributes was to remove side effects in the attribute evaluation.