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.urba...@r-project.org> написал:
>
> > On Aug 11, 2017, at 12:57 PM, Iñaki Úcar <i.uca...@gmail.com> wrote:
> >
> > 2017-08-11 16:00 GMT+02:00 Martin Maechler <maech...@stat.math.ethz.ch>:
> >>>>>>> Dmitriy Selivanov <selivanov.dmit...@gmail.com>
> >>>>>>> on Fri, 11 Aug 2017 17:33:31 +0400 writes:
> >>
> >>> 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.
> >>
> >> I will create one.
> >>
> >> Your previous e-mails left me pretty clueless about what the
> >> problem is that you want to solve ... but maybe others
> >> understand better what you mean.
> >>
> >> Note that in the case of such a relatively sophisticated wish
> >> without a clear sign of a problem (in my view)
> >> chances are not high that anything will change, unless someone
> >> provides a (small footprint) patch towards the (R-devel aka
> >> "trunk") sources *and* reproducible R code that depicts the
> >> problem.
> >
> > How to reproduce it:
> >
> > a <- replicate(2e6, new.env()) # ~ 1.4 GB of memory
> > rm(a)
> > gc() # the R process still has the memory assigned
> >
>
> Right, but that's unavoidable because of the way Linux allocates memory -
> see FAQ 7.42
> The memory is free, Linux just keeps it for future allocations.
>
> Running malloc.trim doesn't help, because the issue is fragmentation due
> to the linear design of the pool - you likely will have another object on
> top so in most practical cases malloc.trim() doesn't actually do anything.
> You can always call malloc.trim() yourself is you think it helps, but it
> doesn't in the general case. The only way to address that would be to move
> allocated objects from top of the pool down, but that's not something R can
> allow, because it cannot know which code still has SEXP pointers referring
> to that object.
>
> Cheers,
> Simon
>
>
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
