The value (expt 2 16) is derived from the implementation's value for call-arguments-limit.
Interpreted or compiled? Repeatably?
The above form seems to fail in both interpreted and compiled versions, but only on the first invocation. Then repeated invocations seem to succeed. This makes little sense, so I wonder if I am not testing what I think I am. Could this somehow be the underlying JVM replacing JITd code running the implementation when it fails?
We can "fix" this bug be setting it something under (expt 2 16): by quick experimentation (expt 2 15) works fine on my machine. As such, the actual call-argument-limit is gonna depend heavily where it is running. We should probably set it to something conservative.
Investigation
What do other implementations do?
TODO
Not the stepper
This bug has been present since at least abcl-1.8.0.
This bug is a regression from abcl-1.9.1 in which the ABCL-STEPPER contrib enables interactive stepping through forms by instrumenting the CL:EVAL with machinery that should only impact performance when stepping is active. Apparently this is not the case, so we need to go back through the code to remove side-effects @alejandrozf.
From reviewing the stepper instrumentation, it could definitely be made more efficient when the stepper is not active by following the original codepath when Lisp.stepper is not true.
Background
Bug EVAL of EQUALP across long lists blows up stack
In triaging why the CALL-ARGUMENTS-LIMIT.4 test fails when invoked under SLIME but works from an unadorned top-level call.
I managed to reduce the failure to the following form which doesn't require one to be using SLIME to trigger it:
The value
(expt 2 16)
is derived from the implementation's value forcall-arguments-limit
.Interpreted or compiled? Repeatably?
The above form seems to fail in both interpreted and compiled versions, but only on the first invocation. Then repeated invocations seem to succeed. This makes little sense, so I wonder if I am not testing what I think I am. Could this somehow be the underlying JVM replacing JITd code running the implementation when it fails?
CALL-ARGUMENTS-LIMIT used to be 50
We set it high in https://github.com/armedbear/abcl/issues/440 based on arguments from @alanruttenberg which apparently didn't consider this corner case (Verify!).
We can "fix" this bug be setting it something under
(expt 2 16)
: by quick experimentation(expt 2 15)
works fine on my machine. As such, the actualcall-argument-limit
is gonna depend heavily where it is running. We should probably set it to something conservative.Investigation
What do other implementations do?
TODO
Not the stepper
This bug has been present since at least abcl-1.8.0.
This bug is a regression from abcl-1.9.1 in which the ABCL-STEPPER contrib enables interactive stepping through forms by instrumenting theCL:EVAL
with machinery that should only impact performance when stepping is active. Apparently this is not the case, so we need to go back through the code to remove side-effects @alejandrozf.Instrumentation for ABCL-STEPPER added as https://github.com/armedbear/abcl/commit/558a45be21d06df5e2b3bd5cceb025dac678c78a
From reviewing the stepper instrumentation, it could definitely be made more efficient when the stepper is not active by following the original codepath when
Lisp.stepper
is nottrue
.