similar to: Run garbage collector when too many open files

In R 3.5 and later you should not need to gc() -- that should happen automatically within the connections code. Nevertheless, I would recommend redesigning your approach to avoid hanging onto open file connections as these are a scarce resource. You can keep around your temporary files without having them open and only open/close them on access, with the close run in an on.exit or a

Dear Luke, Thanks. See below On 07-08-18 17:07, luke-tierney at uiowa.edu wrote: > In R 3.5 and later you should not need to gc() -- that should happen > automatically within the connections code. Could you elaborate on what has changed in R 3.5? As far as I can tell my problem also occurs in R 3.5 (my computer is still on 3.4.4; but I assume the solaris CRAN machine isn't). And

Dear Uwe, (When replying to your message, I sent the reply to r-devel and not r-package-devel, as Martin Meachler suggested that this thread would be a better fit for r-devel.) Thanks. In the example below I used rm() explicitly, but in general users wouldn't do that. One of the reasons for the large number of file handles is that sometimes unnamed temporary objects are created. For

Basile STARYNKEVITCH wrote: > Does any know about some opensource multithread-compatible (or > concurrent) garbage collector library, if possible suitable for LLVM? > > (I mean that I want several mutator threads; the collector can be > stoptheworld or concurrent ....) > > H.Boehm's conservative GC is multithread compatible, but seems quite > slow (allocation is

Well, after many months of effort, my LLVM-based garbage collector is finally passing its unit tests. This represents a significant milestone for me in the development of my programming language, Tart. The collector itself is fairly rudimentary - a single-generation, copying collector. It does not yet support multi-threaded programs, but in practice there's no serious obstacle to supporting

On May 1, 2009, at 1:27 PM, Basile STARYNKEVITCH wrote: > Hello All > > Does any know about some opensource multithread-compatible (or > concurrent) garbage collector library, if possible suitable for LLVM? In fact, yes! http://code.google.com/p/scarcity/ -Chris

LLVM has GC possibility (llvm_gc_allocate). What compiler uses it? I try ldc D compiler but it not uses LLVM garbage collection but own in Tango library. -- View this message in context: http://old.nabble.com/How-start-with-LLVM-garbage-collector--tp29505874p29505874.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

Hello, i want to implement a common lisp subset using llvm for fun. This requires the use of a garbage collector. I read the docs, but many things are still unclear to me. 1. how are collectors supposed to find all living objects? there is llvm.gcroot for marking objects on the stack,but how do collectors crawl heap objects? I did not see a way to provide custom mark functions. Are

Since you are using a copying collector, may I ask how do you handle registers holding pointers to intermediate values? The example I am considering is something like void foo(void); void f(long long *v, long long n) { long long int i; for (i = 0; i < n; ++i) { v[i] = i; foo(); } } If *v points to gc memory, we can start the function with %v.addr = alloca i64*, align 8

Where's the problem? A pointer to v's alloca escapes to llvm.gcroot, so the optimizers should know that foo could modify the value it holds. foo() might also read v[i] through the escaped pointer, so the store will have to happen before the call. Reid 2011/3/8 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>: > Since you are using a copying collector, may I ask how do

Hi all, As part of my bachelor's thesis I'm trying to implement a new LLVM-based back end for the OCaml compiler. Currently I have a problem with LLVM's interface to the OCaml garbage collector. When I try to compile the attached program using llc I get the following stack dump: 0 llc 0x00000000016611de 1 llc 0x00000000016616aa 2 libpthread.so.0

Jaap Suter wrote: >> LLVM currently lacks working examples demonstrating the use of garbage >> collection... > > Hello, > > if anybody has time, I would recommend putting a big disclaimer at the top of > the garbage collection page that explains that, for the most part, garbage > collection falls outside of LLVM's domain. > > Right now LLVM

Hello All Does any know about some opensource multithread-compatible (or concurrent) garbage collector library, if possible suitable for LLVM? (I mean that I want several mutator threads; the collector can be stoptheworld or concurrent ....) H.Boehm's conservative GC is multithread compatible, but seems quite slow (allocation is about the time of a C malloc). And it is well known that

Hi all, As part of my bachelor's thesis I'm trying to implement a new LLVM-based back end for the OCaml compiler. Currently I have a problem with LLVM's interface to the OCaml garbage collector. When I try to compile the attached program using llc I get the following stack dump: 0 llc 0x00000000016611de 1 llc 0x00000000016616aa 2 libpthread.so.0

Hi, After compiling an example.cpp file with "-c -ffunction-sections" and linking with "--gc-sections" (used ld.lld), I am still seeing debug info for the sections deleted by garbage collector in the generated executable. Are there any compiler/linker options and/or other tools in LLVM to get rid of the above mentioned unneeded debug info? If such options does not exist,

Dear listers, a few days ago I asked a question about a problem I had with a C function programmed by myself to be called from R. Thanks to your help, I have been able to look a bit further into it, so now I can be a bit more specific when telling what happens. The fact is that, when my C function finishes its execution (after calling it via the ".C" interface), R seems ok but

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Davide Italiano via llvm-dev > Sent: Thursday, September 20, 2018 10:55 AM > To: ramana.venkat83 at gmail.com; Cary Coutant > Cc: llvm-dev; LLDB > Subject: Re: [llvm-dev] [lldb-dev] [LLD] How to get rid of debug info of > sections deleted by garbage collector > >

> LLVM currently lacks working examples demonstrating the use of garbage > collection... Hello, if anybody has time, I would recommend putting a big disclaimer at the top of the garbage collection page that explains that, for the most part, garbage collection falls outside of LLVM's domain. Right now LLVM advertises itself as "supporting garbage collecting", which although

Hi all, I am trying to tune and troubleshoot an application which runs a background (delayed_job) process involving the import and processing of large csv files into the db and then processing of that data. When I run the process (here Ubuntu 10.04) and monitor ''top'' in the terminal, I see that ''Mem: used'' starts at maybe 500000k and then ups through the process

Thank you all for your time in responding to my query. My understanding was also similar to what you all mentioned here but wanted to check if there are any recent developments in solving this problem. Thanks, Ramana On Thu, Sep 20, 2018 at 9:32 PM, Rui Ueyama <ruiu at google.com> wrote: > Right. Technically we can get rid of debug info that corresponds to dead > sections, but in