[Rd] Memory management issues

[Whit Armstrong]

If you are in control of the c++ library (i.e. it is not from a
vendor), then you can also override the new operator of your object so
that it allocates an SEXP.  if you implement PROTECT/UNPROTECT calls
correctly, then GC will not be a problem.

The approach that I've taken with my time series library is that you
specify a storage policy as a template parameter.  If you are using
regular c++, then vectors of double/int are just allocated normally in
c++, however, if you specify the R storage backend, then the
constructor allocates an SEXP of doubles and sets the object's pointer
to the first element in the vector.  The ojbect doesn't really know
that it's using R's backend storage.

Sources here:
R backend storage policy: http://github.com/armstrtw/r.tslib.backend/tree/master
tslib: http://github.com/armstrtw/tslib/tree/master

-Whit



On Sun, Jul 5, 2009 at 10:54 AM, Yuri D'Elia<wavexx at users.sf.net> 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.
>
> - 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
>