Commaide killed by OOM when analyzing a file

Question

Comma is always killed by oom when I try to edit a file in which I use 10 modules (mainly Cro::HTTP ) and after the start of analysis. I can see that many raku process are running (in order to analyze?) :

journalctl :

janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   4722]  1000  4722      654       29    40960        0             0 comma.sh
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   4771]  1000  4771  1085318   155576  1949696        0             0 java
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   4825]  1000  4825      783       35    40960        0             0 fsnotifier64
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   5036]  1000  5036    52039    24008   364544        0             0 rakudo
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   5038]  1000  5038    51119    25114   372736        0             0 rakudo
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   5039]  1000  5039    52391    23805   368640        0             0 rakudo
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   5047]  1000  5047    51473    22787   352256        0             0 rakudo
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   5049]  1000  5049    51129    22929   356352        0             0 rakudo
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   5050]  1000  5050    49796    21981   348160        0             0 rakudo
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   5052]  1000  5052    50929    25154   368640        0             0 rakudo
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   5057]  1000  5057    52078    23535   364544        0             0 rakudo
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   5066]  1000  5066    51071    22735   348160        0             0 rakudo
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   5075]  1000  5075    51254    22555   356352        0             0 rakudo
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   5081]  1000  5081    49423    21271   335872        0             0 rakudo
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   5093]  1000  5093    49375    21590   344064        0             0 rakudo
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   5100]  1000  5100    50784    22763   352256        0             0 rakudo
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   5104]  1000  5104    49360    21141   335872        0             0 rakudo
janv. 09 19:47:42 samuel-Virtual-Machine kernel: [   5115]  1000  5115    46338    14169   282624        0             0 rakudo
janv. 09 19:47:42 samuel-Virtual-Machine kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/[email protected],task=java,pid=4771,uid=1000
janv. 09 19:47:42 samuel-Virtual-Machine kernel: Out of memory: Killed process 4771 (java) total-vm:4341272kB, anon-rss:622236kB, file-rss:0kB, shmem-rss:68kB, UID:1000 pgtables:1904kB oom_score_adj:0
janv. 09 19:47:42 samuel-Virtual-Machine kernel: oom_reaper: reaped process 4771 (java), now anon-rss:0kB, file-rss:0kB, shmem-rss:68kB

Is this a normal behavior? Is there an option to limit the number of parallel raku process ?

(I work on a small Vm with 4GB of memory).

Answer 1

It's expected that Comma will invoke the selected Raku compiler in order to obtain symbols from modules. That should take place once at the start of editing a file using a particular module and then be cached (and the caching is across the project as a whole).

Aside from the number of rakudo instances spawned, the memory usage of the java process itself looks a bit on the high side. Probably it's worth asking the Comma developers to take a look at it, and providing some more detailed information. Of note, the Help menu has a "Collect Logs and Diagnostic Data" option (which will provide a zip file that can be sent to the developers, although note it may also include some data about the project you are working on). Any other information to aid reproduction (such as the list of modules being used) would also be useful.