[armedbear-devel] More efficient compilation of forward references -- WAS: r13536 - trunk/abcl/src/org/armedbear/lisp

Erik Huelsmann ehuels at gmail.com
Tue Aug 23 21:48:25 UTC 2011


When you look at the ### FASLATONCE comments, you may be wondering what I'm
doing here. Well, I'm looking at a way to make our own compilation much
faster again, but also to make our compiled code much faster.

The problem - as I understand it now - with our slow compilation since the
introduction of the jvm-class-file.lisp file is NOT so much the fact that we
store lots of data in structures now (I thought it was when I did that work
though). Rather, my current understanding is that the declaration order of
functions in a file is extremely important for the performance of said fasl:

Backward referenced functions (those being defined first and called from
code "further down the file") are being called through direct calls of the
execute() method of a final static field in the class of the calling
function. Since the value is final, the JVM is allowed to assume the jump is
always going to go to the same class's execute() method which can be very
easily optimized.

Forward referenced functions (those being called before they are defined --
although still defined in the same file) are being resolved through a call
to the getSymbolFunctionOrDie() function of the function's symbol. Since
that variable is *not* final, the call to the return value of
getSymbolFunctionOrDie() can't be as easily JITted.

Hence my idea to compile all toplevel compilands *after* the entire file has
been processed and all toplevel functions have been discovered. At that
time, the functions can be compiled and all forward references can be
resolved and hard coded using final static fields. However: this introduces
the risk of circularity during fasl loading. My remarks relate to that
problem.


Bye,


Erik.


On Tue, Aug 23, 2011 at 11:34 PM, <ehuelsmann at common-lisp.net> wrote:

> Author: ehuelsmann
> Date: Tue Aug 23 14:34:33 2011
> New Revision: 13536
>
> Log:
> Move more static field initialization to the static class initializer
> <clinit>() code.
>
> Additionally, place some remarks where I expect issues once I start
> compiling forward references the same way as backward references.
>
> Modified:
>   trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp
>
> Modified: trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp
>
> ==============================================================================
> --- trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp       Tue Aug 23
> 13:35:32 2011        (r13535)
> +++ trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp       Tue Aug 23
> 14:34:33 2011        (r13536)
> @@ -1392,7 +1392,7 @@
>                       (local-function-compiland local-function))))
>         (field-name (local-function-field local-function)))
>     (with-code-to-method
> -        (*class-file* (abcl-class-file-constructor *class-file*))
> +        (*class-file* (abcl-class-file-static-initializer *class-file*))
>       ;; fixme *declare-inline*
>       (declare-field field-name +lisp-object+)
>       (emit-new class-name)
> @@ -1416,7 +1416,7 @@
>     (with-code-to-method
>         (*class-file*
>          (if *declare-inline* *method*
> -             (abcl-class-file-constructor *class-file*)))
> +             (abcl-class-file-static-initializer *class-file*)))
>       ;; strings may contain evaluated bits which may depend on
>       ;; previous statements
>       (declare-field g +lisp-object+)
> @@ -1432,7 +1432,7 @@
>      (with-code-to-method
>          (*class-file*
>           (if *declare-inline* *method*
> -              (abcl-class-file-constructor *class-file*)))
> +              (abcl-class-file-static-initializer *class-file*)))
>        ;; The readObjectFromString call may require evaluation of
>        ;; lisp code in the string (think #.() syntax), of which the outcome
>        ;; may depend on something which was declared inline
> @@ -1455,7 +1455,7 @@
>     ;; fixme *declare-inline*?
>     (remember g obj)
>     (with-code-to-method
> -        (*class-file* (abcl-class-file-constructor *class-file*))
> +        (*class-file* (abcl-class-file-static-initializer *class-file*))
>       (declare-field g +lisp-object+)
>       (emit 'ldc (pool-string g))
>       (emit-invokestatic +lisp+ "recall"
> @@ -4149,6 +4149,11 @@
>           (emit-load-local-function local-function)
>           (emit-move-from-stack target))
>          ((inline-ok name)
> +          ;; ### FASLATONCE: when compiling fasl functions after the
> +          ;; full fasl has been processed, forward referenced functions
> +          ;; may not be available during the load process
> +          ;; This case is particularly triggered with circular referencing
> +          ;; functions, both marked as 'notinline'
>           (emit-getstatic *this-class*
>                 (declare-function name) +lisp-object+)
>           (emit-move-from-stack target))
> @@ -4166,6 +4171,11 @@
>           (emit-load-local-function local-function))
>          ((and (member name *functions-defined-in-current-file* :test
> #'equal)
>                (not (notinline-p name)))
> +          ;; ### FASLATONCE: when compiling fasl functions after the
> +          ;; full fasl has been processed, forward referenced functions
> +          ;; may not be available during the load process
> +          ;; This case is particularly triggered with circular referencing
> +          ;; functions, both marked as 'notinline'
>           (emit-getstatic *this-class*
>                 (declare-setf-function name) +lisp-object+)
>           (emit-move-from-stack target))
>
> _______________________________________________
> armedbear-cvs mailing list
> armedbear-cvs at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20110823/761f97eb/attachment.html>


More information about the armedbear-devel mailing list