similar to: Change of variable address due to GC

Hi David, ? Thanks for the correction concerning the "else" issue. ? Taking your code and removing some lines (to increase readability): ? library(pryr) ? data <- array(dim = c(5)) for(x in 1:5) { ?? data[x] <- as.integer(x * 2) } ? #print(data) ? add = address(data) for(x in 1:5) { ?? data[x] <- as.integer(0) } ? if (add == address(data)) { print("Address did not

Hi, Given the following R code: library(pryr) data <- array(dim = c(5)) for(x in 1:5) { data[x] <- as.integer(x * 2) } add = address(data) # save address of "data" for(x in 1:5) { data[x] <- as.integer(0) } if (add == address(data)) { print("Address did not change") }

Hi, ? To get the memory address of where the value of variable "x" (of datatype "numeric") is stored one does the following in R (in 32 bit): ? ??? ? library(pryr) ? ?? ?x <- 1024 ?? ?? addr <- as.numeric(address(x)) +?24?? ?# 24 is needed to jump the variable info and point to the data itself (i.e. 1024) ? The question now is what is the value of the jump?so that one

Hello, I would like for my C function to be able to manipulate some values stored in an R data frame. To achieve this, a need the (real) memory address where the R data frame stores its data (hopefully in a contiguous way). Then, from R, I call the C function and passing this memory address as a parameter. The question: how can we get the memory address of the R data frame? Thank you! L.

> On Nov 12, 2017, at 8:47 AM, lille stor <lille.stor at gmx.com> wrote: > > Hi, > > Given the following R code: > > library(pryr) > > data <- array(dim = c(5)) > > for(x in 1:5) > { > data[x] <- as.integer(x * 2) > } > > add = address(data) # save address of "data" > > for(x in

If you were curious about the hidden details of the memory layout in R, the best reference is the source code. In your example, you are not getting to your string because there is one more pointer in the way, "x" is a vector of strings, each string is represented by a pointer. At C level, there is an API for getting an address of the value, e.g. INTEGER(x) or CHAR(STRING_ELT(x)). At

In this email to the R-help list: https://stat.ethz.ch/pipermail/r-help/2017-June/447474.html and in this question on Stackoverflow: https://stackoverflow.com/questions/44486643/nleqslv-memory-use-in-r Andrew Leach has raised a question about the memory usage of my package nleqslv. In a model with a loop within a function he has experienced continuously increasing memory usage by package nleqslv

Hi, ? I am trying to build R using Visual Studio 2010 but without success. My question is if it possible build?R with this compiler anyway? ? If not, could someone please tell how to link one's C code against both the static and shared libraries of R for Windows (that comes from the official website found here https://cran.r-project.org/mirrors.html)? ? Thank you!

On 1/9/20 06:56, Stepan wrote: > On 09. 01. 20 15:41, lille stor wrote: > >> I believe this could be done without creating side effects (e.g. >> crash) as we are just talking about changing values. A crash would certainly be an annoying "side effect" ;-) As Stepan explained, data.frame objects like most objects in R should never be modified in-place. If you're

On 3/27/20 15:19, Hadley Wickham wrote: > > > On Fri, Mar 27, 2020 at 4:01 PM Herv? Pag?s <hpages at fredhutch.org > <mailto:hpages at fredhutch.org>> wrote: > > > > On 3/27/20 12:00, Hadley Wickham wrote: > > > > > > On Fri, Mar 27, 2020 at 10:39 AM Herv? Pag?s > <hpages at fredhutch.org <mailto:hpages at

On Mon, Apr 28, 2008 at 8:31 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > On 2008-04-28, at 21:19, Lane Schwartz wrote: > > > On Mon, Apr 28, 2008 at 2:13 PM, Gordon Henriksen <gordonhenriksen at mac.com > > > wrote: > > > >>> If so, then a Collector plugin would need to have info about every > >>> supported backend

Sanjoy Das wrote: > In your > example, foo will have to treat its argument differently depending on > whether it is a GC pointer or not. In practice, this is not true of many functions that don't call other functions. Take the example of a simple "print" function that takes a void * to cast and print, type_int to determine what to cast to: why should it care about whether

Now that the statepoint changes have landed, I wanted to start a discussion about what's next for GC support in LLVM. I'm going to sketch out a strawman proposal, but I'm not set on any of this. I mostly just want to draw interested parties out of the woodwork. :) Overall Direction: In the short term, my intent is to preserve the functionality of the existing code, but migrate

On Mon, 19 Jul 2004, Tobias Nurmiranta wrote: > Regarding llvm.gcroot, do I have to allocate stack-space for all > pointers in a function? Right now I mostly use SSA-variables, and let > llvm's register allocation allocate stack-space when needed. Yes. This reflects the fact that the GC can move objects (to compact the heap) at unpredictable times. > Also, what happens when I

On Sun, Apr 27, 2008 at 9:34 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > As for the compiler plugin interface, I suggest you ignore it > initially and use the provided shadow-stack option for the time being. > The shadow stack generates significantly suboptimal code, but will let > you avoid writing some platform-specific code. Instead, simply copy > the

On Apr 28, 2008, at 14:28, Lane Schwartz wrote: > On Sun, Apr 27, 2008 at 9:34 PM, Gordon Henriksen > <gordonhenriksen at mac.com> wrote: > >> As for the compiler plugin interface, I suggest you ignore it >> initially and use the provided shadow-stack option for the time >> being. The shadow stack generates significantly suboptimal code, >> but will

Hi I'm using a GC that's pretty similar to the OCaml one. It records stack locations using llvm.gcroot, and dumps out a frametable describing the live stack offsets so that the GC runtime can walk them as required. I'm on 2.3, not svn head. I'm having some trouble with pointers being cached in registers across function calls (at least x86 backend, haven't tried others yet).

Correct, with a couple of nit picks. Relocation isn't an optimization the collector performs.  It's a key primitive the collector is built upon.  Being unable to relocate is not an allowed state.  (i.e. pinning can't be required by the compiler) When you talk about variables, that's true for the *source* language and for the *abstract* machine before lowering.  After lowering

Hi Terence, I think you're getting hung up on the details of the shadow stack collector. The shadow stack is a GC that is possible within this framework, but of course could be implemented without any special support. Its presence is more misleading than anything else. Taking a step back, the concepts are: llvm.gcroot instructs the code generator --> My GC needs to be able to

On Mon, Apr 28, 2008 at 2:13 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > > If so, then a Collector plugin would need to have info about every > > supported backend lays out the runtime stack? > > Yes. This information is actually available in a target-independent > fashion with LLVM, so the Collector interface is target-independent. A > backend