[R] question about bigmemory: releasing RAM from a big.matrix that isn't used anymore

[Matthew Keller]

Hi Jay and Benilton,

Thank you both for your help. When I do not use the dimnames argument,
everything works fine:

x <- big.matrix(nrow=2e4,ncol=5e5,type='short',init=0) #18 Gb RAM used
rm(x) #18 Gb RAM used
gc() #no RAM used

However, when I use dimnames, I get this problem, reproducibly:

x <- big.matrix(nrow=2e4,ncol=5e5,type='short',init=0,dimnames=list(2e4,5e5))
#18 Gb RAM used
rm(x) #18 Gb RAM used
gc() #18 Gb RAM used

I looked in /dev/shm throughout this and saw nothing there. Might
these files be stored elsewhere?

In any event, I have an easy work-around now, so this isn't a big
deal, but is it a bug in bigmemory that it doesn't return RAM when the
dimnames argument is used? Here's my sessioninfo

> sessionInfo()
R version 2.10.1 (2009-12-14)
x86_64-pc-linux-gnu

locale:
[1] C

attached base packages:
[1] graphics  grDevices datasets  utils     stats     methods   base

other attached packages:
[1] doMC_1.2.0      multicore_0.1-3 foreach_1.3.0   codetools_0.2-2
iterators_1.0.3 pnmath0_0.0-2




On Sat, Feb 6, 2010 at 2:44 PM, Jay Emerson <jayemerson at gmail.com> wrote:
>
>>>> See inline for responses.  But people are always welcome to contact
>>>> us directly.
>
> Hi all,
>
> I'm on a Linux server with 48Gb RAM. I did the following:
>
> x <-
> big.matrix(nrow=20000,ncol=500000,type='short',init=0,dimnames=list(1:20000,1:500000))
> #Gets around the 2^31 issue - yeah!
>
>>>> We strongly discourage use of dimnames.
>
> in Unix, when I hit the "top" command, I see R is taking up about 18Gb
> RAM, even though the object x is 0 bytes in R. That's fine: that's how
> bigmemory is supposed to work I guess. My question is how do I return
> that RAM to the system once I don't want to use x any more? E.g.,
>
> rm(x)
>
> then "top" in Unix, I expect that my RAM footprint is back ~0, but it
> remains at 18Gb. How do I return RAM to the system?
>
>>>> It can take a while for the OS to free up memory, even after a gc().
>>>> But it's available for re-use; if you want to be really sure, have a
>>>> look
>>>> in /dev/shm to make sure the shared memory segments have been
>>>> deleted.
>
> Thanks,
>
> Matt
>
> --
> John W. Emerson (Jay)
> Associate Professor of Statistics
> Department of Statistics
> Yale University
> http://www.stat.yale.edu/~jay
>



-- 
Matthew C Keller
Asst. Professor of Psychology
University of Colorado at Boulder
www.matthewckeller.com