ABCL 1.3.0 Release Engineering


ASDF shipped with the implementation

  • per function call stack and memory exception handler in CL:COMPILE


  • Lazily create the little used portions of the Lisp stack.

Aggressively cache and control the use of memory by the underlying Lisp stack frame representation by introducing the private LispThread?.StackFrame? and LispThread?.StackSegments? classes.

Dmitry Nadezhin contributes the following analysis:

LispStackFrame? object are allocated on every
LispThread?.execute(...) .
However, they are seldom [accessed] ([... verify via] inspect[tion
of the] stack trace). This patch delays allocation of
LispStackFrame? objects until they are requested.
Raw information about stack frames is stored in stack. Stack is an
Object[] array (more precisely a list of [...]4 [Mib] Object[]

Make LispStackFrame??.UNAVAILABLE_ARG a singleton object,

Memory profiling of ABCL shows that the classes with largest allocation count are org.armedbear.lisp.LispStackFrame? and org.armedbear.lisp.LispStackFrame?.UnavailableArgument?.

Contributed by Dmitry Nadezhin.

[r14572]: [r14579]:

  • SYS:SHA256 audited

The functionality if the SYS:SHA256 algorithim has been audited for use on inputs of single for files with recently shipping ORCL Java 7 implementations (through jdk-1.7.0_45).


## Compatbility

### Contrib

#### abcl-asdf


Working with both Maven 3.0.x and 3.1.x. Thanks to Anton for the help!

#### jna

Now references jna-4.0.0. Some incompatibility with CFFI ([in progress with fixing upstream][1]).


Last modified 4 years ago Last modified on 11/09/13 18:54:38