similar to: Boehm

Hi, I'm running LLVM bitcode generated by my compiler under lli. The bitcode is linked against Boehm GC (lli -load=/usr/lib/libgc.so). It looks like Boehm GC isn't scanning global variables and as a result objects referenced only through globals are being prematurely collected. I understand that Boehm GC needs to see the data segment containing my global variables as a root. For native

You should look at http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ExecutionEngine/JITMemoryManager.h?view=markup and see if inheriting from that and overriding allocateGlobal() will do what you want. I'm a little surprised the boehm gc doesn't already see the globals, since there's a reference to their memory from the JMM, but maybe it doesn't scan mmap regions by

I've implemented this by adding calls to GC_add_roots(<first global in module>,<last global in module>+1) to the llvm.global_ctors before any other static initialization code for the module. This should be safe assuming that: - global variables are laid out in memory in the order they appear in their module (and ideally contiguously without being interleaved with any other values)

Hi, I want to use LLVM as replacement code generator for an existing self hosting compiler. I hope to replace the existing BURS code generator with LLVM in order to take advantage of LLVM's JIT, optimizations and wider range of targets. I'm planning on ditching my existing IR completely and using my language's native call mechanism to call the LLVM C bindings. I've got a couple

The virtual machine I'm implementing allocates objects on the heap using Boehm's garbage collector. I currently have an interpreter working for my language, and I'm working on a JIT that will compile some of the functions that would otherwise get interpreted. What I'm wondering is whether or not I need to perform special adjustments for the GC to work properly. My understanding is

I'm hoping to have a stab at getting a tiny language implementation up and running soon. I assume I can just pull in Boehm's GC to get a very rudimentary collector up and running. However, can this work using JIT compilation from OCaml or will the new GC try to traverse the OCaml program's own stack? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd.

Hello, I've been able to get J3 working with the single and multimap garbage collectors but have hit several snags with Boehm and MMTk. For MMTk I get here: Buildfile: /cs/student/kyleklein/vmkit/mmtk/java/build.xml main: [mkdir] Created dir: /cs/student/kyleklein/vmkit/mmtk/java/classes [javac] Compiling 373 source files to /cs/student/kyleklein/vmkit/mmtk/java/classes

Hi everyone, vmkit had two major improvements recently, so I guess I should let you know :). First, it does not require to patch llvm. So you can use your llvm TOT with it. There are some not-required arch-specific patches in case you encounter problems when executing large applications. These should be mainly for ppc external symbols and x86 SSE. Please post to llvm-dev your test-case if

Hi, It is possible using Harmony - http://harmony.apache.org instead of classpath? Harmony has Garbage Collector and class lib. And is there any plan port it to win32? Regards Eric "Nicolas Geoffray" > Hi everyone, > > vmkit had two major improvements recently, so I guess I should let you > know :). > > First, it does not require to patch llvm. So you can use

For anyone who encounters this issue in the future, my issue was the configuration of llvm-gcc. Configure with --with-llvmgccdir=YOUR/PATH doesn't work, instead you are supposed to use --with-llvmgcc=PATH/TO/llvm-gcc and --with-llvmgxx=/PATH/TO/llvm-g++ That will at least get you past my error. Best, Kyle Quoting nicolas geoffray <nicolas.geoffray at gmail.com>: > I am

> The same can be said of closures, garbage collection and a dozen other > features that also cannot feasibly be added to LLVM. > > The only logical solution is to build a HLVM on top of LLVM and share that > between these high-level language implementations. This is an excellent point. You have convinced me. :-) BTW, what garbage collector are you using for your HLVM? You

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

On Thursday 19 February 2009 03:31:04 DeLesley Hutchins wrote: > > The same can be said of closures, garbage collection and a dozen other > > features that also cannot feasibly be added to LLVM. > > > > The only logical solution is to build a HLVM on top of LLVM and share > > that between these high-level language implementations. > > This is an excellent point.

Hi Jon, Jon Harrop wrote: > Other people are creating far more bleeding edge VMs (e.g. VMKit) using LLVM's > GC API so they would be much better positioned to discuss the technical > aspects than I am. I would like to hear any status updates they have! > > VMKit uses conservative GCs (Boehm or Mmap2, a GC developed in our lab), so we don't use the GC API. But we are

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, We’d like to propose an extension to both the map file and the print-gc/icf-sections output. This extension would be to report the pieces of .eh_frame and SHF_MERGE sections in these files somehow. Since all (or at least the majority) of the contents of these sections in the output come from inputs, it would be beneficial in trying to associate the output contents with where they came from,

Hello, 2009/2/26 Talin <viridia at gmail.com> > The IR-level intrinsics themselves don't much help you *write* a GC, so > much as to integrate one with LLVM. What is provided is essentially a > mechanism for walking the stack, and a means to insert read/write > barriers into the generated code, which together form a tiny fraction of > what it would take to design a

Hi everyone, I'm very new to the world of compilation and I've got to spend some time time on LLVM. As I have to produce a cross compiler for a completely new target and I don't want to cross-build the binutils, I choose Clang as a replacement frontend for llvm instead of llvm-gcc. But first, I just would like to compile something on my Linux platform in order to test the software,

llvm (and clang) do not include binutils. You're seeing clang invoking the gcc shell to assemble the .s file that clang generated, then again to link the object file into an executable. On Apr 27, 2010, at 8:31 AM, Swiss Guy wrote: > > Hi everyone, > > I'm very new to the world of compilation and I've got to spend some time > time on LLVM. > As I have to produce

It seems that showing eh_frame section pieces in the map file is useful, but I wonder what would be a concrete use case of the feature. Do you mind if you ask you to describe your plan if you have a use case in mind? On Tue, Feb 6, 2018 at 4:27 AM, James Henderson < jh7370.2008 at my.bristol.ac.uk> wrote: > Hi, > > > > We’d like to propose an extension to both the map file