Memory-Efficient Code Path is Not Automatically Triggered

[aszepieniec]

No description provided.

[jan-ferdinand]

I can confirm this bug on Linux. I'm reasonably sure I'm using the try_reserve_exact API correctly.

A possible explanation for this behavior is overcommitment. That is, the kernel lets the allocation attempt go through, even though the available memory is insufficient. Once Triton VM actually starts using the allocated memory, the kernel realizes that memory is running out, and invokes the oom-killer. Since Triton VM is the process with the worst oom score (usually true considering our RAM demands), it gets terminated.

Should this explanation be correct¹, I see little opportunity for improvement. It is not possible to disable overcommitment for a single process. Messing with the system configuration is a bad idea, and probably impossible. Lowering the oom score adjustment below 0 (which is the default) also sounds like a bad idea and requires administrator privileges.

I'm open to other explanations.

Footnotes

1. I'm not sure what experiments to perform to try to disprove this hypothesis ↩

[jan-ferdinand]

On Windows, the memory-efficient code path is automatically triggered. As far as I know, the allocator on Windows does not perform overcommitting.

[aszepieniec]

Based on this source it is not too difficult to change the system-wide overcommit policy on linux. If we have a reliable way of triggering this issue, let's try that reliable way with overcommitment disabled to verify/falsify this hypothesis.

[jan-ferdinand]

Yes, that's a good experiment to run. 🧑‍🔬