ABCL 1.3.0 Release Engineering
http://abcl.org/trac/milestone/1.3.0
CHANGES
ASDF 3.0.3.0.1 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[] arrays).
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]: http://abcl.org/trac/changeset/14572 [r14579]: http://abcl.org/trac/changeset/14579
- 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).
[r14582]: http://abcl.org/trac/changeset/14582
## Compatbility
### Contrib
#### abcl-asdf
#328: http://abcl.org/trac/ticket/328
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]).
