Error compiling FSET

[alessiostalla]

CL-USER> (ql:quickload :fset)
To load "fset":
  Load 1 ASDF system:
    fset; Loading "fset"
...............

Compilation of the "testing.lisp" file fails with:

The assertion (< 0 (LENGTH JVM::C) 65536) failed.
   [Condition of type SIMPLE-ERROR]

Restarts:
 0: [CONTINUE] Retry assertion.
 1: [RETRY] Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "fset" "Code" "testing">.
 2: [ACCEPT] Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "fset" "Code" "testing"> as having been successful.

The offending function seems to be TEST-MISC:

(SYSTEM::PROCESS-TOPLEVEL-FORM (DEFUN FSET::TEST-MISC NIL "Tests some things that don't need extensive random test cases generated." (MACROLET (#) (FLET # # # # # ...))) #<FILE-STREAM {6933BB11}> NIL)

[easye]

Compilation of the "testing.lisp" file fails with:

The assertion (< 0 (LENGTH JVM::C) 65536) failed.
   [Condition of type SIMPLE-ERROR]

It looks like ABCL is refusing to construct a class file larger than the 64k byte limit imposed by the JVM we currently target (49 3). A long time ago, @erikhueslmann hacked together something to deal with segmenting large fasls across multiple compiler targets. I had thought that our compiler did that by default, but I need to check.

Thanks for the report.

[alessiostalla]

Actually, I think the 64k limit is not about class file size, but method bytecode size, so it's the generated method that should be split, rather than the fasl.

[easye]

Actually, I think the 64k limit is not about class file size, but method bytecode size, so it's the generated method that should be split, rather than the fasl.

You are indeed correct that the 65536 byte limit is upon the method generation, not the total class size.

The culprit in fset is the 1803 lines, 15146 words, and 89640 characters function Test-Misc in Code/testing.lisp.

Conceptually, I suppose one could split such a function at the byte-code level with the correct tooling that could account for all the current variables on the stack. The easier but more inefficient solution would be to just include the offending interpreted form in the loader using it instead of the compiled representation. Such a generic fallback is not a bad idea in general for the compiler.

[alejandrozf]

Hi,

I successfully quick-loaded fset with last ABCL master, commit fff48abd8d2821b53d73015c1c42ecb8139a946d following steps in the Readme using quicklisp-abcl in Ubuntu 18.04.

Maybe this issue is solved after latest versions of ABCL and/or fset

[alejandrozf]

Please forget my last comment. It is still happening. Probably I was confused when running other CL implementation Anyway, I'm trying to solve this issue.

[alejandrozf]

This commit 4a3730af makes possible to compile fset library, the same approach can be used for cl:compile but this breaks the CL standard by making functions inside these forms interpreted and not compiled as it is required.

Maybe we could hack more on it to make it standard compliant but I'm not sure. The other approach seems to be the more correct solution, splitting the bytecode, but I'm not enougth familiar with Java bytecode manipulation. Maybe someone can follow the issue from here.

[alejandrozf]

I think this issue can be closed, the fix was merged to master. See https://github.com/armedbear/abcl/pull/490