[Larceny-users] Larceny Panic: Can't allocate an object of size ...

William D Clinger will at ccs.neu.edu
Fri Feb 5 14:26:52 EST 2016


Sven Hartrumpf wrote:

> Is there a way to avoid the following compiler crash?

Sorry about that.

In my experience, this error means Larceny's assembler tried
to create a single monolithic chunk of x86 machine code whose
size was the reported 17536520 bytes, which is larger than
the maximum object size Larceny currently supports.

The best workaround I know of is to force Larceny's compiler
to break that one huge chunk of x86 machine code into smaller
chunks.  You can probably do that using the lambda-optimization
compiler switch to disable lambda optimization, but that's a
rather blunt approach even if it works.

It would be better to identify specific lambda expressions
(including those implied by the (define (f x ...) ...) syntax)
you're willing to have called using the general closure-calling
mechanism instead of the optimized mechanism, which uses a
PC-relative branch instead of an indirect branch.  Once you've
forced the compiler to allocate separate code segments for
enough lambda expressions, you will no longer have a single
code segment larger than the 16 megabyte limit.

To force the compiler to allocate a separate code segment for
selected lambda expressions, I'd recommend defining new macros
DEFINE, LAMBDA, and HIDE such that

    (DEFINE (f x ...) ...)

expands into

    (define f (LAMBDA (x ...) ...0))

and

    (LAMBDA (...) ...)

expands into

    (hide (lambda (...) ...))

where hide is an obfuscated identity procedure such as

    (define (hide x)
      (vector-ref (vector x x 0)
                  (random 2)))

whose only purpose is to defeat compiler optimizations that
might otherwise result in combining lambda expressions into
some huge machine code segment.

> This is the 32bit compiler; will the 64bit compiler help here?

Yes, this problem will mostly go away when we have a 64-bit
version of Larceny.  Although there are likely to be various
other system constraints that will limit the size of a single
code segment even in 64-bit systems, those limits will probably
be so large that almost nobody ever runs into them.

Will



More information about the Larceny-users mailing list