[Paper Review] Let's Annotate to Let Our Code Run in Parallel

Patrizio Dazzi|arXiv (Cornell University)|Jun 6, 2013

Parallel Computing and Optimization Techniques18 references3 citations

TL;DR

This paper proposes a load-time, annotation-based approach to automatically transform sequential Java programs into parallel, multithreaded code using Java annotations. By marking methods with @Parallel, the system generates futures and restructures bytecode at runtime based on target architecture, achieving negligible overhead and low programmer effort for embarrassingly parallel workloads like Mandelbrot set computation.

ABSTRACT

This paper presents an approach that exploits Java annotations to provide meta information needed to automatically transform plain Java programs into parallel code that can be run on multicore workstation. Programmers just need to decorate the methods that will eventually be executed in parallel with standard Java annotations. Annotations are automatically processed at launch-time and parallel byte code is derived. Once in execution the program automatically retrieves the information about the executing platform and evaluates the information specified inside the annotations to transform the byte-code into a semantically equivalent multithreaded version, depending on the target architecture features. The results returned by the annotated methods, when invoked, are futures with a wait-by-necessity semantics.

Motivation & Objective

• To reduce the complexity of developing parallel applications on multicore systems by leveraging programmer knowledge for task decomposition.
• To enable automatic transformation of sequential Java code into semantically equivalent parallel code at load time.
• To preserve backward compatibility by allowing sequential execution when annotations are ignored.
• To optimize parallel execution based on runtime platform information and user-specified non-functional requirements.
• To minimize performance overhead while supporting both shared-memory and distributed execution models.

Proposed method

• Programmers annotate methods with @Parallel to indicate parts of code to be executed asynchronously.
• The system processes annotations at load time using reflection and transforms the intermediate language (IL) of the bytecode.
• Asynchronous execution is implemented using futures with wait-by-necessity semantics, enabling non-blocking computation.
• The transformation dynamically adapts to target architecture features, such as processor count and memory layout.
• The approach operates at the IL level, avoiding recompilation and reducing runtime overhead compared to source-level transformations.
• The prototype supports both local multicore execution and remote method invocation (RMI) for distributed parallelism.

Experimental results

Research questions

• RQ1 Can programmer-provided annotations at the source code level effectively guide automatic parallelization without requiring deep changes to application logic?
• RQ2 Does load-time bytecode transformation based on runtime platform information lead to efficient and scalable parallel execution?
• RQ3 What is the performance overhead of using annotations and futures compared to native sequential execution?
• RQ4 Can the same annotation-based approach support both shared-memory and distributed (grid/cloud) execution environments?
• RQ5 How does the approach compare to existing skeletons or RMI-based systems in terms of programmer effort and runtime efficiency?

Key findings

• The prototype demonstrated negligible performance overhead in Mandelbrot set computations across various resolutions and task sizes.
• The approach reduced programmer effort significantly compared to manual parallelization of embarrassingly parallel applications.
• The system preserved backward compatibility, allowing sequential execution when annotations were ignored.
• Load-time transformation enabled dynamic adaptation to target architecture, improving runtime efficiency.
• The use of futures with wait-by-necessity semantics allowed efficient, non-blocking access to results without blocking the main thread.
• The method scaled well with increasing task size and number of processing elements, showing consistent performance gains on multicore workstations.