From simon.urbanek at r-project.org  Mon Jul  6 05:10:00 2009
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Sun, 5 Jul 2009 23:10:00 -0400
Subject: [Rd] Memory management issues
In-Reply-To: <20090705165445.68dae639@abz8111lx.eurac.edu>
References: <20090705165445.68dae639@abz8111lx.eurac.edu>
Message-ID: <24443639-D10D-4263-8D10-60D9FC1F4D36@r-project.org>


On Jul 5, 2009, at 10:54 AM, Yuri D'Elia wrote:

> Hi everybody,
>
> I have been interfacing some C++ library code into an R package but
> ran into optimization issues specific to memory management that  
> require
> some insight into the GC.
>
> One of the C++ libraries returns simple vectors of integers, doubles  
> and
> complex which are allocated and managed from the library itself. I
> cannot know the length of the array beforehand, so I cannot
> pre-allocate that memory through the GC.
>
> Right now I'm allocating via allocVector and copying all the data in  
> it.
> However, this requires twice the amount of space (and time), and we're
> running out of memory when doing concurrent analysis.
>
> What I'd would like to do is:
>
> - "patch" the SEXP returned to R so that DATAPTR() points directly to
>  the required address.
>

Why don't you just "patch" the library to use allocVector? That's most  
reliable and trivial to do. Messing around with internal SEXP  
representation is asking for trouble as that may change at any point  
without notice (note that all access is through functions to avoid  
that).

Cheers,
Simon


> - create a normal LISTSXP in the package, which holds a reference
>  to all these objects, so that GC never takes place.
>
> - turn these objects read-only, or, at least, ensure that they are
>  never free()d or remalloc()ed. overwriting the contents is not a
>  critical issue.
>
> Would that approach work?
> Are there any alternative approaches?
> Any specific advice about turning these objects read-only?
>
> Thanks in advance.
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>



[Rd] Memory management issues
Simon Urbanek