A flexible model for dynamic linking in Java and C#

Dynamic linking supports flexible code deployment, allowing partially linked code to link further code on the fly, as needed. Thus, end-users enjoy the advantage of automatically receiving any updates, without any need for any explicit actions on their side, such as re-compilation, or re-linking. On the down side, two executions of a program may link in different versions of code, which in some cases causes subtle errors, and may mystify end-users. Dynamic linking in Java and C# are similar: the same linking phases are involved, soundness is based on similar ideas, and executions which do not throw linking errors give the same result. They are, however, not identical: the linking phases are combined differently, and take place in different order. Consequently, linking errors may be detected at different times by Java and C# runtime systems. We develop a non-deterministic model, which describes the behaviour of both Java and C# program executions. The nondeterminism allows us to describe the design space, to distill the similarities between the two languages, and to use one proof of soundness for both. We also prove that all execution strategies are equivalent with respect to terminating executions that do not throw link errors: they give the same results

Behavioural types for non-uniform memory accesses

Concurrent programs executing on NUMA architectures consist of concurrent entities (e.g. threads, actors) and data placed on different nodes. Execution of these concurrent entities often reads or updates states from remote nodes. The performance of such systems depends on the extent to which the concurrent entities can be executing in parallel, and on the amount of the remote reads and writes. We consider an actor-based object oriented language, and propose a type system which expresses the topology of the program (the placement of the actors and data on the nodes), and an effect system which characterises remote reads and writes (in terms of which node reads/writes from which other nodes). We use a variant of ownership types for the topology, and a combination of behavioural and ownership types for the effect system.Comment: In Proceedings PLACES 2015, arXiv:1602.0325

The knife change minimization problem. definition, properties, heuristics

We define formally the Knife Change Minimization Problem, we prove some properties which reduce the search space, and then describe some heuristsics. At one of the last stages of the paper construction process customer widths have to be cut out of jumbo reels. For example, the widths 50,40,60,40, 30,50,50,50 and 60,40,40,40 may have to be cut out of three jumbo reels of width 200. The collections of indivdidual widths (e.g. 50-40-60-40) are called patterns. The order in which to consider the patterns (i.e. the route) can be arbitrary, and the order in which to cut each pattern is arbitrary as well. Each different solution involves a different number of knife changes, e.g. the solution from above involves 12 knife changes, whereas the solution 50-40-40-60, 5-4-4-4 and 50-50-50-30 involves only 7 knife changes. The objective is to find the solution with the minimal number of knife changes, or, because the search space is immense, to approximate such a solution. We first give some auxiliary definitions describing operations on sequences, bags and sets. We then define formally the problem, the solution space and the cost function in terms of the above. We prove some properties which reduce the search space, and then we describe heuristics

What is Java binary compatibility?

Separate compilation allows the decomposition of programs into units that may be compiled separately, and linked into an executable. Traditionally, separate compilation was equivalent to the compilation of all units together, and modi cation and re-compilation of one unit required re-compilation of all importing units. Java suggests a more exible framework, in which the linker checks the integrity of the binaries to be combined. Certain source code modi cations, such asaddition of methods to classes, are de ned as binary compatible. The language description guarantees that binaries of types (i.e. classes or interfaces) modi ed in binary compatible ways may be re-compiled and linked with the binaries of types that imported and were compiled using the earlier versions of the modi ed types. However, this is not always the case: some of the changes considered by Java as binary compatible do not guarantee successful linking and execution. In this paper we study the concepts around binary compatibility. We suggest a formalization of the requirement of safe linking and execution without re-compilation, investigate alternatives, demonstrate several of its properties, and propose a more restricted de nition of binary compatible changes. Finally, we prove for a substantial subset of Java, that this restricted de nition guarantees error-free linking and execution.

Refactoring Boundary

We argue that the limit of the propagation of the heap effects of a source code modification is determined by the aliasing structure of method parameters in a trace of the method calls that cross a boundary which partitions the heap. Further, that this aliasing structure is sufficient to uniquely determine the state of the part of the heap which has not been affected. And we give a definition of what it means for a part of the heap to be unaffected by a source code modification. This can be used to determine the correctness of a refactoring

What is java binary compatibility?

Separate compilation allows the decomposition of programs into units that may be compiled separately, and linked into an executable. Traditionally, separate compilation was equivalent to the compilation of all units together, and modification and re-compilation of one unit required re-compilation of all importing units. Java suggests a more flexible framework, in which the linker checks the integrity of the binaries to be combined. Certain source code modifications, such as addition of methods to classes, are defined as binary compatible. The language description guarantees that binaries of types (i.e. classes or interfaces) modified in binary compatible ways may be re-compiled and linked with the binaries of types that imported and were compiled using the earlier versions of the modified types. However, this is not always the case: some of the changes considered by Java as binary compatible do not guarantee successful linking and execution. In this paper we study the concepts around binary compatibility. We suggest a formalization of the requirement of safe linking and execution without re-compilation, investigate alternatives, demonstrate several of its properties, and propose a more restricted definition of binary compatible changes. Finally, we prove for a substantial subset of Java, that this restricted definition guarantees error-free linking and execution

Java is type safe -- probably

Amidst rocketing numbers of enthusiastic Java programmers and internet applet users, there is growing concern about the security of executing Java code produced by external, unknown sources. Rather than waiting to find out empirically what damage Java programs do, we aim to examine first the language and then the environment, looking for points of weakness. A proof of the soundness of the Java type system is a first, necessary step towards demonstrating which Java programs won't compromise computer security. We consider a type safe subset of Java describing primitive types, classes, inheritance, instance variables and methods, interfaces, shadowing, dynamic method binding, object creation, null and arrays. We argue that for this subset the type system is sound, by proving that program execution preserves the types, up to subclasses/subinterfaces

Permco – a permissive approach to covariant overriding of subclass members

We describe Permco, a permissive approach which allows covariant overriding of instance variables and any overriding of instance methods. Subclasses are considered subtypes. Instance method access is treated by considering the types of all methods defined for the class of the receiver and all its possible subclasses. Instance variable access is treated by considering the types of the instance variable in all possible subclasses. Thus, Permco is permissive at the point of redefinition and restrictive at the point of call or access. Closed types describe values which may belong to a class but not to its subclasses, and allow a more precise description of types. Result types may depend on receiver or argument types. This paper introduces Permco in terms of an example and compares with related approaches. It then demonstrates its soundness through a subject reduction theorem