fweimer / redhat.com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=14581

> The Ruby allocator calls posix_memalign (16384, 16344), and
> unfortunately, such allocations, when freed, can not always be
> reused for subsequent allocations because the glibc allocator
> will not search for existing unused aligned allocations of a
> given size.

Thanks for bringing this to our attention.

I wonder how beneficial it is for Ruby to free the memalign-ed
sections used for object slots.   Each of those allocations
is "only" 400 or so objects and apps churn through that
quickly, so.

Testing the following patch with
"MALLOC_ARENA_MAX=1 MALLOC_ARENA_TEST=1 make gcbench-rdoc"
seems show a small improvement in VmHWM across repeated
runs, but the results aren't stable...

       https://80x24.org/spew/20180730085724.29644-1-e / 80x24.org/raw

The other problems are we hit malloc a lot and we use native
threads (despite the GVL) in unnecessary ways; and having a
process-wide GC means the associated free() for an allocation
can happen from a thread the allocation didn't come from.

Having multiple malloc arenas to avoid contention isn't very
useful with the GVL, either.


Anyways I'm working on several topics to reduce unnecessary
uses of native threads; and ko1 is introducing transient heap
to deal with short-lived allocations.  So I'm hoping these
ideas pan out and we can put less stress the on malloc
implementation.

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>