# Poor performance of garbage collection in multi-threaded application

**URL:** <https://discourse.julialang.org/t/poor-performance-of-garbage-collection-in-multi-threaded-application/75493>\
**Category:** Julia at Scale\
**Tags:** garbage-collection\
**Created:** [January 31, 2022, 9:47am UTC](https://discourse.julialang.org/t/poor-performance-of-garbage-collection-in-multi-threaded-application/75493 "2022-01-31T09:47:08Z")\
**Posts on this page:** 3\
**Page:** 2

<div class="post-metadata">

**Author:** ![racinmat](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/racinmat/32/11715_2.png) [@racinmat](https://discourse.julialang.org/u/racinmat)\
**Post date:** [February 3, 2022, 10:43pm UTC](https://discourse.julialang.org/t/poor-performance-of-garbage-collection-in-multi-threaded-application/75493/21 "2022-02-03T22:43:22Z")

</div>

Is there any way to defragment memory if it’s already fragmented, or is it tied to how large chunks of memory and where in the code do I allocate them?

---

<div class="post-metadata">

**Author:** ![goerch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerch/32/29122_2.png) [@goerch](https://discourse.julialang.org/u/goerch)\
**Post date:** [February 3, 2022, 10:57pm UTC](https://discourse.julialang.org/t/poor-performance-of-garbage-collection-in-multi-threaded-application/75493/22 "2022-02-03T22:57:09Z")

</div>

It is more of an intrinsic problem. In the (g)olden days they used compacting garbage collection to fight fragmentation, but this is not an option here AFAIU (or are we?). You’ll probably have to identify the critical paths of your application and use an adequate preallocation or arena allocation strategy.

Edit: just [looked](https://discourse.julialang.org/t/is-the-garbage-collector-non-compacting/16335) it up, here another [link](https://discourse.julialang.org/t/details-about-julias-garbage-collector-reference-counting/18021).

> [@racinmat](#):
>
> Is there any way to defragment memory if it’s already fragmented, or is it tied to how large chunks of memory and where in the code do I allocate them?

No and yes.

---

<div class="post-metadata">

**Author:** ![tkf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkf/32/17635_2.png) [@tkf](https://discourse.julialang.org/u/tkf)\
**Post date:** [February 3, 2022, 11:35pm UTC](https://discourse.julialang.org/t/poor-performance-of-garbage-collection-in-multi-threaded-application/75493/23 "2022-02-03T23:35:15Z")

</div>

FYI there’s “compacting malloc”

> **[GitHub - plasma-umass/Mesh: A memory allocator that automatically reduces the...](https://github.com/plasma-umass/Mesh)**
>
> A memory allocator that automatically reduces the memory footprint of C/C++ applications. - GitHub - plasma-umass/Mesh: A memory allocator that automatically reduces the memory footprint of C/C++ a...

which can be used without re-building `julia` (just LD\_PRELOAD) IIUC.

Julia’s GC manages pool on its own so I don’t know how effective it is. But they also showed it was effective with Ruby.

(Edit: It’s likely irrelevant to this issue. Their Ruby example is based on that large string allocation in Ruby directly calls malloc.)

[Previous page](https://discourse.julialang.org/t/poor-performance-of-garbage-collection-in-multi-threaded-application/75493.md?page=1)