Subject: bug#41194: 28.0.50; [feature/native-comp] fibn benchmark exhausts memory

From: Andrea Corallo <[email-masked]>
Date: Sat, 13 Jun 2020 15:00:33 +0000

Kévin Le Gouguec <[email-masked]> writes:

> Andrea Corallo <[email-masked]> writes:
>
>> sorry for the very late reply I just had a look.
>
> No need to apologize!  You've obviously been busy on other fronts.
>
>> The following is going on: being on 32bit system you get into bignums
>> end this allocates memory while is looping inside `elb-fibn'.
>> Unfortunatelly there's no opportunity of passing through maybe_gc to
>> trigger garbage collection because I've not implemented the equivalent
>> of what is the quitcounter in the byte interpreter.
>>
>> I'll come-up with a patch to generate the equivalent code of the
>> quitcounter when compiling for speed < 3.
>>
>> Thanks for the feedback
>>
>>   Andrea
>>
>> PS FYI I think memory consumption during compilation (as compile time)
>> should be now considerably lowered (but I've still haven't measured it).
>
> Alright!  I'll keep an eye on your branch and on the bugtracker, and
> recompile & run my measurements when I spot your patch.

Hi Kévin,

5a55a845a7 * Implement 'maybe_gc_or_quit' to allow correct GC in compiled Lisp
34ed9d2498 * Introduce latches

are fixing here this issue, now running fibn at speed 2 the memory
consuptions stays constant.

You'll still see the same behavior at speed 3 because there the
programmer is supposedly responsible to add manually possible GC entry
points.

I think now 32bit should be in a much better state but I hadn't time to
test it still.

Thanks!

  Andrea

--
[email-masked]