# Julia 1.9 uses more memory for compilation caches that 1.8

**URL:** <https://discourse.julialang.org/t/julia-1-9-uses-more-memory-for-compilation-caches-that-1-8/99482>\
**Category:** Performance\
**Created:** [May 27, 2023, 12:50pm UTC](https://discourse.julialang.org/t/julia-1-9-uses-more-memory-for-compilation-caches-that-1-8/99482 "2023-05-27T12:50:22Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![andreyz4k](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/andreyz4k/32/27248_2.png) [@andreyz4k](https://discourse.julialang.org/u/andreyz4k)\
**Post date:** [May 27, 2023, 12:50pm UTC](https://discourse.julialang.org/t/julia-1-9-uses-more-memory-for-compilation-caches-that-1-8/99482/1 "2023-05-27T12:50:22Z")

</div>

Hi, I have a fairly large project that has a number of functions that deal with parameters of unspecified type (mostly passing them to the next functions that know what they will be getting). In the end, I’m relying on runtime dispatching in a number of places and it was one of the main reasons why I chose to use Julia for this project.

After the release of Julia 1.9, I noticed that memory usage increased significantly, up to the point where GitHub Actions workers are killed during testing. Here is an example run, where tests with 1.8 pass while 1.9 are killed [Don't stop tests on one julia versions if second one fails · andreyz4k/ec@9b78715 · GitHub](https://github.com/andreyz4k/ec/actions/runs/5046332647).

Allocation numbers measured by `@time` are in the same ballpark (I’m running tasks until timeout, so there are fluctuations every time), memory usage is not growing if I’m running the same task again and again, so there is no memory leak, leaving compilation caches the main culprit.

What has changed in this area in 1.9? And how can I track memory usage from compilation caches? I can’t rely on total allocation metrics because they mix everything together, and I can’t make everything type stable, because a lot of my code should be generic.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [May 27, 2023, 12:59pm UTC](https://discourse.julialang.org/t/julia-1-9-uses-more-memory-for-compilation-caches-that-1-8/99482/2 "2023-05-27T12:59:10Z")

</div>

What’s new in 1.9 is precompiled packages now have native code, so on disk much larger. I’m not sure if that’s you issue, but it can be disabled, something you could try, if you’re thinking of some in-memory (cache) structure if might be related, or a result of this. Or just use 1.8 for now… or 1.10/nightly to see if it’s better.

From the history file:

> Package precompilation now saves native code into a “pkgimage”, meaning that code generated during the precompilation process will not require compilation after package load. Use of pkgimages can be disabled via `--pkgimages=no` ([#44527]) ([#47184]).

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [May 27, 2023, 1:30pm UTC](https://discourse.julialang.org/t/julia-1-9-uses-more-memory-for-compilation-caches-that-1-8/99482/3 "2023-05-27T13:30:11Z")

</div>

I think you’re seeing the problem fixed by [Don't permalloc the pkgimgs, but add option for PkgCacheInspector by gbaraldi · Pull Request #49940 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/49940) which will be in 1.9.1.

---

<div class="post-metadata">

**Author:** ![andreyz4k](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/andreyz4k/32/27248_2.png) [@andreyz4k](https://discourse.julialang.org/u/andreyz4k)\
**Post date:** [May 27, 2023, 1:45pm UTC](https://discourse.julialang.org/t/julia-1-9-uses-more-memory-for-compilation-caches-that-1-8/99482/4 "2023-05-27T13:45:04Z")

</div>

I tried to run a test on 1.9.0 with `--pkgimages=no` and still got ~12Gb per worker process memory usage vs ~2.3Gb per worker on 1.8.5.

---

<div class="post-metadata">

**Author:** ![andreyz4k](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/andreyz4k/32/27248_2.png) [@andreyz4k](https://discourse.julialang.org/u/andreyz4k)\
**Post date:** [May 27, 2023, 2:26pm UTC](https://discourse.julialang.org/t/julia-1-9-uses-more-memory-for-compilation-caches-that-1-8/99482/5 "2023-05-27T14:26:57Z")

</div>

Experiments with the current 1.10 nightly showed the same 12Gb per worker memory usage as on 1.9.0, regardless of the `--pkgimages=no` option. So it’s probably not the problem you’ve mentioned.

I should also note that memory usage is growing steadily while it runs different tasks (and probably explores more combinations of parameter types), and not just eats everything from the start, what I would expect from precompiled packages.

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [May 27, 2023, 4:29pm UTC](https://discourse.julialang.org/t/julia-1-9-uses-more-memory-for-compilation-caches-that-1-8/99482/6 "2023-05-27T16:29:27Z")

</div>

oh, that might be changes in how aggressive gc is. you can set a soft limit on heap size in 1.9. that may fix it.

---

<div class="post-metadata">

**Author:** ![andreyz4k](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/andreyz4k/32/27248_2.png) [@andreyz4k](https://discourse.julialang.org/u/andreyz4k)\
**Post date:** [May 27, 2023, 5:31pm UTC](https://discourse.julialang.org/t/julia-1-9-uses-more-memory-for-compilation-caches-that-1-8/99482/7 "2023-05-27T17:31:49Z")

</div>

Is this option propagated to child processes? I tried to run it with `--heap-size-hint=3G` and `--heap-size-hint=1G` with no effect on memory usage whatsoever.

Can it be some weird side-effect of [optimizer: inline abstract union-split callsite by aviatesk · Pull Request #44512 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/44512)?

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [May 27, 2023, 6:22pm UTC](https://discourse.julialang.org/t/julia-1-9-uses-more-memory-for-compilation-caches-that-1-8/99482/8 "2023-05-27T18:22:11Z")

</div>

I don’t think it is propagated (although it possibly should be)

---

<div class="post-metadata">

**Author:** ![andreyz4k](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/andreyz4k/32/27248_2.png) [@andreyz4k](https://discourse.julialang.org/u/andreyz4k)\
**Post date:** [May 28, 2023, 3:57pm UTC](https://discourse.julialang.org/t/julia-1-9-uses-more-memory-for-compilation-caches-that-1-8/99482/9 "2023-05-28T15:57:38Z")

</div>

Yes, it looks like that’s the issue. I’ve switched from using the `-p` flag to launching workers with `addprocs(count, exeflags = "--heap-size-hint=1G")` and they actually stopped eating all the memory in the world. So it looks like this issue is kind of solved for me for now, but if people working on GC can look into it further, it would be great.

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [May 28, 2023, 4:42pm UTC](https://discourse.julialang.org/t/julia-1-9-uses-more-memory-for-compilation-caches-that-1-8/99482/10 "2023-05-28T16:42:05Z")

</div>

yeah. I’m becoming more convinced that this gc change was probably a mistake. it fixed some performance issues but does result in Julia eating a bunch more ram sometimes.