Many macro systems, especially for Lisp and Scheme, allow macro transformers to perform general computation. Moreover, the language for implementing compile-time macro transformers is usually the same as the language for implementing run-time functions. As a side effect of this sharing, implementations tend to allow the mingling of compile-time values and run-time values, as well as values from separate compilations. Such mingling breaks programming tools that must parse code without executing it. Macro implementors avoid harmful mingling by obeying certain macrodefinition protocols and by inserting phase-distinguishing annotations into the code. However, the annotations are fragile, the protocols are not enforced, and programmers can only reason about the result in terms of the compiler's implementation. MzScheme--- the language of the PLT Scheme tool suite---addresses the problem through a macro system that separates compilation without sacrificing the expressiveness of macros.

Abstract not found

Language runtime systems are increasingly being embedded in systems to support runtime extensibility via mobile code. Such systems raise a number of concerns when the code running in such systems is potentially buggy or untrusted. While sophisticated access controls have been designed for mobile code and are shipping as part of commercial systems such as Java, there is no support for terminating mobile code short of terminating the entire language runtime. This paper presents a concept called “soft termination ” which can be applied to virtually any mobile code system. Soft termination allows mobile code threads to be safely terminated while preserving the stability of the language runtime. In addition, function bodies can be permanently disabled, thwarting attacks predicated on system threads eventually calling untrusted functions. We present a formal design for soft termination and an implementation of it for Java, built using Java bytecode rewriting, and demonstrating reasonable performance (3-25% slowdowns on benchmarks).

The MrEd virtual machine serves both as the implementation platform for the DrScheme programming environment, and as the underlying Scheme engine for executing expressions and programs entered into DrScheme's read-eval-print loop. We describe the key elements of the MrEd virtual machine for building a programming environment, and we step through the implementation of a miniature version of DrScheme in MrEd. More generally, we show how MrEd defines a high-level operating system for graphical programs. 1 MrEd: A Scheme Machine The DrScheme programming environment [10] provides students and programmers with a user-friendly environment for developing Scheme programs. To make programming accessible and attractive to novices, DrScheme provides a thoroughly graphical environment and runs under several major windowing systems (Windows, MacOS, and Unix/X). More than 60 universities and high schools currently employ DrScheme in their computing curriculum, and new schools adopt DrScheme every s...

Language run-time systems are often called upon to safely execute mutually distrustful tasks within the same runtime, protecting them from other tasks ’ bugs or otherwise hostile behavior. Well-studied access controls exist in systems such as Java to prevent unauthorized reading or writing of data, but techniques to measure and control resource usage are less prevalent. In particular, most language run-time systems include no facility to account for and regulate heap memory usage on a per-task basis. This oversight can be exploited by a misbehaving task, which might allocate and hold live enough memory to cause a denial-of-service attack, crashing or slowing down other tasks. In addition, tasks can legitimately share references to the same objects, and traditional approaches that charge memory to its allocator fail to properly account for this sharing. We present a method for modifying the garbage collector, already present in most modern language runtime systems, to measure the amount of live memory reachable from each task as it performs its regular duties. Our system naturally distinguishes memory shared across tasks from memory reachable from only a single task without requiring incompatible changes to the semantics of the programming language. Our prototype implementation imposes negligible performance overheads in a variety of benchmarks, yet provides enough information for the expression of rich policies to express the limits on a task’s memory usage. 1