LocalAllocation

Overview

This topic discusses how to use the JVM local slots to implement the VariableBindings and ClosureAllocation. The intent is to allocate all lexical, non-closure variables to stack-allocated slots. The current references to gensymed symbols that hold values will be dropped in favor of stack allocation. Free variables will be treated as lisp symbols, as they are in the current implementation. However, the current system calls the intern method for every reference, slowing execution significantly. The new implementation allocates a local variable on entry of the enclosing lambda expression, intern s the symbol and puts it in the local variable slot. All other references to the symbol later in the lambda expression refer to the symbol in the local variable.

At every level of binding, the binding allocations are complete before descending into a nested binding environment. The order of allocation is

• lambda bindings (parameters passed to funcall or apply methods).
• Non- lambda bindings (let etc)
• Closures
• Globally free variables

The order reflects some constraints imposed by the JVM (parameters come first) and the assumption that lexically-bound, non-closed variables are accessed more frequently. The JVM has special instructions for the first 4 stack slots, supporting a minor optimization. Later versions of the compiler may support much more efficient allocation schemes.

References

Implementation

Lexical, Non-Closure Variables

These variables have lexical scope within the binding environment and are not part of a closure in that binding environment. For example, in

(lambda (x y)
  ..some code...
  (lambda (z) (+ x z))
  ...more code...
)


The parameter x is closed in the outer binding, and the parameter y is bound but not closed. In this example, x is allocated to a closure structure and all references to x are to the closure. But y is merely a bound variable. It is stack-allocated as a JVM local variable. All references to y are to that local variable.

Free Variables

Variables in CLforJava that are globally free are treated as dynamically-scoped symbols. Such variables may be referenced in many locations within a lambda expression. Free variables may be recognized within let forms, but they are allocated within the nearest enclosing lambda expression (including the current one). The allocation of free variables is determined after the creation of the lambda reference data. All of the free variables are identified in the binding form where they occur. The allocation algorithm determines in which binding form the symbol is allocated and assigned to a JVM local variable.

Notice that the recognition of a globally free variable within a let form forces an :symbol-table entry for that variable in the enclosing lambda expression.

Examples

Algorithm

For each free variable, the SemanticAnalyzer locates the nearest enclosing lambda expression

Closure Reference

The reference to a closure in any binding environment is allocated to the next available local variable after all parameter and lexically-bound but not closed variables. It precedes the allocation of globally free variables.

Discussions

Links to Blog issues

Current Status of LocalAllocation

Status:

Release Level:

Open bug count:

Test Suites

Links to JUnit results

-- JerryBoetje - 12 Jul 2003