GNU bug report logs - #55972
28.1; Package quickstart generated for large number of packages generates byte-code string larger than 64K, triggering bytecode overflow error

Previous Next

Full log

View this message in rfc822 format

From: Lynn Winebarger <owinebar <at> gmail.com>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 55972 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#55972: 28.1; Package quickstart generated for large number of packages generates byte-code string larger than 64K, triggering bytecode overflow error
Date: Fri, 17 Jun 2022 16:06:01 -0400

[Message part 1 (text/plain, inline)]

On Tue, Jun 14, 2022 at 12:29 PM Mattias Engdegård <mattiase <at> acm.org> wrote:

> If, as seems to be the case, byte-compile-keep-pending is only used for
> top-level forms, then this patch may even be correct. Does it solve your
> problems?
> It still seems to generate far bigger bytecode chunks than the 300 cutoff
> would imply but that's perhaps just a matter of calling the function in
> more places.
>
>
Thanks, Mattias, it does work.

I was going to ask about directly addressing the underlying problem by
tail-calling
or trampolining to a byte-code vector in the constants array, but then
realized you would have to
either make sure there could be no "gotos" between the segments or do a
real trampoline to
an explicit label.  And in either case you would have to save the contents
of the stack frame
and reinstate them in the continuation byte-code call, and I don't see any
byte-codes that would
support that.   Otherwise you could only do it when you know there is no
stack in use, which is what I believe
your solution effectively does.

On the other hand, given the code for patching up byte-code in
byte-compile-lapcode, you could
explicitly byte-compile a thunk for every top-level expression, then glue
them together until they would exceed
the 65K pc limit, then do another segment, etc, and do a simple trampoline
between the resulting byte-code vectors,
or no trampoline if there were only one required.  Strictly speaking,
gluing them all together is really an optimization
of creating byte-code vectors (thunks) for each top-level expression, and
looping over the collection of them, invoking
each one in turn.

As long as I'm looking at the compile log, I also see a lot of errors of
the form:
     package-quickstart2.el:14739:39: Warning: The compiler ignores
‘autoload’ except at top level.  You should
         probably put the autoload of the macro ‘bind-map-for-minor-mode’
at top-level.
This message is only reported for macros - there are plenty of autoload
expressions that do not generate this
message despite being in the same kind of "let" form.

Lynn

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.