Concurrent Attributes

We are currently adding support for concurrent and parallel evaluation of attributes to JastAdd. A beta implementation is available on the concurrent 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:

--concurrent --safeLazy


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 @Parallel or @ParallelSurvey annotations to the attribute to parallelize the collection and/or survey phase of the attribute evaluation.

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).

Parallel performance

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:

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.