Integration of aspect-oriented approach means in object-oriented programming language

This article presents the first memory allocation scheme for embedded systems having a scratch-pad memory whose size is unknown at compile time. A scratch-pad memory (SPM) is a fast compiler-managed SRAM that replaces the hardware-managed cache. All existing memory allocation schemes for SPM require the SPM size to be known at compile time. Unfortunately, because of this constraint, the resulting executable is tied to that size of SPM and is not portable to other processor implementations having a different SPM size. Size-portable code is valuable when programs are downloaded during deployment either via a network or portable media. Code downloads are used for fixing bugs or for enhancing functionality. The presence of different SPM sizes in different devices is common because of the evolution in VLSI technology across years. The result is that SPM cannot be used in such situations with downloaded codes. To overcome this limitation, our work presents a compiler method whose resulting executable is portable across SPMs of any size. Our technique is to employ a customized installer software, which decides the SPM allocation just before the program's first run, since the SPM size can be discovered at that time. The installer then, based on the decided allocation, modifies the program executable accordingly. The resulting executable places frequently used objects in SPM, considering both code and data for placement. To keep the overhead low, much of the preprocessing for the allocation is done at compile time. Results show that our benchmarks average a 41% speedup versus an all-DRAM allocation, while the optimal static allocation scheme, which knows the SPM size at compile time and is thus an unachievable upper-bound and is only slightly faster (45% faster than all-DRAM). Results also show that the overhead from our customized installer averages about 1.5% in code size, 2% in runtime, and 3% in compile time for our benchmarks.

The traditional tradeoff when performing dynamic compilation is that of fast compilation time versus fast code performance. Most dynamic compilation systems for Java perform selective compilation and/or optimization at a method granularity. This is the not the optimal granularity level. However, compiling at a sub-method granularity is thought to be too complicated to be practical. This paper describes a straightforward technique for performing compilation and optimizations at a finer, sub-method granularity. We utilize dynamic profile data to determine intra-method code regions that are rarely or never executed, and compile and optimize the code without those regions. If a branch that was predicted to be rare is actually taken at run time, we fall back to the interpreter or dynamically compile another version of the code. By avoiding compiling and optimizing code that is rarely executed, we are able to decrease compile time significantly, with little to no degradation in performance. Futhermore, ignoring rarely-executed code can open up more optimization opportunities on the common paths. We present two optimizations---partial dead code elimination and rare-path-sensitive pointer and escape analysis---that take advantage of rare path information. Using these optimizations, our technique is able to improve performance beyond the compile time improvements

Our earlier work reported a Threshold Scheduling Method for compile‐time mapping of functional parallism on distributed‐memory systems. The work reported in this paper discusses run‐time issues in efficiently supporting the functional parallism with minimal overheads, through a combination of compile‐time and run‐time ownership analysis.At compile time, the code generation phase determines whether a local copy of a live definition of a variable needed by a task is available on a given processor, through an ownership analysis. In case ownership cannot be resolved at compile time, an appropriate code is generated to perform analysis at run time. The code generation is carried out so that all the processors carry the same copy of the compiled program with the individual processor's code being isolated and the universally owned code being replicated on all processors to minimize run‐time overheads. The run‐time system maintains the static and dynamic ownerships at every processor to avoid communication overhead on ownership information.We demonstrate the approach by incorporating it in the compiler for targeting a parallel functional language, Sisal (streams and iterations in single assignment language), to Intel Touchstone i860 systems. Several benchmarks demonstrate the viability of the approach.

A class of high-performance, low-cost architectures that rely on the ability to predict, at compile time, the order in which shared resources (such as shared memories) will be accessed by the processors is discussed. If this ordering can be predicted at compile time and enforced at run time, then no hardware or software overhead is required for resolving contention for shared resources, and extremely efficient interprocessor communication is possible. Further, no overhead (such as semaphore management) is required for synchronization of the programs running on the component processors. The hardware required to enforce the ordered access of the shared resources is very simple. The result is a very lean multiprocessor architecture with very efficient access to shared resources. A specific example using Motorola DSP96002 processors and a shared memory is described in detail. >

Inline expansion is very important for high performance VLIW, especially for microprocessors with static scheduling. Optimizations in optimizing compilers for VLIW duplicate code aggressively and lead to long compile time. Our inlining algorithm is based on heuristics that takes into account compile time explicitly. This made optimization more balanced and significantly reduced code growth and compile time compared to common inlining approach based on minimization of runtime within constraints. Instead of using hard constraints we are trading run time for compilation time in some proportion. Our heuristics predicts several key optimizations in evaluation of runtime and compile time: code scheduling, global copy propagation, dead code elimination and different loop optimizations. Optimizations prediction reduces the need in profile information which is rarely available in practice. Our implementation of inlining includes cloning, partial inlining and inlining across compilation modules in whole program mode. All this factors make dramatic impact on performance: our inlining implementation in the Elbrus optimizing compiler boost SPEC CPU2006 benchmark performance by factor of 1.41 at the cost of 12% increase of compile time and 7.7% increase of code size on average.

Compilers for current programming languages enforce rigid restrictions on changes, during the compilation of a statement, in the set of associations between names and declarations, that is, on changes in the compile-time environment of the statement. These restrictions inhibit the writing of well-structured, modular programs, because such programs tend to require frequent switching between the environments associated with different modules. With current compilers, arbitrary switching of environments must be handled by means of macros at compile time or deferred until run time. Conventional macros are difficult to use in situations where it is desirable that the macro writer and the macro user be ignorant about each other's programs. When deferred until run time, frequent switching of environments becomes costly owing to the overhead associated with subroutine calls. In order to encourage the compartmentalization of program information and at the same time to allow efficient code generation, we propose the relaxation of present restrictions on changes in the compile-time environment. Specifically, we propose that a group of declarations can be defined as an environment and that arbitrary pieces of program text can state within which environment they are to be compiled. With such a mechanism, program text can be intermixed by means of macros without having to make the relevant declarations global or having to repeat the declarations in places other than the environment's definition.

Index refinements (or dependent types over a restricted domain) enable the expression of many desirable invariants that can be verified at compile time. We propose to incorporate a system of index refinements in a small, class-based, imperative, object-oriented language. While rooted in techniques formulated for dependently-typed functional languages, our type system is able to capture more than just value properties and pure computations. Index refinements, combined with a notion of pre- and post-type to track state, give programmers the ability to reason about effectful computations. Our type system distinguishes between two classes of objects, imposing an affine discipline to objects whose types are governed by indices, as opposed to conventional objects which can be freely shared. We have designed and implemented an expressive and decidable type system, which we illustrate through a number of examples.

A surprisingly simple Lua compiler—Extended version

DOI: 10.1049/ic:20040206 ISBN: 0 86341 417 6 Location: Edinburgh, UK Conference date: 25 May 2004 Format: PDF Working on large software projects commonly requires software development in teams, which requires a tight interaction within the development team. Usually each developer is responsible for a certain part of the whole system. Therefore, it is necessary to let developers work independently without disturbing their teammates as well as allowing them to share their results with their teammates at a certain time and to integrate the developed software parts. Common practice is to use CASE-tools to support large software projects and a software configuration management (SCM) system that supports team coordination. Popular SCM systems are usually based upon text files and fail in versioning binary files or object-oriented structures on a fine-grained level, as usually produced by CASE-tools. On the other hand, current CASE-tools insufficiently support versioning and team coordination. CoObRA is a framework that offers undo/redo-, persistency-, multi-user-support and version control techniques for applications based on object-oriented data models in general. The major advantage is that it provides an easy-to-use mechanism requiring very low integration costs. CoObRA was successfully integrated in the Fujaba tool suite and is also part of Fujaba's code generation facilities that offer CoObRA's features to applications generated with Fujaba. However, CoObRA may easily be used outside Fujaba, too. Inspec keywords: computer aided software engineering; programming environments; groupware; configuration management; distributed object management; object-oriented programming; software tools Subjects: Software engineering techniques; Object-oriented programming; Programming support; Groupware; Distributed systems software

Efforts to reason formally about programs, and in particular to prove their properties mathematically, have no practical value unless they can handle all the language facilities on which realistic programs depend. It is then not surprising that one of the biggest obstacles to the spread of such correctness-guaranteeing methods has been the lack of a good way to model the highly dynamic nature of the run-time structures created by object-oriented programs — and by most plain C or Pascal programs — with their heavy use of pointers, or references, from object to object. The present discussion proposes a mathematical theory for modeling pointer-rich object structures and proving their properties. The model only uses simple concepts from set theory: sets, relations, functions, composition, restriction, image. For run-time operations all it needs is the notion of event, a function yielding a new program state from an existing one. The model has two principal applications: •T he coarse-grained version of the model, considering only the existence or not of a reference between an object and another, gives a basis for discussing overall properties of the object structure, defining as a result the correctness constraints of memory management and especially garbage collection, full or incremental. Mathematically, this model uses a binary relation. •T he fine-grained version, based on functions which together make up the relation of the coarse-grained version, integrates the properties of individual object fields. As a result, it allows proving the correctness of classes describing structures with luxurious pointer foliage, from linked lists and graphs to B-trees and double-ended queues. This is part of a series of 3 articles. Parts 2 and 3 will be published in the May-June 2003 issue of JOT.

A hierarchical and reflective framework for synchronization and scheduling controls

A lightweight cryptography (LWC) framework to secure memory heap in Internet of Things

Recent tools have been designed to help developers understand the potential runtime structure of objects in a system at compile time. Such tools let developers interactively explore diagrams of object structure. But do developers ask questions about object structure? If so, when?We conducted a small pilot study of developers working on coding tasks designed to require thinking about relationships between objects. Developers did indeed ask a number of questions about various types of relationships such as containment, ownership, object identities and aliasing. Finally, some of our results revealed usability challenges tools should address to more effectively answer these questions.

The three problems of the title — the first two widely discussed in the literature, the third less well known but just as important for further development of object technology — are:– Eradicating the risk of void calls: x.f with, at run time, the target x not denoting any object, leading to an exception and usually a crash.– Eradicating the risk of “catcalls”: erroneous run-time situations, almost inevitably leading to crashes, resulting from the use of covariant argument typing.– Providing a simple way, in concurrent object-oriented programming, to lock an object handled by a remote processor or thread of control, or to access it without locking it, as needed by the context and in a safe way.A language mechanism provides a combined solution to all three issues.This mechanism also allows new solutions to two known problems: how to check that a certain object has a certain type, and then use it accordingly (“Run-Time Type Identification” or “downcasting”), for which it may provide a small improvement over previously proposed techniques; and how to provide a “once per object” facility, permitting just-in-time evaluation of certain object properties.The solution relies on a small extension to the type system involving a single symbol, the question mark. The idea is to declare certain types as “attached” (not permitting void values), enforce some new validity rules that rule out void calls, and validate a number of common programming schemes as “Certified Attachment Patterns” guaranteed to rule out void calls. (In addition, the design replaced an existing type-querying construct by a simpler one.)The mechanism is completely static: all checks can be performed by compilers as part of normal type system enforcement. It places no undue burden on these compilers — in particular, does not require dataflow analysis — and can be fairly quickly explained to programmers. Existing code, if reasonably well-written, will usually continue to work without change; for exceptions to this rule, often reflecting real risks of run-time crashes, backward-compatible options and a clear transition path are available.KeywordsFormal ArgumentValidity RuleProgram TextExpanded TypeCreation InstructionThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Run-time code generation (RTCG) enables program optimizations specific to values that are unknown until run time and improves the performance. This paper shows that object-oriented languages allow RTCG from a simple analysis of source programs. It also proposes an automatic, safe, and efficient RTCG system implemented as a preprocessor of a C++ compiler. It can inline virtual member functions combined with other optimizations. Increases in speed have ranged from 1.2 to 2.3 times.KeywordsSource ProgramIntermediate RepresentationGraphic ObjectInstance VariableMachine CodeThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.