search for: malloc_trim

On 12 August 2017 at 15:10, luke-tierney at uiowa.edu wrote: | As the Python posts poitns out, it is possible to use alternate malloc | implementations, either rebuilding R to use them or using LD_PRELOAD. | On Ubuntu for example, you can have R use jemalloc with | | sudo apt-get install libjemalloc1 | env LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1 R | | This does not seem to hold

...running R process created and deleted many small objects so R heap memory continued to grow. And eventually linux OOM killler killed R process. On other side same code worked fine on OS X or if I manually time to time called `mallinfo::malloc.trim()`. My question is whether it is possible to call `malloc_trim()` with each call of garbage collection on systems which use glibc? Calling it manually doesn't look like good approach for me. What are potential drawbacks of triggering `malloc_trim()` for each gc() call? I've made some tests and such calls are not longer than single digit millisecond for...

Strange because in my all my experiments calling malloc.trim always helped - memory reported by top decreased to the level it supposed to be. Do you have in mind case when calling malloc.trim won't do anything? Also shouldn't MALLOC_TRIM_THRESHOLD_ env variable has impact on malloc.trim calls? At the moment seems any value is ignored... 12 ???. 2017 ?. 6:09 ?? ???????????? "Simon Urbanek" < simon.urbanek at r-project.org> ???????: > > > On Aug 11, 2017, at 12:57 PM, I?aki ?car <i.ucar86 at gmail.com&gt...

...n Sat, 12 Aug 2017, Dmitriy Selivanov wrote: > Strange because in my all my experiments calling malloc.trim always helped > - memory reported by top decreased to the level it supposed to be. Do you > have in mind case when calling malloc.trim won't do anything? Also > shouldn't MALLOC_TRIM_THRESHOLD_ env variable has impact on malloc.trim > calls? At the moment seems any value is ignored... This is a question for glibc developers. For that matter, this entire thread is really about tuning of the malloc in glibc and should ideally be addressed upstream. There has been some discus...

Very interesting information about switching glibc malloc to jemalloc. So I see action plan as following: 1. set up some benchmark (need to think about design) 2. Run it on ubuntu machine with default glibc malloc 3. Run it with malloc_trim passed with reg.finalizer() 4. Run it with jemalloc 5. Review results and if they will look better than with glibc malloc - possibly consider switch R builds to use jemalloc on Debian, Ubuntu Can't promise about timeline, but I will definitely try to investigate. 2017-08-13 1:36 GMT+...

Hi mailing list and R-core. Could someone from R-core please help me to create account in bugzilla? I would like to submit issue related to gc() to wishlist. Related context is here - https://stat.ethz.ch/pipermail/r-devel/2017-July/074715.html -- Regards Dmitriy Selivanov [[alternative HTML version deleted]]

I have a new problem: Register RBP is used in a function foo. (I am not allocating RBP to any virtual register, the instances of RBP in function foo are in the machine code when my register allocator starts.) Function foo calls function bar. Register RBP is not saved across the call, though it is live after the call. Function bar includes a virtual register. The code that I'm using to

...arena; int ordblks; int smblks; int hblks; int hblkhd; int usmblks; int fsmblks; int uordblks; int fordblks; int keepcost; }; extern struct mallinfo mallinfo (void) __attribute__ ((__nothrow__)); extern int mallopt (int __param, int __val) __attribute__ ((__nothrow__)); extern int malloc_trim (size_t __pad) __attribute__ ((__nothrow__)); extern size_t malloc_usable_size (void *__ptr) __attribute__ ((__nothrow__)); extern void malloc_stats (void) __attribute__ ((__nothrow__)); extern void *malloc_get_state (void) __attribute__ ((__nothrow__)); extern int malloc_set_state (void *__ptr) __...