Lisp Knowledgebase
Title: Dealing with excess long-lived garbage
ID: 10027
Product: LispWorks Version: All OS: All | |
Description: First, the user loads the code for the program and executes (room): CL-USER 1 > (room) Generation 0: Total Size 525K, Allocated 330K, Free 186K Generation 1: Total Size 1370K, Allocated 1100K, Free 257K Generation 2: Total Size 14756K, Allocated 12915K, Free 1815K Total Size 16648K, Allocated 14346K, Free 2260K Now, execute the program: CL-USER 2 > (run-genetic-programming-system 'NON-HAMSTRUNG-SQUAD-CAR 1.0 21 100) At the end of run, (room) prints: CL-USER 3 > (room) Generation 0: Total Size 525K, Allocated 76K, Free 440K Generation 1: Total Size 2010K, Allocated 645K, Free 1348K Generation 2: Total Size 16676K, Allocated 15371K, Free 1267K Total Size 19208K, Allocated 16093K, Free 3056K The space in Generation 2 has increased by 2Mb. Now, when the same program is executed again. CL-USER 4 > (run-genetic-programming-system 'NON-HAMSTRUNG-SQUAD-CAR 1.0 21 100) the space grows again: CL-USER 5 > (room) Generation 0: Total Size 525K, Allocated 244K, Free 272K Generation 1: Total Size 2010K, Allocated 483K, Free 1510K Generation 2: Total Size 18596K, Allocated 17367K, Free 1179K Total Size 21128K, Allocated 18095K, Free 2962K This is a problem with promoting, into generation 2, large object data which then dies. The solution is to call gc-generation: (progn (run-genetic-programming-system 'NON-HAMSTRUNG-SQUAD-CAR 1.0 21 100) (gc-generation 2) ) Note: Use (mark-and-sweep 2) instead of gc-generation in LispWorks 5.1 and earlier versions. | |
See Also: Workaround: Patch: | |
Hardware:N/A | |
Summary:Swap space is being filled erroneously with garbage | |
Bug#: | |
Patch Enhancement#: | |
Reported:5499 |