Join point

Abstract: The current AspectJ join points represent locations in the code that are the interface of the Java objects. However, not all the "things that happen" happen at the interfaces. In particular, loops are a key place that could be advised for parallelisation. This article presents a loop join point model, which allows AspectJ to intervene directly in loops. More generally, this demonstrates the need for, and provides, a more complex join point in AspectJ.The approach used for recognising loops is based on a control-flow analysis at the bytecode level; this avoids ambiguities due to alternative forms of source-code that would effectively produce identical loops. This model is also enhanced with a mechanism for context exposure, which is pivotal for giving a meaning to the use of this join point, and with additional information through join point reflection. The context exposure is particularly useful for writing pointcuts that select specific loops only, and the problem of loop selection is also presented in the paper.Finally, LoopsAJ, an extension for the abc compiler that provides AspectJ with a loop join point, is presented. It is shown how to use this extension for writing aspects that parallelise loops.

Abstract: In spite of the more advanced modularisation mechanisms, aspect-oriented programs still suffer from evolution problems. Due to the fragile pointcut problem, seemingly safe modifications to the base code of an aspect-oriented program can have an unexpected impact on the semantics of the pointcuts defined in that program. This can lead to broken aspect functionality due to accidental join point misses and unintended join point captures. We tackle this problem by declaring pointcuts in terms of a conceptual model of the base program, rather than defining them directly in terms of how the base program is structured. As such, we achieve an effective decoupling of the pointcuts from the base program's structure. In addition, the conceptual model provides a means to verify where and why potential fragile pointcut conflicts occur, by imposing structural and semantic constraints on the conceptual model, that can be verified when the base program evolves. To validate our approach we implemented a model-based pointcut mechanism, which we used to define some aspects on SmallWiki, a medium-sized application, and subsequently detected and resolved occurrences of the fragile pointcut problem when this application evolved.

Abstract: Scientific software frequently demands high performance in order to execute complex models in acceptable time. A major means of obtaining high performance is via parallel execution on multi-processor systems. However, traditional methods of programming for parallel execution can lead to substantial code-tangling where the needs of the mathematical model crosscut with the concern of parallel execution.Aspect-Oriented Programming is an attractive technology for solving the problem of code-tangling in high performance parallel scientific software. The underlying mathematical model and the parallelism can be treated as separate concerns and programmed accordingly. Their elements of code can then be woven together to produce the final application. This paper investigates the extent to which AspectJ technology can be used to achieve the desired separation of concerns in programs from the Java Grande Forum benchmark suite, a set of test applications for evaluation of the performance of Java in the context of numerical computation. The paper analyses three different benchmark programs and classifies the degrees of difficulty in separating concerns within them in a form suitable for AspectJ. This leads to an assessment of the influence of the design of a numerical application on the ability of AspectJ to solve this kind of code-tangling problem. It is concluded that: (1) scientific software is rarely produced in true object-oriented style; and (2) the inherent loop structure of many scientific algorithms is incompatible with the join point philosophy of AspectJ.Since AspectJ cannot intercept the iterations of for-loops (which are at the heart of high-performance computing), various object-oriented models are proposed for describing (embarrassingly parallel) rectangular double-nested forloops that make it possible to use AspectJ for encapsulating parallelisation in an aspect. Finally, a test-case using these models is presented, together with performance results obtained on various Java Virtual Machines.

Abstract: A system is described, useful in a multiple operand stream, or parallel, data processing system, for detecting the specification of independent tasks which can be operated upon in parallel. The specification of the independent parallel operable tasks is given by a fork instruction specifying the number of tasks and the physical or logical function to be performed for the task. A fork point can therefore be visualized as a logical node point where a given class of physical or logical tasks is undertaken. There is control apparatus associated with each node point. The control apparatus is a resource distributor-manager and also a controller into which each system resource reports when it has become free from whatever other task it was performing. The control apparatus dynamically allocates resources to the tasks in the fork on an as-available basis. The fork ends at a join point where data from the parallel tasks is coordinated. In one embodiment, the processor which initiated the fork may reach the join point, and apparatus is provided which gives this processor the options to wait for all tasks to be completed and coordinate data itself; to become one of the fork processors and help out by taking on an undistributed task, if one or more tasks remain undistributed; or to abort, for example under priority interrupt, and go to another job leaving the data to be coordinated by another processor in the system. The control apparatus includes subsystems, each comprising first and second queueing means, the first queueing means for queueing fork instructions as they are issued, and second queueing means for allowing the control of a plurality of fork instructions at a given time.