Implement malloc_trim

[bugcrazy]

A ticket has been opened on the original rpmalloc, malloc_trim is interesting and offers a good feature, it can be implemented in a smart way, better than glibc. mjansson#116

Here are some reference links:

https://stackoverflow.com/questions/15529643/what-does-malloc-trim0-really-mean

https://www.algolia.com/blog/engineering/when-allocators-are-hoarding-your-precious-memory/

[TheTechsTech]

Interesting feature to have, my changes currently just focus on getting execution under not so modern/standard compilers or systems.

I also find issues with original library, had fixed some, did different PR, but then was trying to track down what i thought was a memory leak. I reverted to original build and found i get segmentation faults, the library wasn’t usable without fixes from the beginning.

I wouldn’t mine PR submission, my focus is in other places/projects at the moment.

I would need to really think about my usage patterns that could cause the issue and stop it there. I can indirectly foresee addressing the possible issue.

The feature seems Linux only from the reading.

[bugcrazy]

This feature is present in Linux, the issue is that several software programs use it, if there is something similar in rpmalloc it would be a differential, the problem is that it is a low-level kernel function that calls glibc, it is not something portable:

https://www.gnu.org/software/gnulib/manual/html_node/malloc_005ftrim.html

https://stackoverflow.com/questions/62187219/alternative-for-malloc-trim0

It is important to fix the limitations of rpmalloc and develop tests that detect regressions.

[TheTechsTech]

What programs use it?

What script you have that will generate the problem? To fix a problem, the needs to be present to prove it’s fixed.

The more i read about it, the more i see it being not necessary.

[bugcrazy]

These are programs:

https://systemd.io/MEMORY_PRESSURE/

https://www.softwareatscale.dev/p/run-python-servers-more-efficiently

https://doc.servo.org/src/libc/unix/linux_like/linux/gnu/mod.rs.html#1500

Here are the tool scripts and tests performed:

https://github.com/FooBarWidget/heap_dumper_visualizer

mruby/mruby#5047

Here are articles and material for testing:

https://github.com/tessi/malloc_trim

https://www.joyfulbikeshedding.com/blog/2019-03-14-what-causes-ruby-memory-bloat.html

[TheTechsTech]

The only common issue I find, is the results of using "garbage collectors" for memory management, no fan. In which case using jemalloc is a better choice and more designed to handle.

I expected you to be showing how rpmalloc is displaying a problem, but the reality I see is a software design pattern usage, that's a different issue, not fixable here.

Before I decide to possibility write anything from scratch, I research other projects attempts and maybe rewrite that instead.

In general, my forks end up being something totally different.

My meaning of developer is the whole thing, everything involved, no prefix in front. If I find something is already doing it, use it, otherwise write it. It's like on the side origins of developing zelang-dev/c-raii#1

[bugcrazy]

I understand, the main problem is fragmentation, design problems can be solved by refactoring or rewriting code, but it depends on the scope of the project, problems reported by Haiku devs, which is the most correct path to follow.

[TheTechsTech]

Edit: I see the comments there from commits. But that’s all cpp, I actually removed the c++ files in this fork. I don’t see any tests run, showing the issues.

The author do state in the readme:

## memory fragmentation

There is no memory fragmentation by the allocator in the sense that it will not leave unallocated and unusable "holes" in the memory pages by calls to allocate and free blocks of different sizes. This is due to the fact that the memory pages allocated for each size class is split up in perfectly aligned blocks which are not reused for a request of a different size. The block freed by a call to rpfree will always be immediately available for an allocation request within the same size class.

However, there is memory fragmentation in the meaning that a request for x bytes followed by a request of y bytes where x and y are at least one size class different in size will return blocks that are at least one memory page apart in virtual address space. Only blocks of the same size will potentially be within the same memory page span.

rpmalloc keeps an "active span" and free list for each size class. This leads to back-to-back allocations will most likely be served from within the same span of memory pages (unless the span runs out of free blocks). The rpmalloc implementation will also use any "holes" in memory pages in semi-filled spans before using a completely free span.

So from that, the issue is in how it’s being called/used.

[TheTechsTech]

I know see where things are being discussed about malloc in general on https://review.haiku-os.org/q/malloc.

I will review issues when i can, see how things are addressed here.

[TheTechsTech]

Rereading the comments again, they acknowledge in various places it might be their usage/use-case.

So once that’s realize, might need to develop your own allocator, using mi-malloc eventually will have same problem. Adding malloc-trim will just increase the same usage and add more complexity, maybe why others not bothered doing so.

So far from rereading most things covered currently, but my usage pattern is different.

[bugcrazy]

Rereading the comments again, they acknowledge in various places it might be their usage/use-case.

So once that’s realize, might need to develop your own allocator, using mi-malloc eventually will have same problem. Adding malloc-trim will just increase the same usage and add more complexity, maybe why others not bothered doing so.

So far from rereading most things covered currently, but my usage pattern is different.

You are using the right approach.

[TheTechsTech]

I have downloaded and been going over https://review.haiku-os.org/c/haiku/+/1499, reviewing comments, the diff compared to this fork, plus original, and many things has changed, more functions, threads are initialized separately, heap/memory pages are better tracked/controlled.

You shouldn't even need malloc_trim using current original stable version. I think all their issues raised has been resolved, they should give it another try.

[bugcrazy]

I have downloaded and been going over https://review.haiku-os.org/c/haiku/+/1499, reviewing comments, the diff compared to this fork, plus original, and many things has changed, more functions, threads are initialized separately, heap/memory pages are better tracked/controlled.

You shouldn't even need malloc_trim using current original stable version. I think all their issues raised has been resolved, they should give it another try.

There are many changes in the fork, some issues should have been fixed.

Problem is that there are only practical usage tests, there is no testing tool in Haiku:
https://review.haiku-os.org/c/haiku/+/8335

[bugcrazy]

There are these tests in C++ for Haiku, which can help understand the problem of not releasing memory and fragmentation:

https://dev.haiku-os.org/ticket/15996

[TheTechsTech]

There are these tests in C++ for Haiku, which can help understand the problem of not releasing memory and fragmentation:

https://dev.haiku-os.org/ticket/15996

I'm going to finally close this out now, you keep repeating claims of here of issues your Dev's from 4 years ago with C++. There is no real issue here, you seem to want me to come up with a problem I don't have. That is something you need to provide, an actual example in C, showing this library not releasing memory when called do so. I read skill issues from every link you have been providing.

Your Dev's developing an OS, which they should have by now realize "no off the shelf allocation" is going to work with their problem of actual memory management, not allocation.

I see the standard malloc was really decoupled from an OS system for general use, you get a raw pointer, you do whatever, the tracking of usage is on you. That raw pointer has an header, if it's not valid, bad things happen.

It seems malloc_trim is a placebo for some type of memory management where only garbage collectors has use for.

[bugcrazy]

Malloc_trim is another GNU-ism, made for Linux, it is not portable to other OS, the link to the ruby article talks about fragmentation and good results obtained, the points raised by you are valid, the implementation of malloc_trim can be discarded.

Question how to solve fragmentation problem, ruby test shows that malloc tools have fragmentation problems and so does Haiku, in addition to problems in 32-bit systems, Haiku used rpmalloc as the main tool, found problems in daily use and developed tests.

It is difficult to find tests in C language to test fragmentation problems, that is generic, I found a test, I will open a ticket about fragmentation this main problem, not malloc_trim anymore.

It's hard to find fragmentation tests in C, searching, stress tests and debugging appear:

https://lukasatkinson.de/2024/allocator-testing/

[TheTechsTech]

Haiku used rpmalloc as the main tool, found problems in daily use and developed tests.

Links to those tests and results would be of interest.