toms419 and toms717 maxing out RAM on 64-bit Allegro

[david....@genworks.com]

Is it normal/expected behavior for toms419 and toms717 to gobble up to 5GB of RAM (on compile/loading it) on a 64-bit Lisp? I think the toms419 maxed out the RAM then finally timed out, and cl-test-grid killed the process and moved on. Now it looks like it is doing the same for toms717.  Are these packages expected to consume huge memories or is this an Allegro-specific problem? I did run these tests on Linux as well, but that was on a machine with 32GB of RAM, so maybe they were able to run successfully.  I am seeing this on 64-bit Allegro/Windows SMP (non-SMP hasn't gotten to that test yet). 

My Allegro/Windows 32-bit tests are almost done, and I presume they may have had the same problem but it didn't get so far because the Lisp probably threw an allocation error when it got to around 1 or 1.5GB.  

I just thought I would ask here for experiences before digging into the results myself...

[Dave Cooper]

Note that when I say "maxes out the RAM," this is so because my Windows VM is configured with 5GB of RAM. 

If some of the cl-test-grid tests are known to require more than that, then I can temporarily bump up the RAM. It just seemed a bit suspicious to me that a system would require that much RAM just to compile/load. 

[Anton Vodonosov]

Ah, these toms ASDF systems are from f2cl project - a Fortran compiler.

I saw it using a lot of memory on SBCL - sometimes SBCL failed to compile
it even with 1GB heap, which I consider large, other libraries require less.
5GB is extra large.

CCL for example stays within 100MB of memory when compiling these systems.

As it was explained to me on sbcl mailing list, the SBCL's use of memory
is due to imprecise (conservative) garbage collector.

Probably Allegro's GC is also conservative.

I suggest to let the libraries fail, and not increase the system memory.

Best regards,
- Anton