similar to: Garbage collection

Hi all, I'm posting this here as it discusses an issue with an external C library. If it would be better in R-Help, then I'll repost. I'm using an external library which I've written, which provides a large set of data (>500MB in a highly condensed format) and the tools to return values from the data. The functionality has been tested call by call and using valgrind and works

Hi all, I'm posting this here as it discusses an issue with an external C library. If it would be better in R-Help, then I'll repost. I'm using an external library which I've written, which provides a large set of data (>500MB in a highly condensed format) and the tools to return values from the data. The functionality has been tested call by call and using valgrind and works

On 2009-02-27, at 19:58, Jon Harrop wrote: > On Friday 27 February 2009 18:42:13 Gordon Henriksen wrote: >> I agree this could be better. I think it would be prudent of you, >> being aware of this problem, to structure your compiler so as to >> limit >> the number of pieces of code which would be effected when you switch >> to a copying collector. > > I

On Friday 27 February 2009 18:42:13 Gordon Henriksen wrote: > I agree this could be better. I think it would be prudent of you, > being aware of this problem, to structure your compiler so as to limit > the number of pieces of code which would be effected when you switch > to a copying collector. I think that would make my VM a lot more complicated for no clear practical gain. >

On Feb 26, 2009, at 21:17, Jon Harrop wrote: > For example, the IR I am generating shares pointers read from the > heap even across function calls. That is built on the assumption > that the pointers are immutable and, therefore, that the GC is non- > moving. [...] > > If you wanted to add a copying GC to my VM you would probably > replace every lookup of the IR

>Hi folks, > >Our LLVM compiler creates a special debug section, which depends on a >certain >text section. This debug section is created with the SHF_LINK_ORDER >flag, and >sh_link field in the section header points to the correct section. > >When linking the program with the linker flag '-gc-sections', lld can >garbage- >collect unused sections. In my

When doing repeated regressions on large data sets, I'm finding that the time spent on garbage collection often exceeds the time spent on the regression itself. Consider this test program which I'm running on an Intel Haswell i7-4470 processor under Linux 3.13 using R 3.1.2 compiled with ICPC 14.1: nate at haswell:~$ cat > gc.R library(speedglm) createData <- function(n) {

Hi, I currently write a LLVM backend for RPython, a programming language and toolchain to write dynamic language interpreters. For example, this toolchain powers PyPy, a fast Python interpreter. In the moment the implementation uses a shadowstack to manage garbage collection stack roots. To improve performance, I experimented with LLVM's garbage collection support. It works by marking a

The following statements yield a seg.fault: R --vanilla --nsize 500K x <- rep(letters,10000) f <- function(x) {z<-paste("\"",x,"\"",sep=""); z} y <- f(x) Segmentation fault If a turn gcinfo on, I get Garbage collection [nr. 1]... 387529 cons cells free (75%) 3807 Kbytes of heap free (62%) Garbage collection [nr. 2]... 273868 cons cells free

On Fri, 2010-09-17 at 12:16 +0100, David Given wrote: > On 17/09/10 09:55, Pedro Ferreira wrote: > > As I understand it, LLVM simply gives you support for garbage collectors > > that you have to implement yourself and link into the final binary, > > similar to what C's malloc does (it's a library call). The issue with > > GC's is that they need to be provided

Talin wrote: > A while back there was a discussion thread about whether an accurate, > concurrent garbage collector could be "generic" in the sense of being > able to support multiple different languages efficiently. After having > done some work on this, I now believe that this is the case Very cool! I haven't worked on a system with good concurrent garbage

Hi, I had a technical question about CHARSXP and garbage collection and couldn't find the answer in the R manual. The question is this. Are CHARSXP garbage collected like any other object, despite being part of the CHARSXP cache? i.e. is the cache being cleaned by garbage collection regularly and therefore, when I am in C code, do I need to protect a CHARSXP? Thanks! Holger [[alternative

Thanks for the example code. Its gives a good idea how the shadow stack works. But I have another question. Using the shadow stack is a nice and simple way to implement GC, but it might have a large runtime overhead per function call. Is there another way to preserve garbage specific information (gcroots) through the llvm optimizer and native code generator? This information could be used to

Hello, I want to add garbage collection support to a compiler with a llvm backend, using the shadow-stack compiler plugin. I read the GC tutorial in the LLVM documentation, and the paper about shadow-stacks. Im currently adding intrinsics to my generated llvm code, and trying to write code to connected it to my (existing) garbage collector library. Im not sure yet how everything fits together.

Hi folks, Our LLVM compiler creates a special debug section, which depends on a certain text section. This debug section is created with the SHF_LINK_ORDER flag, and sh_link field in the section header points to the correct section. When linking the program with the linker flag '-gc-sections', lld can garbage- collect unused sections. In my case, the text section is correctly garbage-

Hi, In line 5, you are allocating a vector of length nc. Then, in line 12, you are using nr as a limit, so if nr goes beyond nc, which is happening in line 39, you are in trouble. I?aki On Sat, 12 Sep 2020 at 03:30, Rory Nolan <rorynoolan at gmail.com> wrote: > I want to write an R function using R's C interface that takes a 2-column > matrix of increasing, non-overlapping

On Sun, 6 Aug 2006, Reid Spencer wrote: > Yes, the JIT implementation was recently improved to add support for > this. There's nothing you need to do (or emit). The JIT implementation > will automatically collect memory that is not being used. See the > JITMemoryManager in lib/ExecutionEngine/JIT/JITEmitter.cpp for details. The JIT doesn't automatically do this. I don't

https://bugzilla.netfilter.org/show_bug.cgi?id=1778 Bug ID: 1778 Summary: Skipping garbage collection in nf_conncount.c stops working when jiffies wrap around Product: netfilter/iptables Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5

As I understand it, LLVM simply gives you support for garbage collectors that you have to implement yourself and link into the final binary, similar to what C's malloc does (it's a library call). The issue with GC's is that they need to be provided info about the stack, thats where LLVM's support comes in. As far as I know, the garbage collector is linked into the final binary

This is really nice, it supports my (somewhere-in-the-future) work with llvm, garbage collection and persistent memories. Can/Will one garbage collector be used for several different front-end languages? If so, don't you have to put functionality to traverse objects in the language implementation, since the internal representation depends on what language that is compiled. One language's