fix #30653, call malloc_trim sometimes

[JeffBezanson]

This works around what seems to be a glibc bug. Fixes #30653

@cstjean See if this fixes your original case.

[JeffBezanson]

@nanosoldier runbenchmarks(ALL, vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan

[ViralBShah]

If this is an issue on only certain versions of glibc, is it worthwhile to apply this fix only if the user is using a glibc version that's bad?

[JeffBezanson]

I don't think so; with this change we'll only call malloc_trim if there's significant heap growth so it shouldn't take much time. And I don't want to bother tracking down which versions are affected.

[cstjean]

I'm seeing some fairly large trim difference for my code. I create temporaries which grow usage to 11GB. Then GC brings me down to ~4GB. Then explicitly calling malloc_trim gets me another 2GB.

julia> memory_usage() / 1.e9
4.618551296

julia> GC.gc()

julia> memory_usage() / 1.e9
4.61774848

julia> malloc_trim()  # the ccall
1

julia> memory_usage() / 1.e9
2.462871552

I guess that's to be expected given this PR? It's not a problem for us at the moment. I assume that it will be trimmed automatically eventually...