From selivanov.dmitriy at gmail.com  Sat Aug 12 16:35:44 2017
From: selivanov.dmitriy at gmail.com (Dmitriy Selivanov)
Date: Sat, 12 Aug 2017 18:35:44 +0400
Subject: [Rd] Help to create bugzilla account
In-Reply-To: <BB27F8C5-00DD-42D2-AD1E-5BB8E9E2AE81@r-project.org>
References: <CAJdZCv3oUhwiqJUTwKy0ZvwkcB=qdA5WcBdfMsdAcJED9f356w@mail.gmail.com>
 <22925.47256.496267.20679@stat.math.ethz.ch>
 <CALEXWq1qcUU=cR-YT2fujXfB4HNd-7zJFdKhyuJ9icWRkV9-HQ@mail.gmail.com>
 <BB27F8C5-00DD-42D2-AD1E-5BB8E9E2AE81@r-project.org>
Message-ID: <CAJdZCv0NAMf9qYodsondd5BHF1JSsP2G=wU63UXuTwfQahRmjA@mail.gmail.com>

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> wrote:
> >
> > 2017-08-11 16:00 GMT+02:00 Martin Maechler <maechler at stat.math.ethz.ch>:
> >>>>>>> Dmitriy Selivanov <selivanov.dmitriy at 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]]



[Rd] Help to create bugzilla account
Dmitriy Selivanov