Visually Characterizing Source Code Changes

International audienceRevision Control Systems (e.g., SVN, Git, Mercurial) include automatic and advanced merging algorithms that help developers to merge their modifications with development repositories. While these systems can help to textually detect conflicts, they do not help to identify the semantic consequences of a change. Unfortunately, there is little support to help release masters (integrators) to take decisions about the integration of changes into the system release. Most of the time, the release master needs to read all the modified code, check the diffs to build an idea of a change, and dig for details from related unchanged code to understand the context and potential impact of some changes. As a result, such a task can be overwhelming. In this article we present a visualization tool to support integrators of object-oriented programs in comprehending changes. Our approach named Torch characterizes changes based on structural informa- tion, authors and symbolic information. It mixes text-based diff information with visual representation and metrics characterizing the changes. The current implementation of our approach analyses Smalltalk programs, and thus we de- scribe our experiments applying it to Pharo, a large open-source system. We also report on the evaluations of our approach by release masters and developers of several open-source projects

Meta-models and Infrastructure for Smalltalk Omnipresent History

International audienceSource code management systems record different versions of code. Tool support can then com- pute deltas between versions. However there is little support to be able to perform history-wide queries and analysis: for example building slices of changes and identifying their differences since the beginning of the project. We believe that this is due to the lack of a powerful code meta- model as well as an infrastructure. For example, in Smalltalk often several source code meta- models coexist: the Smalltalk reflective API coexists with the one of the Refactoring engine or distributed versioning system. While having specific meta-models is an engineered solution, it hampers meta-models manipulation as it requires more maintenance efforts (e.g., duplication of tests, transformation between models), and more importantly navigation tool reuse. As a first step to solve this problem, this article presents several source code models that could be used to support several activities and proposes an unified and layered approach to be the foundation for building an infrastructure for omnipresent version browsing

Ring: a Unifying Meta-Model and Infrastructure for Smalltalk Source Code Analysis Tools

International audienceSource code management systems record different versions of code. Tool support can then compute deltas between versions. To ease version history analysis we need adequate models to represent source code entities. Now naturally the questions of their definition, the abstractions they use, and the APIs of such models are raised, especially in the context of a reflective system which already offers a model of its own structure. We believe that this problem is due to the lack of a powerful code meta-model as well as an infrastructure. In Smalltalk, often several source code meta-models coexist: the Smalltalk reflective API coexists with the one of the Refactoring Engine or distributed versioning system such as Monticello or Store. While having specific meta-models is an adequate engineered solution, it multiplies meta-models and it requires more maintenance efforts (e.g., duplication of tests, transformation between models), and more importantly hinders navigation tool reuse when meta-models do not offer polymorphic APIs. As a first step to provide an infrastructure to support history analysis, this article presents Ring, a unifying source code meta-model that can be used to support several activities and proposes a unified and layered approach to be the foundation for building an infrastructure for version and stream of change analyses. We re-implemented three tools based on Ring to show that it can be used as the underlying meta-model for remote and off-image browsing, scoping refactoring, and visualizing and analyzing changes. As a future work and based on Ring we will build a new generation of history analysis tools

Visually Supporting Source Code Changes Integration: the Torch Dashboard

International audienceAutomatic and advanced merging algorithms help programmers to merge their modifications in main development repositories. However, there is little support to help release masters (integrators) to take decisions about the integration of published merged changes into the system release. Most of the time, the release master has to read all the changed code, check the diffs to build an idea of a change, and read unchanged code to understand the context of some changes. Such a task can be overwhelming. In this paper we present a dashboard to support integrators getting an overview of proposed changes in the context of object-oriented programming. Our approach named Torch characterizes changes based on structural information, authors and symbolic information. It mixes text-based diff information with visual representation and metrics characterizing the changes. We describe our experiment applying it to Pharo, a large open-source system, and report on the evaluation of our approach by release masters of several open-source projects

Towards Abstract Interpretation for Recovering Design Information

AbstractIt is a well-known problem that design information of object-oriented programs is often lost or is not kept up-to-date when the program evolves. This design information can be recovered from the program using such techniques as logic meta programming. In this technique logic queries are used to check whether the program is implemented along certain well-known patterns. Currently the technique relies on structural information and patterns are expressed in the queries as conditions over structural elements of the program. Some patterns are however better expressed in dynamic terms which requires behavioural information about the program. Such information can be obtained from execution traces of the program, but these record only one possible input dependent program execution out of many. Abstract interpretation of the object-oriented program could provide a well-founded means for extracting the necessary behavioural information

Many-Core Virtual Machines: Decoupling Abstract from Concrete Concurrency

We propose to search for common abstractions for concurrency models to enable multi-language virtual machines to support a wide range of them. This would enable domain-specific solutions for concurrency problems. Furthermore, such an abstraction could improve portability of virtual machines to the vastly different upcoming many-core architectures

Intermediate Language Design of High-level Language Virtual Machines: Towards Comprehensive Concurrency Support

Today's major high-level language virtual machines (VMs) are becoming successful in being multi-language execution platforms, hosting a wide range of languages. With the transition from few-core to many-core processors, we argue that VMs will also have to abstract from concrete concurrency models at the hardware level, to be able to support a wide range of abstract concurrency models on a language level. To overcome the lack of sufficient abstractions for concurrency concepts in VMs, we proposed earlier to extend VM intermediate languages by special concurrency constructs. As a first step towards this goal, we try to fill a gap in the current literature and survey the intermediate language design of VMs. Our goal is to identify currently used techniques and principles as well as to gain an overview over the available concurrency related features in intermediate languages. Another aspect of interest is the influence of the particular target language, for which the VM is originally intended, on the intermediate language

Synchronization Views for Event-loop Actors

The actor model has already proven itself as an interesting concurrency model that avoids issues such as deadlocks and race conditions by construction, and thus facilitates concurrent programming. The tradeoff is that it sacrifices expressiveness and efficiency especially with respect to data parallelism. However, many standard solutions to computationally expensive problems employ data parallel algorithms for better performance on parallel systems. We identified three problems that inhibit the use of data-parallel algorithms within the actor model. Firstly, one of the main properties of the actor model, the fact that no data is shared, is one of the most severe performance bottlenecks. Especially the fact that shared state can not be read truly in parallel. Secondly, the actor model on its own does not provide a mechanism to specify extra synchronization conditions on batches of messages which leads to event-level data-races. And lastly, programmers are forced to write code in a continuation-passing style (CPS) to handle typical request-response situations. However, CPS breaks the sequential flow of the code and is often hard to understand, which increases complexity and lowers maintainability. We proposes \emphsynchronization views to solve these three issues without compromising the semantic properties of the actor model. Thus, the resulting concurrency model maintains deadlock-freedom, avoids low-level race conditions, and keeps the semantics of macro-step execution

Modularity and Conventions for Maintainable Concurrent Language Implementations: A Review of Our Experiences and Practices

In this paper, we review what we have learned from implementing languages for parallel and concurrent programming, and investigate the role of modularity. To identify the approaches used to facilitate correctness and maintainability, we ask the following questions: What guides modularization? Are informal approaches used to facilitate correctness? Are concurrency concerns modularized? And, where is language support lacking most? Our subjects are AmbientTalk, SLIP, and the RoarVM. All three evolved over the years, enabling us to look back at specific experiments to understand the impact of concurrency on modularity. We conclude from our review that concurrency concerns are one of the strongest drivers for the definition of module boundaries. It helps when languages offer sophisticated modularization constructs. However, with respect to concurrency, other language features like single-assignment are of greater importance. Furthermore, tooling that enables remodularization taking concurrency invariants into account would be of great value

Which Problems Does a Multi-Language Virtual Machine Need to Solve in the Multicore/Manycore Era?

While parallel programming for very regular problems has been used in the scientific community by non-computer-scientists successfully for a few decades now, concurrent programming and solving irregular problems remains hard. Furthermore, we shift from few expert system programmers mastering concurrency for a constrained set of problems to mainstream application developers being required to master concurrency for a wide variety of problems. Consequently, high-level language virtual machine (VM) research faces interesting questions. What are processor design changes that have an impact on the abstractions provided by VMs to provide platform independence? How can application programmers' diverse needs be facilitated to solve concurrent programming problems? We argue that VMs will need to be ready for a wide range of different concurrency models that allow solving concurrency problems with appropriate abstractions. Furthermore, they need to abstract from heterogeneous processor architectures, varying performance characteristics, need to account for memory access cost and inter-core communication mechanisms but should only expose the minimal useful set of notions like locality, explicit communication, and adaptable scheduling to maintain their abstracting nature. Eventually, language designers need to be enabled to guarantee properties like encapsulation, scheduling guarantees, and immutability also when an interaction between different problem-specific concurrency abstractions is required