[armedbear-devel] failure to compile big files
Dear ABCL developers, trying to "compile-file" the following fragment of code using the latest release results in an error "s2 argument 32778 out of 16-bit signed range." ----------------------------------------------------- (defmacro many-functions (n) (append '(progn) (loop for i from 1 to n collect `(defun ,(intern (format nil "TEST~A" i)) () (print ,i))))) (many-functions 1525) ----------------------------------------------------- There are no problems with 0.20 (even for much bigger values of the parameter, i.e. bigger output files). I encountered the problem with a file containing several calls to the macro def-java-class in Jfli. It took me some time to discover that splitting the file in two was enough to make the problem go away... This is not a critical bug (it's usually easy to reorganize the code to ensure the files are small enough), but you might want to look at it. Cheers, Carlos
On Sun, Aug 22, 2010 at 3:19 PM, Carlos Ungil <carlos.ungil@gmail.com> wrote:
Dear ABCL developers,
trying to "compile-file" the following fragment of code using the latest release results in an error "s2 argument 32778 out of 16-bit signed range."
-----------------------------------------------------
(defmacro many-functions (n) (append '(progn) (loop for i from 1 to n collect `(defun ,(intern (format nil "TEST~A" i)) () (print ,i)))))
(many-functions 1525)
-----------------------------------------------------
There are no problems with 0.20 (even for much bigger values of the parameter, i.e. bigger output files). I encountered the problem with a file containing several calls to the macro def-java-class in Jfli. It took me some time to discover that splitting the file in two was enough to make the problem go away...
This is not a critical bug (it's usually easy to reorganize the code to ensure the files are small enough), but you might want to look at it.
The bug appears to be caused by the new way functions are loaded to avoid reflection: a big loader function is created that installs all the other functions by instantiating them as Java objects directly in bytecode. Since a function gets compiled to a single method and there's a limit on the size of a method, I believe we're hitting that limit. The obvious solution is to split the big method in many smaller methods (say, one every 1024 functions). I'd say this is a nice occasion to test Erik's new class-file writer! ;) So, stay tuned: I'll try to fix the bug asap. Cheers, and thanks for the report, Alessio
Alessio, Did you find time to fix the issue mentioned below, or should we file an issue in order to keep track? Bye, Erik. On Sun, Aug 22, 2010 at 10:14 PM, Alessio Stalla <alessiostalla@gmail.com> wrote:
On Sun, Aug 22, 2010 at 3:19 PM, Carlos Ungil <carlos.ungil@gmail.com> wrote:
Dear ABCL developers,
trying to "compile-file" the following fragment of code using the latest release results in an error "s2 argument 32778 out of 16-bit signed range."
-----------------------------------------------------
(defmacro many-functions (n) (append '(progn) (loop for i from 1 to n collect `(defun ,(intern (format nil "TEST~A" i)) () (print ,i)))))
(many-functions 1525)
-----------------------------------------------------
There are no problems with 0.20 (even for much bigger values of the parameter, i.e. bigger output files). I encountered the problem with a file containing several calls to the macro def-java-class in Jfli. It took me some time to discover that splitting the file in two was enough to make the problem go away...
This is not a critical bug (it's usually easy to reorganize the code to ensure the files are small enough), but you might want to look at it.
The bug appears to be caused by the new way functions are loaded to avoid reflection: a big loader function is created that installs all the other functions by instantiating them as Java objects directly in bytecode. Since a function gets compiled to a single method and there's a limit on the size of a method, I believe we're hitting that limit. The obvious solution is to split the big method in many smaller methods (say, one every 1024 functions). I'd say this is a nice occasion to test Erik's new class-file writer! ;) So, stay tuned: I'll try to fix the bug asap.
Cheers, and thanks for the report, Alessio
_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On Sun, Oct 10, 2010 at 10:09 PM, Erik Huelsmann <ehuels@gmail.com> wrote:
Alessio,
Did you find time to fix the issue mentioned below, or should we file an issue in order to keep track?
No, I didn't fix it, and it's better to keep track of it. Now I'm busy with invokedynamic - or better, with the new verifier, which is a prerequisite for it - but after that, I'd like to try to change our FASL loading scheme to avoid text files entirely, compiling the text file to a .class. If that turns out to be a good choice, I'll do the method splitting for it; else, I'll fix the bug the way I originally proposed. Bye, Alessio
Hi Alessio, On Mon, Oct 11, 2010 at 9:48 AM, Alessio Stalla <alessiostalla@gmail.com> wrote:
On Sun, Oct 10, 2010 at 10:09 PM, Erik Huelsmann <ehuels@gmail.com> wrote:
Alessio,
Did you find time to fix the issue mentioned below, or should we file an issue in order to keep track?
No, I didn't fix it, and it's better to keep track of it. Now I'm busy with invokedynamic - or better, with the new verifier, which is a prerequisite for it - but after that, I'd like to try to change our FASL loading scheme to avoid text files entirely, compiling the text file to a .class. If that turns out to be a good choice, I'll do the method splitting for it; else, I'll fix the bug the way I originally proposed.
That'd be great. Turns out this issue also prevents us from building SBCL, which I've tried today since a very long time. I'll log it later today then. Bye, Erik.
participants (3)
-
Alessio Stalla -
Carlos Ungil -
Erik Huelsmann