Most specifications of garbage collectors concentrate on the low-level algorithmic details of how to find and preserve accessible objects. Often, they focus on bit-level manipulations such as "scanning stack frames," "marking objects," "tagging data," etc. While these details are important in some contexts, they often obscure the more fundamental aspects of memory management: what objects are garbage and why? We develop a series of calculi that are just low-level enough that we can express allocation and garbage collection, yet are sufficiently abstract that we may formally prove the correctness of various memory management strategies. By making the heap of a program syntactically apparent, we can specify memory actions as rewriting rules that allocate values on the heap and automatically dereference pointers to such objects when needed. This formulation permits the specification of garbage collection as a relation that removes portions of the heap without affecting the outcome of the evaluation. Our high-level approach allows us to specify in a compact manner a wide variety of memory management techniques, including standard trace-based garbage collection (i.e., the family of copying and mark/sweep collection algorithms), generational collection, and type-based, tag-free collection. Furthermore, since the definition of garbage is based on the semantics of the underlying language instead of the conservative approximation of inaccessibility, we are able to specify and prove the idea that type inference can be used to collect some objects that are accessible but never used.

Abstract not found

. 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. 1 Introduction Before the first complete Java language description was available [13] use of the language was extremely widespread and the ...

We define an interpretation of Standard ML into type theory. The interpretation takes the form of a set of elaboration rules reminiscent of the static semantics given in The Definition of StandardML. In particular, the elaboration rules are given in a relational style, exploiting indeterminacy to avoid over-commitment to specific implementation techniques. Elaboration consists of identifier scope resolution, type checking and type inference, expansion of derived forms, pattern compilation, overloading resolution, equality compilation, and the coercive aspects of signature matching.

Many programming languages have been developed and implemented for mobile code environments. They are typically quite expressive. But while security is an important aspect of any mobile code technology, it is often treated after the fundamental design is complete, in ad hoc ways. In the end, it is unclear what security guarantees can be made for the system. We argue that mobile programming languages should be designed around certain security properties that hold for all well-formed programs. This requires a better understanding of the relationship between programming language design and security. Appropriate security properties must be identified. Some of these properties and related issues are explored.