|
|
SESSION: Growing Java |
|
|
|
|
The jastadd extensible java compiler |
| |
Torbjörn Ekman,
Görel Hedin
|
|
Pages: 1-18 |
|
doi>10.1145/1297027.1297029 |
|
Full text: PDF
|
|
The JastAdd Extensible Java Compiler is a high quality Java compiler that is easy to extend in order to build static analysis tools for Java, and to extend Java with new language constructs. It is built modularly, with a Java 1.4 compiler that is extended ...
The JastAdd Extensible Java Compiler is a high quality Java compiler that is easy to extend in order to build static analysis tools for Java, and to extend Java with new language constructs. It is built modularly, with a Java 1.4 compiler that is extended to a Java 5 compiler. Example applications that are built as extensions include an alternative backend that generates Jimple, an extension of Java with AspectJ constructs, and the implementation of a pluggable type system for non-null checking and inferenc. The system is implemented using JastAdd, a declarative Java-like language. We describe the compiler architecture, the major design ideas for building and extending the compiler, in particular, for dealing with complex extensions that affect name and type analysis. Our extensible compiler compares very favorably concerning quality, speed and size with other extensible Java compiler frameworks. It also compares favorably in quality and size compared with traditional non-extensible Java compilers, and it runs within a factor of three compared to javac. expand
|
|
|
Session details: Growing Java |
| |
David F. Bacon
|
|
doi>10.1145/3250661 |
|
|
|
|
Jeannie: granting java native interface developers their wishes |
| |
Martin Hirzel,
Robert Grimm
|
|
Pages: 19-38 |
|
doi>10.1145/1297027.1297030 |
|
Full text: PDF
|
|
Higher-level languages interface with lower-level languages such as C to access platform functionality, reuse legacy libraries, or improve performance. This raises the issue of how to best integrate different languages while also reconciling productivity, ...
Higher-level languages interface with lower-level languages such as C to access platform functionality, reuse legacy libraries, or improve performance. This raises the issue of how to best integrate different languages while also reconciling productivity, safety, portability, and efficiency. This paper presents Jeannie, a new language design for integrating Java with C. In Jeannie, both Javaand C code are nested within each other in the same file and compile down to JNI, the Java platform's standard foreign function interface. By combining the two languages' syntax and semantics, Jeannie eliminates verbose boiler-plate code, enables static error detection across the language boundary, and simplifies dynamic resource management. We describe the Jeannie language and its compiler, while also highlighting lessons from composing two mature programming languages. expand
|
|
|
Ilea: inter-language analysis across java and c |
| |
Gang Tan,
Greg Morrisett
|
|
Pages: 39-56 |
|
doi>10.1145/1297027.1297031 |
|
Full text: PDF
|
|
Java bug finders perform static analysis to find implementation mistakes that can lead to exploits and failures; Java compilers perform static analysis for optimization.allIf Java programs contain foreign function calls to C libraries, however, static ...
Java bug finders perform static analysis to find implementation mistakes that can lead to exploits and failures; Java compilers perform static analysis for optimization.allIf Java programs contain foreign function calls to C libraries, however, static analysis is forced to make either optimistic or pessimistic assumptions about the foreign function calls, since models of the C libraries are typically not available. We propose ILEA (stands for Inter-LanguagE Analysis), which is a framework that enables existing Java analyses to understand the behavior of C code. Our framework includes: (1) a novel specification language, which extends the Java Virtual Machine Language (JVML) with a few primitives that approximate the effects that the C code might have; (2) an automatic specification extractor, which builds models of the C code. Comparing to other possible specification languages, our language is expressive, yet facilitates construction of automatic specification extractors. Furthermore, because the specification language is based on the JVML, existing Java analyses can be easily migrated to utilize specifications in the language. We also demonstrate the utility of the specifications generated, by modifying an existing non-null analysis to identify null-related bugs in Java applications that contain C libraries. Our preliminary experiments identified dozens of null-related bugs. expand
|
|
|
SESSION: Runtime techniques/GC |
|
|
|
|
Session details: Runtime techniques/GC |
| |
Cliff Click
|
|
doi>10.1145/3250662 |
|
|
|
|
Statistically rigorous java performance evaluation |
| |
Andy Georges,
Dries Buytaert,
Lieven Eeckhout
|
|
Pages: 57-76 |
|
doi>10.1145/1297027.1297033 |
|
Full text: PDF
|
|
Java performance is far from being trivial to benchmark because it is affected by various factors such as the Java application, its input, the virtual machine, the garbage collector, the heap size, etc. In addition, non-determinism at run-time causes ...
Java performance is far from being trivial to benchmark because it is affected by various factors such as the Java application, its input, the virtual machine, the garbage collector, the heap size, etc. In addition, non-determinism at run-time causes the execution time of a Java program to differ from run to run. There are a number of sources of non-determinism such as Just-In-Time (JIT) compilation and optimization in the virtual machine (VM) driven by timer-based method sampling, thread scheduling, garbage collection, and various. There exist a wide variety of Java performance evaluation methodologies usedby researchers and benchmarkers. These methodologies differ from each other in a number of ways. Some report average performance over a number of runs of the same experiment; others report the best or second best performance observed; yet others report the worst. Some iterate the benchmark multiple times within a single VM invocation; others consider multiple VM invocations and iterate a single benchmark execution; yet others consider multiple VM invocations and iterate the benchmark multiple times. This paper shows that prevalent methodologies can be misleading, and can even lead to incorrect conclusions. The reason is that the data analysis is not statistically rigorous. In this paper, we present a survey of existing Java performance evaluation methodologies and discuss the importance of statistically rigorous data analysis for dealing with non-determinism. We advocate approaches to quantify startup as well as steady-state performance, and, in addition, we provide the JavaStats software to automatically obtain performance numbers in a rigorous manner. Although this paper focuses on Java performance evaluation, many of the issues addressed in this paper also apply to other programming languages and systems that build on a managed runtime system. expand
|
|
|
Microphase: an approach to proactively invoking garbage collection for improved performance |
| |
Feng Xian,
Witawas Srisa-an,
Hong Jiang
|
|
Pages: 77-96 |
|
doi>10.1145/1297027.1297034 |
|
Full text: PDF
|
|
To date, the most commonly used criterion for invoking garbage collection (GC) is based on heap usage; that is, garbage collection is invoked when the heap or an area inside the heap is full. This approach can suffer from two performance shortcomings: ...
To date, the most commonly used criterion for invoking garbage collection (GC) is based on heap usage; that is, garbage collection is invoked when the heap or an area inside the heap is full. This approach can suffer from two performance shortcomings: untimely garbage collection invocations and large volumes of surviving objects. In this work, we explore a new GC triggering approach called MicroPhase that exploits two observations: (i) allocation requests occur in phases and (ii) phase boundaries coincide with times when most objects also die. Thus, proactively invoking garbage collection at these phase boundaries can yield high efficiency. We extended the HotSpot virtual machine from Sun Microsystems to support MicroPhase and conducted experiments using 20 benchmarks. The experimental results indicate that our technique can reduce the GC times in 19 applications. The differences in GC overhead range from an increase of 1% to a decrease of 26% when the heap is set to twice the maximum live-size. As a result, MicroPhase can improve the overall performance of 13 benchmarks. The performance differences range from a degradation of 2.5% to an improvement of 14%. expand
|
|
|
Probabilistic calling context |
| |
Michael D. Bond,
Kathryn S. McKinley
|
|
Pages: 97-112 |
|
doi>10.1145/1297027.1297035 |
|
Full text: PDF
|
|
Calling context enhances program understanding and dynamic analyses by providing a rich representation of program location. Compared to imperative programs, object-oriented programs use more interprocedural and less intraprocedural control flow, ...
Calling context enhances program understanding and dynamic analyses by providing a rich representation of program location. Compared to imperative programs, object-oriented programs use more interprocedural and less intraprocedural control flow, increasing the importance of context sensitivity for analysis. However, prior online methods for computing calling context, such as stack-walking or maintaining the current location in a calling context tree, are expensive in time and space. This paper introduces a new online approach called probabilistic calling context (PCC) that continuously maintains a probabilistically unique value representing the current calling context. For millions of unique contexts, a 32-bit PCC value has few conflicts. Computing the PCC value adds 3% average overhead to a Java virtual machine. PCC is well-suited to clients that detect new or anomalous behavior since PCC values from training and production runs can be compared easily to detect new context-sensitive behavior; clients that query the PCC value at every system call, Java utility call, and Java API call add 0-9% overhead on average. PCC adds space overhead proportional to the distinct contexts stored by the client (one word per context). Our results indicate PCC is efficient and accurate enough to use in deployed software for residual testing, bug detection, and intrusion detection. expand
|
|
|
SESSION: Inheritance and visibility |
|
|
|
|
Session details: Inheritance and visibility |
| |
Yannis Smaragdakis
|
|
doi>10.1145/3250663 |
|
|
|
|
Variant path types for scalable extensibility |
| |
Atsushi Igarashi,
Mirko Viroli
|
|
Pages: 113-132 |
|
doi>10.1145/1297027.1297037 |
|
Full text: PDF
|
|
Much recent work in the design of object-oriented programming languages has been focusing on identifying suitable features to support so-called scalable extensibility, where the usual extension mechanism by inheritance works in different scales ...
Much recent work in the design of object-oriented programming languages has been focusing on identifying suitable features to support so-called scalable extensibility, where the usual extension mechanism by inheritance works in different scales of software components-that is, classes, groups of classes, groups of groups and so on. Its typing issues has usually been addressed by means of dependent type systems, where nested types are seen as properties of objects. In this work, we seek instead for a different solution, which can bemore easily applied to Java-like languages, in which nested types are considered properties of classe. We introduce the mechanism of variant path types, which provide a flexible means to express intra-group relationship (among classes) that has to be preserved through extension. In particular, improving and extending existing works on groups and exact types, we feature the new notions of exact and inexact qualifications, providing rich abstractions to express various kinds of set of objects, with a flexible subtyping scheme. We formalize a safe type system for variant path types on top of Feather weight Java. Our development results in a complete solution for scalable extensibility, similarly to previous attempts based on dependent type systems. expand
|
|
|
Dependent classes |
| |
Vaidas Gasiunas,
Mira Mezini,
Klaus Ostermann
|
|
Pages: 133-152 |
|
doi>10.1145/1297027.1297038 |
|
Full text: PDF
|
|
Virtual classes allow nested classes to be refined in subclasses. In this way nested classes can be seen as dependent abstractions of the objects of the enclosing classes. Expressing dependency via nesting, however, has two limitations: Abstractions ...
Virtual classes allow nested classes to be refined in subclasses. In this way nested classes can be seen as dependent abstractions of the objects of the enclosing classes. Expressing dependency via nesting, however, has two limitations: Abstractions that depend on more than one object cannot be modeled and a class must know all classes that depend on its objects. This paper presents dependent classes, a generalization of virtual classes that expresses similar semantics by parameterization rather than by nesting. This increases expressivity of class variations as well as the flexibility of their modularization. Besides, dependent classes complement multimethods in scenarios where multi-dispatched abstractions rather than multi-dispatched methods are needed. They can also be used to express more precise signatures of multimethods and even extend their dispatch semantics. We present a formal semantics of dependent classes and a machine-checked type soundness proof in Isabelle/HOL [29], the first of this kind for a language with virtual classes and path-dependent types. expand
|
|
|
Component nextgen: a sound and expressive component framework for java |
| |
James Sasitorn,
Robert Cartwright
|
|
Pages: 153-170 |
|
doi>10.1145/1297027.1297039 |
|
Full text: PDF
|
|
Developing a general component system for a statically typed, object-oriented language is a challenging design problem for two reasons. First, mutually recursive references across components are common in object-oriented programs-an issue that has proven ...
Developing a general component system for a statically typed, object-oriented language is a challenging design problem for two reasons. First, mutually recursive references across components are common in object-oriented programs-an issue that has proven troublesome in the context of component systems for functional and procedural languages. Second, inheritance across component boundaries can cause accidental method overrides. Our recent research shows that a component framework can be constructed for a nominally typed object-oriented language supporting first-class generic types simply by adding appropriate annotations, syntactic sugar, and component-level type-checking. The fundamental semantic building blocks for constructing, type-checking and manipulating components are provided by the underlying first-class generic type system. To demonstrate the simplicity and utility of this approach we have designed and implemented an extension of Java called Component NEXTGEN (CGEN). CGEN, which is based on the Sun Java 5.0 javac compiler, is backwards compatible with existing Java binary code and runs on current Java Virtual Machines. The primary contribution of this paper is a technical analysis of the subtle design issues involved in building a component framework for a nominally typed object-oriented language supporting first-class generics. In contrast to component systems for structurally typed languages, mutual recursion among components is accommodated in the type system and semantics without incorporating any special machinery. Our analysis includes a presentation of Core CGEN (CCG), a small, core language modeling the CGEN framework. It is based on Featherweight GJ and incorporates some ideas from MIXGEN. CCG adds the essential features to support components, but nothing more. Our discussion includes the type rules and semantics for CCG, as well as a proof of type safety. expand
|
|
|
User-changeable visibility: resolving unanticipated name clashes in traits |
| |
Stéphane Ducasse,
Roel Wuyts,
Alexandre Bergel,
Oscar Nierstrasz
|
|
Pages: 171-190 |
|
doi>10.1145/1297027.1297040 |
|
Full text: PDF
|
|
A trait is a unit of behaviour that can be composed with other traits and used by classes. Traits offer an alternative to multiple inheritance. Conflict resolution of traits, while flexible, does not completely handle accidental method name conflicts: ...
A trait is a unit of behaviour that can be composed with other traits and used by classes. Traits offer an alternative to multiple inheritance. Conflict resolution of traits, while flexible, does not completely handle accidental method name conflicts: if a trait with method m is composed with another trait defining a different method m then resolving the conflict may prove delicate or infeasible in cases where both versions of m are still needed. In this paper we present freezeable traits, which provide an expressive composition mechanism to support unanticipated method composition conflicts. Our solution introduces private trait methods and lets the class composer change method visibility at composition time (from public to private and vice versa). Moreover two class composers may use different composition policies for the same trait, something which is not possible in mainstream languages. This approach respects the two main design principles of traits: the class composer is empowered and traits can be flattened away. We present an implementation of freezable traits in Smalltalk. As a side-effect of this implementation we introduced private (early-bound and invisible) methods to Smalltalk by distinguishing object-sends from self-sends. Our implementation uses compile-time bytecode manipulation and, as such, introduces no run-time penalties. expand
|
|
|
SESSION: Language design |
|
|
|
|
Session details: Language design |
| |
William Cook
|
|
doi>10.1145/3250664 |
|
|
|
|
Transactions with isolation and cooperation |
| |
Yannis Smaragdakis,
Anthony Kay,
Reimer Behrends,
Michal Young
|
|
Pages: 191-210 |
|
doi>10.1145/1297027.1297042 |
|
Full text: PDF
|
|
We present the TIC (Transactions with Isolation and Cooperation) model for concurrent programming. TIC adds to standard transactional memory the ability for a transaction to observe the effects of other threads at selected points. This allows transactions ...
We present the TIC (Transactions with Isolation and Cooperation) model for concurrent programming. TIC adds to standard transactional memory the ability for a transaction to observe the effects of other threads at selected points. This allows transactions to cooperate, as well as to invoke nonrepeatable or irreversible operations, such as I/O. Cooperating transactions run the danger of exposing intermediate state and of having other threads change the transaction's state. The TIC model protects against unanticipated interference by having the type system keep track of all operations that may (transitively) violate the atomicity of a transaction and require the programmer to establish consistency at appropriate points. The result is a programming model that is both general and simple. We have used the TIC model to re-engineer existing lock-based applications including a substantial multi-threaded web mail server and a memory allocator with coarse-grained locking. Our experience confirms the features of the TIC model: It is convenient for the programmer, while maintaining the benefits of transactional memory. expand
|
|
|
Streamflex: high-throughput stream programming in java |
| |
Jesper H. Spring,
Jean Privat,
Rachid Guerraoui,
Jan Vitek
|
|
Pages: 211-228 |
|
doi>10.1145/1297027.1297043 |
|
Full text: PDF
|
|
The stream programming paradigm aims to expose coarse-grained parallelism inapplications that must process continuous sequences of events. The appeal ofstream programming comes from its conceptual simplicity. A program is acollection of independent filters ...
The stream programming paradigm aims to expose coarse-grained parallelism inapplications that must process continuous sequences of events. The appeal ofstream programming comes from its conceptual simplicity. A program is acollection of independent filters which communicate by the means ofuni-directional data channels. This model lends itself naturally toconcurrent and efficient implementations on modern multiprocessors. As theoutput behavior of filters is determined by the state of their inputchannels, stream programs have fewer opportunities for the errors (such asdata races and deadlocks) that plague shared memory concurrent programming. This paper introduces S<scp>tream</scp>F<scp>lex</scp>, an extension to Java which marries streams with objects and thus enables to combine, in the same Java virtual machine, stream processing code with traditional object-oriented components. S<scp>tream</scp>F<scp>lex</scp> targets high-throughput low-latency applications with stringent quality-of-service requirements. To achieve these goals, it must, at the same time, extend and restrict Java. To allow for program optimization and provide latency guarantees, the S<scp>tream</scp>F<scp>lex</scp> compiler restricts Java by imposing a stricter typing discipline on filters. On the other hand, S<scp>tream</scp>F<scp>lex</scp> extends the Java virtual machine with real-time capabilities, transactional memory and type-safe region-based allocation. The result is a rich and expressive language that can be implemented efficiently. expand
|
|
|
Can programming be liberated from the two-level style: multi-level programming with deepjava |
| |
Thomas Kühne,
Daniel Schreiber
|
|
Pages: 229-244 |
|
doi>10.1145/1297027.1297044 |
|
Full text: PDF
|
|
Since the introduction of object-oriented programming few programming languages have attempted to provide programmers with more than objects and classes, i.e., more than two levels. Those that did, almost exclusively aimed at describing language properties-i.e., ...
Since the introduction of object-oriented programming few programming languages have attempted to provide programmers with more than objects and classes, i.e., more than two levels. Those that did, almost exclusively aimed at describing language properties-i.e., their metaclasses exert linguistic control on language concepts and mechanisms-often in order to make the language extensible. In terms of supporting logical domain classification levels, however, they are still limited to two levels. In this paper we conservatively extend the object-oriented programming paradigm to feature an unbounded number of domain classification levels. We can therefore avoid the introduction of accidental complexity into programs caused by accommodating multiple domain levels within only two programming levels. We present a corresponding language design featuring ``deep instantiation'' and demonstrate its features with a running example. Finally, we outline the implementation of our compiler prototype and discuss the potentials of further developing our language design. expand
|
|
|
SESSION: Software design |
|
|
|
|
Session details: Software design |
| |
David Holmes
|
|
doi>10.1145/3250665 |
|
|
|
|
The causes of bloat, the limits of health |
| |
Nick Mitchell,
Gary Sevitsky
|
|
Pages: 245-260 |
|
doi>10.1145/1297027.1297046 |
|
Full text: PDF
|
|
Applications often have large runtime memory requirements. In some cases, large memory footprint helps accomplish an important functional, performance, or engineering requirement. A large cache,for example, may ameliorate a pernicious performance problem. ...
Applications often have large runtime memory requirements. In some cases, large memory footprint helps accomplish an important functional, performance, or engineering requirement. A large cache,for example, may ameliorate a pernicious performance problem. In general, however, finding a good balance between memory consumption and other requirements is quite challenging. To do so, the development team must distinguish effective from excessive use of memory. We introduce health signatures to enable these distinctions. Using data from dozens of applications and benchmarks, we show that they provide concise and application-neutral summaries of footprint. We show how to use them to form value judgments about whether a design or implementation choice is good or bad. We show how being independent ofany application eases comparison across disparate implementations. We demonstrate the asymptotic nature of memory health: certain designsare limited in the health they can achieve, no matter how much the data size scales up. Finally, we show how to use health signatures to automatically generate formulas that predict this asymptotic behavior, and show how they enable powerful limit studies on memory health. expand
|
|
|
Notation and representation in collaborative object-oriented design: an observational study |
| |
Uri Dekel,
James D. Herbsleb
|
|
Pages: 261-280 |
|
doi>10.1145/1297027.1297047 |
|
Full text: PDF
|
|
Software designers in the object-oriented paradigm can make use of modeling tools and standard notations such as UML. Nevertheless, casual observations from collocated design collaborations suggest that teams tend to use physical mediums to sketch a ...
Software designers in the object-oriented paradigm can make use of modeling tools and standard notations such as UML. Nevertheless, casual observations from collocated design collaborations suggest that teams tend to use physical mediums to sketch a plethora of informal diagrams in varied representations that often diverge from UML. To better understand such collaborations and support them with tools, we need to understand the origins, roles, uses, and implications of these alternate representations. To this end we conducted observational studies of collaborative design exercises, in which we focused on representation use. Our primary finding is that teams intentionally improviserepresentations and organize design information in responseto ad-hoc needs, which arise from the evolution of the design, and which are difficult to meet with fixed standard notations. This behavior incurs orientation and grounding difficulties for which teams compensate by relying on memory, other communication mediums, and contextual cues. Without this additional information the artifacts are difficult to interpret and have limited documentation potential. Collaborative design tools and processes should therefore focus on preserving contextual information while permitting unconstrained mixing and improvising of notations. expand
|
|
|
Webrb: evaluating a visual domain-specific language for building relational web-applications |
| |
Avraham Leff,
James T. Rayfield
|
|
Pages: 281-300 |
|
doi>10.1145/1297027.1297048 |
|
Full text: PDF
|
|
Many web-applications can be characterized as "relational". In this paper we introduce and evaluate WebRB, a visualdomain-specific language for building such applications. WebRB addresses the limitations of the conventional "imperative-embedding" ...
Many web-applications can be characterized as "relational". In this paper we introduce and evaluate WebRB, a visualdomain-specific language for building such applications. WebRB addresses the limitations of the conventional "imperative-embedding" approach typically used to build relational web-applications. We describe the WebRB language, present extended examples of its use, and discuss the WebRB visual editor, libraries, and runtime. We then evaluate WebRB by comparing it to alternative approaches, and demonstrate its effectiveness in building relational web-applications. expand
|
|
|
SESSION: Type and typestate |
|
|
|
|
Session details: Type and typestate |
| |
Mandana Vaziri
|
|
doi>10.1145/3250666 |
|
|
|
|
Modular typestate checking of aliased objects |
| |
Kevin Bierhoff,
Jonathan Aldrich
|
|
Pages: 301-320 |
|
doi>10.1145/1297027.1297050 |
|
Full text: PDF
|
|
Objects often define usage protocols that clients must follow inorder for these objects to work properly. Aliasing makes itnotoriously difficult to check whether clients and implementations are compliant with such protocols. Accordingly, existing approaches ...
Objects often define usage protocols that clients must follow inorder for these objects to work properly. Aliasing makes itnotoriously difficult to check whether clients and implementations are compliant with such protocols. Accordingly, existing approaches either operate globally or severely restrict aliasing. We have developed a sound modular protocol checking approach, based on typestates, that allows a great deal of flexibility in aliasing while guaranteeing the absence of protocol violations at runtime. The main technical contribution is a novel abstraction, access permissions, that combines typestate and object aliasing information. In our methodology, developers express their protocol design intent through annotations based on access permissions. Our checking approach then tracks permissions through method implementations. For each object reference the checker keeps track of the degree of possible aliasing and is appropriately conservativein reasoning about that reference. This helps developers account for object manipulations that may occur through aliases. The checking approach handles inheritance in a novel way, giving subclasses more flexibility in method overriding. Case studies on Java iterators and streams provide evidence that access permissions can model realistic protocols, and protocol checking based on access permissions can be used to reason precisely about the protocols that arise in practice. expand
|
|
|
Type qualifier inference for java |
| |
David Greenfieldboyce,
Jeffrey S. Foster
|
|
Pages: 321-336 |
|
doi>10.1145/1297027.1297051 |
|
Full text: PDF
|
|
Java's type system provides programmers with strong guarantees of type and memory safety, but there are many important properties not captured by standard Java types. We describe JQual, a tool that adds user-defined type qualifiers to Java, allowing ...
Java's type system provides programmers with strong guarantees of type and memory safety, but there are many important properties not captured by standard Java types. We describe JQual, a tool that adds user-defined type qualifiers to Java, allowing programmers to quickly and easily incorporateextra lightweight, application-specific type checking into their programs. JQual provides type qualifier inference, so that programmers need only add a few key qualifier annotations to their program, and then JQual infers any remaining qualifiers and checks their consistency. We explore two applications of JQual. First, we introduce opaque and enumqualifiers to track C pointers and enumerations that flow through Java code via the JNI. In our benchmarks we found that these C values are treated correctly, but there are some places where a client could potentially violate safety. Second,we introduce a read only qualifier for annotating references that cannot be used to modify the objects they refer to. We found that JQual is able to automatically infer read only in many places on method signatures. These results suggest that type qualifiers and type qualifier inference are a useful addition to Java. expand
|
|
|
Establishing object invariants with delayed types |
| |
Manuel Fahndrich,
Songtao Xia
|
|
Pages: 337-350 |
|
doi>10.1145/1297027.1297052 |
|
Full text: PDF
|
|
Mainstream object-oriented languages such as C# and Java provide an initialization model for objects that does not guarantee programmer controlled initialization of fields. Instead, all fields are initialized to default values (0 for scalars and null ...
Mainstream object-oriented languages such as C# and Java provide an initialization model for objects that does not guarantee programmer controlled initialization of fields. Instead, all fields are initialized to default values (0 for scalars and null for non-scalars) on allocation. This is in stark contrast to functional languages, where all parts of an allocation are initialized to programmer-provided values. These choices have a direct impact on two main issues: 1) the prevalence of null in object oriented languages (and its general absence in functional languages), and 2) the ability to initialize circular data structures. This paper explores connections between these differing approaches and proposes a fresh look at initialization. Delayed types are introduced to express and formalize prevalent initialization patterns in object-oriented languages. expand
|
|
|
Modular verification of higher-order methods with mandatory calls specified by model programs |
| |
Steve M. Shaner,
Gary T. Leavens,
David A. Naumann
|
|
Pages: 351-368 |
|
doi>10.1145/1297027.1297053 |
|
Full text: PDF
|
|
What we call a''higher-order method" (HOM) is a method that makes mandatory calls to other dynamically-dispatched methods. Examples include template methods as in the Template method design pattern and notify methods in the Observer pattern. HOMs are ...
What we call a''higher-order method" (HOM) is a method that makes mandatory calls to other dynamically-dispatched methods. Examples include template methods as in the Template method design pattern and notify methods in the Observer pattern. HOMs are particularly difficult to reason about, because standard pre- and postcondition specifications cannot describe the mandatory calls. For reasoning about such methods, existing approaches use either higher order logic or traces, but both are complex and verbose. We describe a simple, concise, and modular approach to specifying HOMs We show how to verify calls to HOMs and their code using first-order verification conditions, in asound and modular way. Verification of client code that calls HOMs can take advantage of the client's knowledge about the mandatory calls to make strong conclusions. Our verification technique validates and explains traditional documentation practice for HOMs, which typically shows their code. However, specifications do not have to expose all of the code to clients, but only enough to determine how the HOM makes its mandatory calls. expand
|
|
|
SESSION: Isolation and repair |
|
|
|
|
Session details: Isolation and repair |
| |
Steve Backburn
|
|
doi>10.1145/3250667 |
|
|
|
|
Using early phase termination to eliminate load imbalances at barrier synchronization points |
| |
Martin C. Rinard
|
|
Pages: 369-386 |
|
doi>10.1145/1297027.1297055 |
|
Full text: PDF
|
|
We present a new technique, early phase termination, for eliminating idle processors in parallel computations that use barrier synchronization. This technique simply terminates each parallel phaseas soon as there are too few remaining tasks to ...
We present a new technique, early phase termination, for eliminating idle processors in parallel computations that use barrier synchronization. This technique simply terminates each parallel phaseas soon as there are too few remaining tasks to keep all of the processors busy. Although this technique completely eliminates the idling that would other wise occur at barrier synchronization points, it may also change the computation and therefore the result that the computation produces. We address this issue by providing probabilistic distortion models that characterize how the use of early phase termination distorts the result that the computation produces. Our experimental results show that for our set of benchmark applications, 1) early phase termination can improve the performance of the parallel computation, 2) the distortion is small (or can be made to be small with the use of an appropriate compensation technique) and 3) the distortion models provide accurate and tight distortion bounds. These bounds can enable users to evaluate the effect of early phase termination and confidently accept results from parallel computations that use this technique if they find the distortion bounds to be acceptable. Finally, we identify a general computational pattern that works well with early phase termination and explain why computations that exhibit this pattern can tolerate the early termination of parallel tasks without producing unacceptable results. expand
|
|
|
Starc: static analysis for efficient repair of complex data |
| |
Bassem Elkarablieh,
Sarfraz Khurshid,
Duy Vu,
Kathryn S. McKinley
|
|
Pages: 387-404 |
|
doi>10.1145/1297027.1297056 |
|
Full text: PDF
|
|
Data structure corruptions are insidious bugs that reduce the reliability of software systems. Constraint-based datastructure repair promises to help programs recover from potentially crippling corruption errors. Prior work repairs a variety of relatively ...
Data structure corruptions are insidious bugs that reduce the reliability of software systems. Constraint-based datastructure repair promises to help programs recover from potentially crippling corruption errors. Prior work repairs a variety of relatively small data structures, usually with hundreds of nodes. We present STARC which uses static analysis to repair data structures with tens of thousands of nodes. Given a Java predicate method that describes the integrity constraints of a structure, STARC statically analyzes the method to identify: (1) the recurrent fields, i.e., fields that the predicate method uses to traverse the structure; and (2) local field constraints, i.e., how the value of an object field is related to the value of a neighboring object field. STARC executes the predicate method on the structure and monitors its execution to identify corrupt object fields, which STARC then repairs using a systematic search of a neighborhood of the given structure. Each repair action is guided by the result of the static analysis, which enables more efficient and effective repair compared to prior work. Experimental results showthat STARC can repair structures with tens of thousands of nodes, up to 100 times larger than prior work. STARC efficiency is probably not practical for very large data structures in deployed systems, but opens a promising direction for future work. expand
|
|
|
Tracking bad apples: reporting the origin of null and undefined value errors |
| |
Michael D. Bond,
Nicholas Nethercote,
Stephen W. Kent,
Samuel Z. Guyer,
Kathryn S. McKinley
|
|
Pages: 405-422 |
|
doi>10.1145/1297027.1297057 |
|
Full text: PDF
|
|
Programs sometimes crash due to unusable values, for example, when Java and C# programs dereference null pointers and when C and C++ programs use undefined values to affect program behavior. A stack trace produced on such a crash identifies the effect ...
Programs sometimes crash due to unusable values, for example, when Java and C# programs dereference null pointers and when C and C++ programs use undefined values to affect program behavior. A stack trace produced on such a crash identifies the effect of the unusable value, not its cause, and is often not much help to the programmer. This paper presents efficient origin tracking of unusable values; it shows how to record where these values come into existence, correctly propagate them, and report them if they cause an error. The key idea is value piggybacking: when the original program stores an unusable value, value piggybacking instead stores origin information in the spare bits of the unusable value. Modest compiler support alters the program to propagate these modified values through operations such as assignments and comparisons. We evaluate two implementations: the first tracks null pointer origins in a JVM, and the second tracks undefined value origins in a memory-checking tool built with Valgrind. These implementations show that origin tracking via value piggybacking is fast and often useful, and in the Java case, has low enough overhead for use in a production environment. expand
|
|
|
SESSION: Ownership |
|
|
|
|
Session details: Ownership |
| |
Jan Vitek
|
|
doi>10.1145/3250668 |
|
|
|
|
Inferring aliasing and encapsulation properties for java |
| |
Kin-Keung Ma,
Jeffrey S. Foster
|
|
Pages: 423-440 |
|
doi>10.1145/1297027.1297059 |
|
Full text: PDF
|
|
There are many proposals for language techniques to control aliasing and encapsulation in object oriented programs, typically based on notions of object ownership and pointer uniqueness. Most of these systems require extensive manual annotations, and ...
There are many proposals for language techniques to control aliasing and encapsulation in object oriented programs, typically based on notions of object ownership and pointer uniqueness. Most of these systems require extensive manual annotations, and thus there is little experience with these properties in large, existing Java code bases. To remedy this situation, we present Uno, a novel static analysis for automatically inferring ownership, uniqueness, and other aliasing and encapsulation properties in Java. Our analysis requires no annotations, and combines an intraprocedural points-to analysis with an interprocedural, demand-driven predicate resolution algorithm. We have applied Uno to a variety of Java applications and found that some aliasing properties, such as temporarily lending a reference to a method, are common, while others, in particular field and argument ownership, are relatively uncommon. As a result, we believe that Uno can be a valuable tool for discovering and understanding aliasing and encapsulation in Java programs. expand
|
|
|
Multiple ownership |
| |
Nicholas R. Cameron,
Sophia Drossopoulou,
James Noble,
Matthew J. Smith
|
|
Pages: 441-460 |
|
doi>10.1145/1297027.1297060 |
|
Full text: PDF
|
|
Existing ownership type systems require objects to have precisely one primary owner, organizing the heap into an ownership tree. Unfortunately, a tree structure is too restrictive for many programs, and prevents many common design patterns where multiple ...
Existing ownership type systems require objects to have precisely one primary owner, organizing the heap into an ownership tree. Unfortunately, a tree structure is too restrictive for many programs, and prevents many common design patterns where multiple objects interact. Multiple Ownership is an ownership type system where objects can have more than one owner, and the resulting ownership structure forms a DAG. We give a straightforward model for multiple ownership, focusing in particular on how multiple ownership can support a powerful effects system that determines when two computations interfere-in spite of the DAG structure. We present a core programming language MOJO, Multiple ownership for Java-like Objects, including a type and effects system, and soundness proof. In comparison to other systems, MOJO imposes absolutely no restrictions on pointers, modifications or programs' structure, but in spite of this, MOJO's effects can be used to reason about or describe programs' behaviour. expand
|
|
|
Ownership transfer in universe types |
| |
Peter Müller,
Arsenii Rudich
|
|
Pages: 461-478 |
|
doi>10.1145/1297027.1297061 |
|
Full text: PDF
|
|
Ownership simplifies reasoning about object-oriented programs by controlling aliasing and modifications of objects. Several type systems have been proposed to express and check ownership statically. For ownership systems to be practical, they must allow ...
Ownership simplifies reasoning about object-oriented programs by controlling aliasing and modifications of objects. Several type systems have been proposed to express and check ownership statically. For ownership systems to be practical, they must allow objects to migrate from one owner to another. This ownership transfer is common and occurs, for instance, during the initialization of data structures and when data structures are merged. However, existing ownership type systems either do not support ownership transfer at all or they are too restrictive, give rather weak static guarantees, or require a high annotation overhead. In this paper, we present UTT, an extension of Universe Types that supports ownership transfer. UTT combines ownership type checking with a modular static analysis to control references to transferable objects. UTT is very flexible because it permits temporary aliases, even across certain method calls. Nevertheless, it guarantees statically that a cluster of objects is externally-unique when it is transferred and, thus, that ownership transfer is type safe. UTT provides the same encapsulation as Universe Types and requires only negligible annotation overhead. expand
|
|
|
SESSION: Language specification |
|
|
|
|
Session details: Language specification |
| |
Dan Grossman
|
|
doi>10.1145/3250669 |
|
|
|
|
Lost in translation: formalizing proposed extensions to c# |
| |
Gavin M. Bierman,
Erik Meijer,
Mads Torgersen
|
|
Pages: 479-498 |
|
doi>10.1145/1297027.1297063 |
|
Full text: PDF
|
|
Current real-world software applications typically involve heavy use of relational and XML data and their query languages. Unfortunately object-oriented languages and database query languages are based on different semantic foundations and optimization ...
Current real-world software applications typically involve heavy use of relational and XML data and their query languages. Unfortunately object-oriented languages and database query languages are based on different semantic foundations and optimization strategies. The resulting ''ROX (Relations, Objects, XML) impedance mismatc'' makes life very difficult for developers. Microsoft Corporation is developing extensions to the .NET framework to facilitate easier processing of non-object-oriented data models. Part of this project (known as "LINQ") includes various extensions to the .NET languages to leverage this support. In this paper we consider proposals for C# 3.0, the next version of the C# programming language. We give both an informal introduction to the new language features, and a precise formal account by defining a translation from C# 3.0 to C# 2.0. This translation also demonstrates how these language extensions do not require any changes to the underlying CLR. expand
|
|
|
The java module system: core design and semantic definition |
| |
Rok Strniša,
Peter Sewell,
Matthew Parkinson
|
|
Pages: 499-514 |
|
doi>10.1145/1297027.1297064 |
|
Full text: PDF
|
|
Java has no module system. Its packages only subdivide the class name space, allowing only a very limited form of component-level information hiding and reuse. Two Java Community Processes have started addressing this problem: one describes the ...
Java has no module system. Its packages only subdivide the class name space, allowing only a very limited form of component-level information hiding and reuse. Two Java Community Processes have started addressing this problem: one describes the runtime system and has reached an early draft stage, while the other considers the developer's view and only has a straw-man proposal. Both are natural language documents, which inevitably contain ambiguities. In this work we design and formalize a core module system for Java. Where the JCP documents are complete, we follow them closely; elsewhere we make reasonable choices. We define the syntax, the type system, and the operational semantics of an LJAM language, defining these rigorously in the Isabelle/HOL automated proof assistant. Using this formalization, we identify various issues with the module system. We highlight the underlying design decisions, and discuss several alternatives and their benefits. Our Isabelle/HOL definitions should provide a basis for further consideration of the design alternatives, for reference implementations, and for proofs of soundness. expand
|
|
|
Awesome: an aspect co-weaving system for composing multiple aspect-oriented extensions |
| |
Sergei Kojarski,
David H. Lorenz
|
|
Pages: 515-534 |
|
doi>10.1145/1297027.1297065 |
|
Full text: PDF
|
|
Domain specific aspect-oriented language extensions offer unique capabilities to deal with a variety of cross cutting concerns. Ideally, one should be able to use several of these extensions together in a single program. Unfortunately, each extension ...
Domain specific aspect-oriented language extensions offer unique capabilities to deal with a variety of cross cutting concerns. Ideally, one should be able to use several of these extensions together in a single program. Unfortunately, each extension generally implements its own specialized weaver and the different weavers are incompatible. Even if the weavers were compatible, combining them is a difficult problem to solve in general, because each extension definesits own language with new semantics. In this paper we present a practical composition framework, named A<scp>wesome</scp>, for constructing a multi-extension weaver by plugging together independently developed aspect mechanisms. The framework has a component-based and aspect-oriented architecture that facilitates the development and integration of aspect weavers. To be scalable, the framework provides a default resolution of feature interactions in the composition. To be general, the framework provides means for customizing the composition behavior. Furthermore, to be practically useful, there is no framework-associated overhead on the runtime performance of compiled aspect programs. To illustrate the A<scp>wesome</scp> framework concretely, we demonstrate the construction of a weaver for a multi-extension AOP language that combines Cool and AspectJ. However, the composition method is not exclusive to Cool and AspectJ-it can be applied to combine any comparable reactive aspect mechanisms. expand
|
|
|
SESSION: Runtime techniques |
|
|
|
|
Session details: Runtime techniques |
| |
David Gay
|
|
doi>10.1145/3250670 |
|
|
|
|
Scalable omniscient debugging |
| |
Guillaume Pothier,
Éric Tanter,
José Piquer
|
|
Pages: 535-552 |
|
doi>10.1145/1297027.1297067 |
|
Full text: PDF
|
|
Omniscient debuggers make it possible to navigate backwards in time within a program execution trace, drastically improving the task of debugging complex applications. Still, they are mostly ignored in practice due to the challenges raised by the potentially ...
Omniscient debuggers make it possible to navigate backwards in time within a program execution trace, drastically improving the task of debugging complex applications. Still, they are mostly ignored in practice due to the challenges raised by the potentially huge size of the execution traces. This paper shows that omniscient debugging can be realistically realized through the use of different techniques addressing efficiency, scalability and usability. We present TOD, a portable Trace-Oriented Debugger for Java, which combines an efficient instrumentation for event generation, a specialized distributed database for scalable storage and efficient querying, support for partial traces in order to reduce the trace volume to relevant events, and innovative interface components for interactive trace navigation and analysis in the development environment. Provided a reasonable infrastructure, the performance of TOD allows a responsive debugging experience in the face of large programs. expand
|
|
|
Using hpm-sampling to drive dynamic compilation |
| |
Dries Buytaert,
Andy Georges,
Michael Hind,
Matthew Arnold,
Lieven Eeckhout,
Koen De Bosschere
|
|
Pages: 553-568 |
|
doi>10.1145/1297027.1297068 |
|
Full text: PDF
|
|
All high-performance production JVMs employ an adaptive strategy for program execution. Methods are first executed unoptimized and then an online profiling mechanism is used to find a subset of methods that should be optimized during the same execution. ...
All high-performance production JVMs employ an adaptive strategy for program execution. Methods are first executed unoptimized and then an online profiling mechanism is used to find a subset of methods that should be optimized during the same execution. This paper empirically evaluates the design space of several profilers for initiating dynamic compilation and shows that existing online profiling schemes suffer from several limitations. They provide an insufficient number of samples, are untimely, and have limited accuracy at determining the frequently executed methods. We describe and comprehensively evaluate HPM-sampling, a simple but effective profiling scheme for finding optimization candidates using hardware performance monitors (HPMs) that addresses the aforementioned limitations. We show that HPM-sampling is more accurate; has low overhead; and improves performance by 5.7% on average and up to 18.3% when compared to the default system in Jikes RVM, without changing the compiler. expand
|
|
|
Mop: an efficient and generic runtime verification framework |
| |
Feng Chen,
Grigore Roşu
|
|
Pages: 569-588 |
|
doi>10.1145/1297027.1297069 |
|
Full text: PDF
|
|
Monitoring-Oriented Programming (MOP1) [21, 18, 22, 19] is a formal framework for software development and analysis, in which the developer specifies desired properties using definable specification formalisms, along with code to execute when properties ...
Monitoring-Oriented Programming (MOP1) [21, 18, 22, 19] is a formal framework for software development and analysis, in which the developer specifies desired properties using definable specification formalisms, along with code to execute when properties are violated or validated. The MOP framework automatically generates monitors from the specified properties and then integrates them together with the user-defined code into the original system. The previous design of MOP only allowed specifications without parameters, so it could not be used to state and monitor safety properties referring to two or more related objects. In this paper we propose a parametric specification formalism-independent extension of MOP, together with an implementation of JavaMOP that supports parameters. In our current implementation, parametric specifications are translated into AspectJ code and then weaved into the application using off-the-shelf AspectJ compilers; hence, MOP specifications can be seen as formal or logical aspects. Our JavaMOP implementation was extensively evaluated on two benchmarks, Dacapo [14] and Tracematches [8], showing that runtime verification in general and MOP in particular are feasible. In some of the examples, millions of monitor instances are generated, each observing a set of related objects. To keep the runtime overhead of monitoring and event observation low, we devised and implemented a decentralized indexing optimization. Less than 8% of the experiments showed more than 10% runtime overhead; in most cases our tool generates monitoring code as efficient as the hand-optimized code. Despite its genericity, JavaMOP is empirically shown to be more efficient than runtime verification systems specialized and optimized for particular specification formalisms. Many property violations were detected during our experiments; some of them are benign, others indicate defects in programs. Many of these are subtle and hard to find by ordinary testing. expand
|
|
|
Making trace monitors feasible |
| |
Pavel Avgustinov,
Julian Tibble,
Oege de Moor
|
|
Pages: 589-608 |
|
doi>10.1145/1297027.1297070 |
|
Full text: PDF
|
|
A trace monitor observes an execution trace at runtime; when it recognises a specified sequence of events, the monitor runs extra code. In the aspect-oriented programming community, the idea originatedas a generalisation of the advice-trigger ...
A trace monitor observes an execution trace at runtime; when it recognises a specified sequence of events, the monitor runs extra code. In the aspect-oriented programming community, the idea originatedas a generalisation of the advice-trigger mechanism: instead of matchingon single events (joinpoints), one matches on a sequence of events. The runtime verification community has been investigating similar mechanisms for a number of years, specifying the event patterns in terms of temporal logic, and applying the monitors to hardware and software. In recent years trace monitors have been adapted for use with mainstream object-oriented languages. In this setting, a crucial feature is to allow the programmer to quantify over groups of related objects when expressing the sequence of events to match. While many language proposals exist for allowing such features, until now no implementation had scalable performance: execution on all but very simple examples was infeasible. This paper rectifies that situation, by identifying two optimisations for generating feasible trace monitors from declarative specifications of the relevant event pattern. We restrict ourselves to optimisations that do not have a significant impact on compile-time: they only analyse the event pattern, and not the monitored code itself. The first optimisation is an important improvement over an earlier proposal in [2] to avoid space leaks. The second optimisation is a form of indexing for partial matches. Such indexing needs to be very carefully designed to avoid introducing new space leaks, and the resulting data structure is highly non-trivial. expand
|
|
|
SESSION: Onward! session 1 |
|
|
|
|
Session details: Onward! session 1 |
| |
Crista Videira Lopes
|
|
doi>10.1145/3250671 |
|
Full text: PDF
|
|
|
|
|
Living in the comfort zone |
| |
Martin C. Rinard
|
|
Pages: 611-622 |
|
doi>10.1145/1297027.1297072 |
|
Full text: PDF
|
|
A comfort zone is a tested region of a system's input space within which it has been observed to behave acceptably. To keep systems operating within their comfort zones, we advocate the interposition of rectifiers between systems and their input ...
A comfort zone is a tested region of a system's input space within which it has been observed to behave acceptably. To keep systems operating within their comfort zones, we advocate the interposition of rectifiers between systems and their input sources. Rectifiers are designed to transform inputs to ensure that they are within the comfort zone before they are presented to the system. Rectifiers enforce a highly constrained input format and, if necessary, discard information to force inputs to conform to this format. Potential benefits of this approach include the elimination of errors and vulnerabilities, the excision of undesirable excess functionality from large, complex systems, and a simplification of the computing environment. We have developed a rectifier for email messages and used this rectifier to force messages into a specific constrained form. Our results show that this rectifier can successfully produce messages that keep the Pine email client strictly within code previously confirmed (during a small testing and training session) to function acceptably. Our results also show that the rectifier completely eliminates a security vulnerability in the Pine email client. And finally, the rectifier is able to accomplish these goals while still preserving an acceptable amount of information from the original messages. expand
|
|
|
Living it up with a live programming language |
| |
Sean McDirmid
|
|
Pages: 623-638 |
|
doi>10.1145/1297027.1297073 |
|
Full text: PDF
|
|
A dynamic language promotes ease of use through flexible typing, a focus on high-level programming, and by streamlining the edit-compile-debug cycle. Live languages go beyond dynamic languages with more ease of use features. A live language supports ...
A dynamic language promotes ease of use through flexible typing, a focus on high-level programming, and by streamlining the edit-compile-debug cycle. Live languages go beyond dynamic languages with more ease of use features. A live language supports live programming that provides programmers with responsive and continuous feedback about how their edits affect program execution. A live language is also based on high-level constructs such as declarative rules so that programmers can write less code. A live language could also provide programmers with responsive semantic feedback to enable time-saving services such as code completion. This paper describes the design of a textual live language that is based on reactive data-flow values known as signals and dynamic inheritance. Our language, SuperGlue, supports live programming with responsive semantic feedback, which we demonstrate with a working prototype. expand
|
|
|
SESSION: Onward! session 2 |
|
|
|
|
Session details: Onward! session 2 |
| |
Crista Videira Lopes
|
|
doi>10.1145/3250672 |
|
|
|
|
No ifs, ands, or buts: uncovering the simplicity of conditionals |
| |
Jonathan Edwards
|
|
Pages: 639-658 |
|
doi>10.1145/1297027.1297075 |
|
Full text: PDF
|
|
Schematic tables are a new representation for conditionals. Roughly a cross between decision tables and data flowgraphs, they represent computation and decision-making orthogonally. They unify the full range of conditional constructs, from if ...
Schematic tables are a new representation for conditionals. Roughly a cross between decision tables and data flowgraphs, they represent computation and decision-making orthogonally. They unify the full range of conditional constructs, from if statements through pattern matching to polymorphic predicate dispatch. Program logic is maintained in a declarative canonical form that enforces completeness and disjointness among choices. Schematic tables can beused either as a code specification/generation tool, or as a self-contained diagrammatic programming language. They give program logic the clarity of truth tables, and support high-level direct manipulation of that logic, avoiding much of the mental computation demanded by conventional conditionals. expand
|
|
|
Epi-aspects: aspect-oriented conscientious software |
| |
Sebastian Fleissner,
Elisa L. A. Baniassad
|
|
Pages: 659-674 |
|
doi>10.1145/1297027.1297076 |
|
Full text: PDF
|
|
Conscientious software is a recently proposed paradigm for developing reliable, self-sustaining software systems. Conscientious software systems consist of an allopoietic part, which encapsulates application functionality, and an autopoietic part that ...
Conscientious software is a recently proposed paradigm for developing reliable, self-sustaining software systems. Conscientious software systems consist of an allopoietic part, which encapsulates application functionality, and an autopoietic part that is responsible for keeping the system alive by monitoring the application and adapting it to environmental changes. Practical application of the conscientious software paradigm requires solutions to two open problems: The design of suitable autopoietic programming languages and the proposal of concrete architectures for combining the autopoietic and allopoietic parts. In this paper, we tackle the second challenge, and propose a concrete, aspect-oriented architecture for realizing conscientious software. Here, we introduce epi-aspects, a construct for upgrading new and existing applications into conscientious software. This paper provides the architectural design of epi-aspects, an autopoietic simulator, and a concrete framework for developing epi-aspects in Java. The framework and the simulator are used to conduct a case study in which we develop and test a conscientious Java application. expand
|
|
|
SESSION: Essays session 1 |
|
|
|
|
Session details: Essays session 1 |
| |
Guy L. Steele, Jr.
|
|
doi>10.1145/3250673 |
|
Full text: PDF
|
|
|
|
|
Confessions of a used programming language salesman |
| |
Erik Meijer
|
|
Pages: 677-694 |
|
doi>10.1145/1297027.1297078 |
|
Full text: PDF
|
|
For many years I had been fruitlessly trying to sell functional programming and Haskell to solve real world problems such as scripting and data-intensive three-tier distributed web applications. The lack of widespread adoption of Haskell is a real pity. ...
For many years I had been fruitlessly trying to sell functional programming and Haskell to solve real world problems such as scripting and data-intensive three-tier distributed web applications. The lack of widespread adoption of Haskell is a real pity. Functional programming concepts are key to curing many of the headaches that plague the majority of programmers, who today are forced to use imperative languages. If the mountain won't come to Mohammed, Mohammed must go to the mountain, and so I left academia to join industry. Instead of trying to convince imperative programmers to forget everything they already know and learn something completely new, I decided to infuse existing imperative object-oriented programming languages with functional programming features. As a result, functional programming has finally reached the masses, except that it is called Visual Basic 9 instead of Haskell 98. expand
|
|
|
SESSION: Essays session 2 |
|
|
|
|
Session details: Essays session 2 |
| |
Guy L. Steele, Jr.
|
|
doi>10.1145/3250674 |
|
|
|
|
The transactional memory / garbage collection analogy |
| |
Dan Grossman
|
|
Pages: 695-706 |
|
doi>10.1145/1297027.1297080 |
|
Full text: PDF
|
|
This essay presents remarkable similarities between transactional memory and garbage collection. The connections are fascinating in their own right, and they let us better understand one technology by thinking about the corresponding issues for the other.
This essay presents remarkable similarities between transactional memory and garbage collection. The connections are fascinating in their own right, and they let us better understand one technology by thinking about the corresponding issues for the other. expand
|