Skip to content

Memory consumption of Frama-C in OCaml 5 beta1 is about 10x larger #11662

@maroneze

Description

@maroneze

My colleague just noticed that, when running Frama-C in a switch with OCaml.5.0.0~beta1, memory consumption of Frama-C is about 10x larger when loading dynamic modules (i.e., any of Frama-C's plug-ins).

I created a Dockerfile to test it on an isolated environment and obtained the same results.

When comparing the same code compiled under OCaml 4.14.0 and OCaml 5.0.0~beta1, I obtained the following differences:

Plugin Memory 4.14.0 (KB) Memory 5.0.0~beta1 (KB) Difference
none 23724 24980 5%
all 76424 967336 1166%
aorai 36364 339072 832%
callgraph 35084 317140 804%
dive 35380 338568 857%
e-acsl 27280 143444 426%
eva 34568 296416 757%
from 36104 344628 855%
impact 40264 482276 1098%
inout 36944 366408 892%
instantiate 25284 63284 150%
loop-analysis 35208 315164 795%
markdown-report 25804 49444 92%
metrics 35876 322344 798%
nonterm 35072 305268 770%
obfuscator 24968 42404 70%
occurrence 35004 306828 777%
pdg 37288 384804 932%
postdominators 35092 306764 774%
reduc 37348 384940 931%
report 25096 45068 80%
rtegen 25084 45000 79%
scope 38160 419024 998%
server 25452 61524 142%
slicing 39924 467248 1070%
sparecode 38684 431408 1015%
studia 34948 310884 790%
users 35172 325944 827%
variadic 25204 65292 159%

The two first lines are the most important ones; the others are provided only as possible clues for further investigation.

Memory usage is obtained by running /usr/bin/time -f "%M" (it reports maximum resident set size). Note that this is not just a theoretical issue (e.g. memory reserved but unused in practice): my colleague had his PC start swapping heavily when running a few dozen parallel instances of Frama-C, which doesn't happen with OCaml <= 4.14. This is when we decided to measure it.

I compiled and installed Frama-C, then ran it under the following configurations:

  • Without any modules dynamically loaded: frama-c -no-autoload-plugins
  • Default (all modules): frama-c
  • A single module per execution: frama-c -no-autoload-plugins -load-module <plugin>

We notice that, without any modules, memory usage is the same in both versions. But when all modules are loaded, it is almost 1GB in OCaml 5, versus less than 100 MB in OCaml 4.14.

Here's a hackish Dockerfile to help reproduce it:

# We don't actually use the Frama-C installed in this image, it serves only
# as a opam-ready base image
FROM framac/frama-c:dev-stripped.fedora

RUN opam update && opam switch create 5.0.0~beta1 -y
# why3 installation may fail, hence the "|| true" below
RUN opam install --deps-only frama-c --confirm-level=unsafe-yes || true
RUN opam install dune-site --confirm-level=unsafe-yes
RUN sudo dnf install time -y
RUN git clone https://git.frama-c.com/pub/frama-c.git --depth=1
RUN cd frama-c && eval $(opam env) && make && make install
RUN eval $(opam env) && /usr/bin/time -f "Memory: %M" frama-c -no-autoload-plugins
RUN eval $(opam env) && /usr/bin/time -f "Memory: %M" frama-c
RUN eval $(opam env) && for p in aorai callgraph dive e-acsl eva from impact inout instantiate loop-analysis markdown-report metrics nonterm obfuscator occurrence pdg postdominators reduc report rtegen scope server slicing sparecode studia users variadic; do /usr/bin/time -f "Plugin $p: Memory: %M" frama-c -no-autoload-plugins -load-module $p; done

In this Dockerfile, all we do is (1) install a new opam switch, (2) install Frama-C dependencies, then (3) clone and install Frama-C itself (currently, it is not possible to run opam install frama-c on a 5.0 switch due to the lack of a compatible Why3). Finally, (4) run Frama-C and measure memory usage.

I simply replaced 5.0.0~beta1 with 4.14.0 in the first RUN to compare it with OCaml 4.14.

If you have any clues on what could be causing it and how to further investigate, please tell us. We'll try to take a look into it ourselves.

Metadata

Metadata

Assignees

No one assigned

    Labels

    PerformancePR or issues affecting runtime performance of the compiled programs

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions